Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / October 2003

Tip: Looking for answers? Try searching our database.

Listen to standby, wake up event

Thread view: 
Juergen Kraus - 31 Oct 2003 11:46 GMT
Hi,

is there a way to listen to standby and wake up events with java programs.

We have a client application that sends periodically alive events to the
server. In standby or power save mode these events cannot be sent and
therefore our server terminates the session.
It would be nice to send events from the client to the server just before
switching to standby and shortly after waking up.

Do you have any tips to solve this problem?
Thank you!

Juergen
Gordon Beaton - 31 Oct 2003 12:00 GMT
> is there a way to listen to standby and wake up events with java
> programs.
[quoted text clipped - 6 lines]
>
> Do you have any tips to solve this problem?

I would suggest that your client should simply reconnect to the server
whenever it detects that the connection has been lost. Any distributed
application that hopes to be robust should do that anyway.

If your connections are stateful, the server should remember the state
of the client it disconnected. Upon reconnecting, the client can
request that the previous state (if any) be resumed, otherwise the
server can discard the saved state at that point.

Another idea is that you should be able to detect wakeup without
outside help. If you note the time you send each alive event, and
discover that the previous one was "long ago", then you can assume
that you've been asleep for the interim.

/gordon

Signature

[  do not email me copies of your followups  ]
g o r d o n + n e w s @  b a l d e r 1 3 . s e

Juergen Kraus - 31 Oct 2003 13:24 GMT
Hi Gordon,

thank you for your answer.

The problem is, that our server is not able to distinguish between clients
in standby mode and crashed clients. In both cases the client is dead an no
messages can be send to it.

A client opens a document and the server locks this document until it is
closed by the client. It is very important that a document is only edited
by one user at a time. Therefore we must be able to check if the client is
dead. If it is dead the server is able to unlock the open document.

Perhaps we should write some C program that listens to shutdown, standby
events at the client and forwards those events to the server.

Juergen
Gordon Beaton - 31 Oct 2003 15:23 GMT
> The problem is, that our server is not able to distinguish between
> clients in standby mode and crashed clients. In both cases the
[quoted text clipped - 9 lines]
> standby events at the client and forwards those events to the
> server.

If the client is holding a lock on a resource owned by the server, it
could be argued that the server should consider that a non-responsive
client is dead (regardless of the reason) and retract the lock. The
client can discover this fact when he wakes up and contacts the server
before continuing.

On the other hand if you can write C to listen to those events, you
should be able to write some native methods using JNI to notify your
client from within the application.

/gordon

Signature

[  do not email me copies of your followups  ]
g o r d o n + n e w s @  b a l d e r 1 3 . s e



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.