Re: [xmlblaster] New xmlBlaster session handling

[Heinrich Götzger <goetzger at gmx.net>]

On Tue, 12 Mar 2002, Cyrille Giquello wrote:

>
>
>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
>update.
>I think this is a nice option.

I'm voting as well. Sounds good to me.
But how do we handle updates like this?
How is the connection to be watched?
What do we save really?
Or might it just be a setup via some options in the Qos for the regular
update?

Heinrich
--
http://www.xmlBlaster.org