[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: [xmlblaster] New xmlBlaster session handling
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.
> -----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.
> Marcel Ruff
> mailto:ruff at swand.lake.de