[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] New xmlBlaster session handling

Marcel Ruff a écrit :

> Heinrich Götzger wrote:
> > Hi,
> >
> > the spec. sais:
> > " XmlBlaster allows to check clients with a ping to the callback server.
> > The ping frequency is adjustable at login time by the client itself. A
> > client session disappears when it does a logout or on failure (no response
> > to the ping) or on session-timeout or when killOldSessions=true is set."
> >
> > I'm courius about this, please allow me two questions:
> > Do you have any examples on how this ping-stuff is to be realised in Qos?
> > How many pakets (if at all) may be lost, unless the client will be
> > disconnected?
> >
> > One may not have a high performance netconnection but for example using
> > some radio-net or even letter-doves ;-). If one ping-frame drops out it
> > should not force the connection to shut down.
> > So I could imagine closing this client after 5 lost pings in a row for
> > example. Whereas a successful ping could reset this counter to 0.
> This is an interesting issue.
> The current ping is a blocking, application level ping,
> it sends a string and a string is returned.
> So there is no difference when invoking update(),
> update sends some arguments and receives a return value.
> (The return value is needed in future to allow
> transaction support with two phase commit).
> Loosing pings is dramatic, as is loosing updates.
> If we allow lost pings, we need to allow lost updates
> with resending until we succeed (or a certain number is reached).
> A MoM should support it, but i'm not shure
> if we shouldn't drop the client in such a case,
> and wait until the client reconnects.
> Possibly the best solution is to have a configuration
> parameter supporting both philosophies.
> Another question:
> -----------------
> Should we add a second update method, say
>    oneway updateOneway(MessageUnit[])
> which would allow much higher performance since no
> response message is needed with the drawback that this
> mode won't support transaction safety?
> Please vote on this.

Hello guies !

I'm voting for that second update method.
In case we want to send messages like UDP fashion. We don't want transaction, but fast and very frequent
I think this is a nice option.


> regards,
> Marcel
> --
> Marcel Ruff
> mailto:ruff at swand.lake.de
> http://www.lake.de/home/lake/swand/
> http://www.xmlBlaster.org


 -      http://www.ktaland.com/
 - Pour votre MAC: http://TOUSOFT.COM/
 * The contents of this e-mail are confidential to the ordinary user of the e-mail address to which it
was addressed and may also be privileged. If you are not the addressee of this e-mail you may not copy,
forward, disclose or otherwise use it or any part of it in any form whatsoever. If you have received this
e-mail in error please e-mail the sender by replying to this message.
Encryption | Duncan Campbell | DST | Blacklisted 411 | ECHELON | 2600 | PGP | Corsica | NSA