server-side disconnect detection

[WDS]

Hello - I wish to know if server side able to detect when client close
browser, aka terminate gwteventservice connection. How may this be
possible?

[sven.s]

Hi,

yes, that is possible and is already used to clean up the internal
user/event management when the browser is closed. It works by a
timeout detection. The client sends a message to trigger a connection
cycle (configured by max-waiting-time). That functionality is extended
in version 1.1 by supporting an unlisten listener with various scopes,
so other clients can register the listener to get notified about
disconnects of other users.

The unlisten listener is already used in the DemoConversationApp of
GWTEventService 1.1 (SVN trunk version) and can simply be tested by
pulling the network connector of a client while the
DemoConversationApp is running. The disconnected client gets a popup
message directly when the connector is pulled (really cool :-) ) and
the other clients get an event after the timeout is recognized at the
server side (when the configured timeout-time is exceed).

You may take a look in the timeout concept of GWTEventService:
http://code.google.com/p/gwteventservice/wiki/GWTEventServiceTimeoutConcept

[eirikb]

Hey

What if I want some clean-up on server-side?
Is it possible to hook into the internal user/even management?
And if my servlet is notified then I could just send addEvent instead
of UserLeaveEvent

Thanks

On Jan 23, 11:54 am, "sven.s" <sven.strohsch...@googlemail.com> wrote:
> Hi,
>
> yes, that is possible and is already used to clean up the internal
> user/event management when the browser is closed. It works by a
> timeout detection. The client sends a message to trigger a connection
> cycle (configured by max-waiting-time). That functionality is extended
> in version 1.1 by supporting an unlisten listener with various scopes,
> so other clients can register the listener to get notified about
> disconnects of other users.
>
> The unlisten listener is already used in the DemoConversationApp of
> GWTEventService 1.1 (SVN trunk version) and can simply be tested by
> pulling the network connector of a client while the
> DemoConversationApp is running. The disconnected client gets a popup
> message directly when the connector is pulled (really cool :-) ) and
> the other clients get an event after the timeout is recognized at the
> server side (when the configured timeout-time is exceed).
>

> You may take a look in the timeout concept of GWTEventService:http://code.google.com/p/gwteventservice/wiki/GWTEventServiceTimeoutC...

[sven.s]

Hi,

that is also possible with version 1.1 (trunk). You can get the
GWTEventService internal user management and register a
TimeoutListener.

See that piece of code:

UserManager theUserManager = UserManagerFactory.getInstance
().getUserManager();
UserActivityScheduler theUserActivityScheduler =
theUserManager.getUserActivityScheduler();
theUserActivityScheduler.addTimeoutListener(...);

Regards,

Sven S.

[eirikb]

Hey

That is exactly what I was looking for!
Works like a charm, thanks a bunch.
Oh and did I mention that your library is awesome? .. Well it is
awesome :D

[eirikb]

Hello

I wonder how I can link UserInfo to my own server-side info about a
user.
I have been using HttpSession to store the user name (nick), and then
retrieve information from HashMaps.
Since theUserActivityScheduler.addTimeoutListener give me a UserInfo-
object, I only got a ranom userId to work with,
is there any way I can get this when it is created? (So I can link the
userId to nick, for instance).
Maybe something similar to addTimeoutListener, just a listener for
addUser in UserManager?

[sven.s]

Hi,

the user/client is also identified with the session id in
GWTEventService. You can get the session id with UserInfo#getUserId()
and with that you should be able to get the nick from your user
management system, because you map the user with the session, too.

Another way to "catch" the user on register is to add an
UnlistenEvent. With EventRegistry#registerUnlistenEvent(...) you can
register a custom UnlistenEvent for every user. That custom
UnlistenEvent can contain information from your user management system
and will be published to all clients/users which have an
UnlistenEventListener registered to the UnlistenDomain.

The documentation of the new unlisten/timeout listening is in the
works and will be published very soon. So don't be worry when
something is unclear at the moment... ;-) The official release of
GWTEventService 1.1 is near.

Regards,

Sven S.

[eirikb]

Oh my I'm so sorry.

I was looking for attributes in session after userId, not realizing
that the id was the actual session id.
Just doing getThreadLocalRequest().getSession().getId() would do the
trick.
I was also searching your source for HttpSession, when I should have
searched for getThreadLocalRequest.

Oh well it works now, this solves everything.

Thanks again Sven :)