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:[EMAIL PROTECTED]] > Gesendet am: Dienstag, 12. M�rz 2002 08:31 > An: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > http://www.lake.de/home/lake/swand/ > http://www.xmlBlaster.org > >
