Re: Non-blocking notification mechanism via RMI

Its fairly easy to create a callback mechanism. Doing a google search should find lots of examples. I'll paste in some snippits of somthing i did that hopefully points you in the right direction. The remote software would provide the callback object to the server. If you are saying that you don't want to use a remote callback mechanism then there really isn't much you can do but block. Another approach is to have the server post answers to a client specific queue and have the client periodically remotely dequeue answers. This is not as clean as callbacks but is a bit simpler to implement.

Following is the interface to me callback object
interface EventCallbackInterface extends Remote
{
/**
This will tell the client that the server is still alive
* @throws RemoteException will be thrown if a network error occurs
*/
public void deadManCheck() throws RemoteException;
/**
An object has changes has occured
* @param index is an unique event identifier
* @param reason is the reason for the change
* @param record is which record changed
* @throws RemoteException will be thrown if a networking error occurs
*/
public void handleChange(int index,int reason,RtdrRecordData record) throws RemoteException;
}


Following is the class the implements it.
/**
* This class provides a callback mechanism from an rtdr server to the client
* @author Leon Lambert
* @version 1.00, 08/01/98
* @since JDK1.2
*/
class EventCallbackImpl extends UnicastRemoteObject implements EventCallbackInterface
{
/**
* Rtdr that is managing this connection
*/
RemoteRtdr remoteRtdr;

/**
* Allocate an instance to manage callbacks to this client
* @param remoteRtdr is an interface to the remote rtdr
* @exception RemoteException will be thrown for RMI errors
*/
public EventCallbackImpl(RemoteRtdr remoteRtdr) throws RemoteException
{
this.remoteRtdr = remoteRtdr;
}

/**
* The is called to provide a deadman point. This will fail on the server if i'm dead.
* @exception RemoteException will be thrown for RMI errors
*/
public void deadManCheck() throws RemoteException
{
}

/**
* Callback point to handle changes that this client has subscribed to
* @param index for the event reference
* @param reason for the change
* @param record is the one with the change
* @exception RemoteException will be thrown for RMI errors
*/
public void handleChange(int index,int reason,RtdrRecordData record) throws RemoteException
{
try
{
RemoteOHCRefNum remoteOHCRefNum = remoteRtdr.findEvent(index);
remoteOHCRefNum.handleChange(record,reason);
}
catch (Exception ex)
{
}
}
}


kittyhawk wrote:
That makes sense. But how do I notify the client when the job is done?
My first idea:
Let the client call stub.someMethod(xzy, this) where xyz is the actual
argument needed for the computation, and this is the refrenze to the
client object.
As soon as the job is done, the remote object could then call
((MyClientClass).processingJob.getReferenzeToClientObj()).notiy()

This callback has to go through RMI back to the client. So, the client
has to implement the Remote interface. Am I right? When I did this, it
worked, but any System.out.println() showed up on the remote side
instead of on the client side. Additionally, the remote object blocks
until the notify() method returns. Since I cann't assume a "frindly"
client, the notify method coul never return. Even if a use a separat
for each callback, the thread will wait as long as notify() is
executed. If notify() calculates a while(true){}, a bunch of waiting
threads will eat up my resources.

Probably I should say it more clearly: The problem is that I cannot
assume any time bound. Neither on the server side, nor on the client.
The server object has to be accessible via RMI, the client don't. A
worker thread on the server side fetching job for a queue is okay. But
I still don't see how the remote object notifies the client without
blocking until notify() returns.

Leon Lambert schrieb:

You don't need one thread per client. You just need 1 worker thread.
Have it pull requests from a synchronized queue. Have the RMI calls post
to the queue in a synchronized fashion. This is a pretty common way of
handling problems like this whether they are local or remote.

Hope this helps
Leon Lambert

kittyhawk wrote:
Alex Molochnikov schrieb:

"kittyhawk" <thomas.hentrich@xxxxxxxxx> wrote in message
news:1143588976.975859.138660@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi folks,

I want to trigger a method on some remote object via RMI to process
some data. But the client invoking the method should not block while
the remote object is processing. Instead, I would like the remote
object to notify the client as soon as the job is done.
Launch a new thread on the server from the method called by the client, and
return immediately. Any processing to be done by the request from the client
should be done in that new thread.

Of course, one could hand over the client's reference so that the
remote object could invoke a client's method. But, first, the server
will block as long as the client is doing something in its called
method,
Same deal on the client: start a new thread and return.

...and second, the client has to be accessible via RMI, too. The
latter fact even causes that the method is actually processed on the
server instead of on the client side. So, any System.out.println() will
show up on the server, not on the client.
Any method called on the client's objects (i.e. those that exist in the
client's address space) will be executed on the client. What makes you think
that you are seeing the client's System.out stream on the server?

I cann't span separate threads to do the callbacks. That's set.
And the reason is?

If you want the server to send a message to the client not as a response to
the client's call, but originating from the server, and want to use RMI for
this, the callback is your only choice. Essentially, you want to turn your
client into an improvised server, that will listen to the "real" server's
call - this is exactly what the callback mechanism does.

I have also looked into some design patterns, but didn't
find anything suitable for RMI problems at first glance.

All I want is a simple notification mechanism. Non-blocking on the
client, non-blocking on the server. Just a ping from the server to the
client, like "Hey, job is done. Fetch your result."
If you want to stay out of J2EE, the RMI can do this, but only if you are
willing/can use threads. Otherwise, you could try JMS - its asynchronous
messaging is suited perfectly for your task.

AM
I simply can't use a separate thread for each client task because my
component must also work on devices with limited memory and weak
processing power. Even the reduced overhead by using a thread pool is
way too much. All I can use is one thread within the remote object,
i.e. the server.
But I will look into JMS. Probably it will solve my headache...


.

Relevant Pages

  • [Full-Disclosure] R: Full-Disclosure Digest, Vol 3, Issue 42
    ... Full-Disclosure Digest, Vol 3, Issue 42 ... SD Server 4.0.70 Directory Traversal Bug ... Arkeia Network Backup Client Remote Access ...
    (Full-Disclosure)
  • RE: Remote connectivity problems
    ... do you mean you have added a remote client to SBS ... If you have hardware VPN tunnel setup using Linksys or others, ... In this scenario you have to configure the SBS Server computer to enable ...
    (microsoft.public.windows.server.sbs)
  • Re: Terminal Services Remote Control
    ... You don't need the Remote Desktop Client on the server, ... how do I get Remote Control ...
    (microsoft.public.win2000.termserv.apps)
  • Re: RWW Disconnecting
    ... I have been connected from a remote site for about 3 ... DHCP server and even a wireless access ... the key codes to for Internet access. ... Client Workstations} ...
    (microsoft.public.windows.server.sbs)
  • Re: RWW Disconnecting
    ... Server to test the issue. ... I understand that remote client encounts following error message when RWW ... I strongly suggest that we rerun the Configure E-mail and Internet ...
    (microsoft.public.windows.server.sbs)