On option is to use the new Continuations api we added (I THINK to 2.1.3, might just be for 2.1.4-SNAPSHOT though) to allow the clients to "long poll" without consuming server threads.
Basically, a client would send a "amIOK" request to the server using an async method with a REALLY long timeout. Maybe an hour or so instead of the default 60 seconds. Maybe even turn off the timeouts. On the server side, the server would just create a continuation and record it. If the admin wants to disconnect a client, it would notify the continuation which would allow the server to send back a "will die soon" message. The client would get that message and can proceed as needed. Dan On Sunday 11 January 2009 10:42:16 am Andrew Clegg wrote: > 2009/1/11 SKS <[email protected]>: > > I am Ok with HTTP reuest / WEb service request , But i dont want server > > and client to continiously check and decide that its ok. You know real > > maintainance will happen weekly/monthly but if i keep on polling server > > just to see if i am being asked to get disconnected...its more resource > > consuming. If i get a mechanism where rather than continiously polling , > > if i get some message from server when disconnection is required it would > > make things more optimized...It may be something similar to push > > services... > > If you don't want the client to poll the server, then your only option > really is to run a server of some sort on the client. > > This could be a simple CXF web service running on an embedded instance > of Jetty in each client JVM. Or it could be something more > lightweight, such as a TCP or UDP socket server listening for a > particular signal. See e.g. > > http://www.javaworld.com/javaworld/jw-12-1996/jw-12-sockets.html > > The more low-level you're willing to get, the more optimized you can make > it. > > The problem is, all of these 'push' methods will fail if the user is > behind a firewall or router that doesn't allow incoming connections. > > You could have the client open a TCP socket to the server when a > session starts, which is kept open independently of the web services, > and uses it to send a connection-closing signal. But this might also > run into firewall issues, on a paranoid company intranet or out on the > web where people have personal firewalls. > > The only other option I can see is to piggyback a out-of-band > connection-closing signal on each 'regular' web service response. So > every response defined in the WSDL has an optional flag or variable > saying that the connection is about to close (and perhaps how soon), > which the client looks for. But this risks unexpected disconnects if > the client has been inactive for a while. (And it smells like a nasty > hack.) > > Remember Donald Knuth (I think) who said "premature optimization is > the root of all evil". You don't know that a polling operation every 5 > mins from each client will cause unacceptable slowdowns, until you > prototype it and load-test it. > > Andrew. -- Daniel Kulp [email protected] http://dankulp.com/blog
