AW: [xmlblaster] New xmlBlaster session handling

[<Michele.Laghi at swisscom.com>]

Hello everybody,
I like particularly using xmlBlaster with letter-doves ;)
About the oneway update I think it is a good idea since performance is an issue in many applications.

Cheers
Michele


> -----Ursprüngliche Nachricht-----
> Von: Marcel Ruff [mailto:ruff at swand.lake.de]
> Gesendet am: Dienstag, 12. März 2002 08:31
> An: xmlblaster at server.xmlBlaster.org
> Betreff: Re: [xmlblaster] New xmlBlaster session handling
> 
> 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.
> 
> 
> regards,
> 
> Marcel
> 
> -- 
> Marcel Ruff
> mailto:ruff at swand.lake.de
> http://www.lake.de/home/lake/swand/
> http://www.xmlBlaster.org
> 
>