RMI callbacks with no replica aware stubs in a cluster?

We would like to use either an RMI ping mechanism or an RMI callback in an upcoming project but are limited to 1.1 and 1.2 JRE's. I don't believe generating a replica aware proxy is an option for us given those constraints, no support for dynamic proxies. So we have a remote server object that we would ideally like to be clusterable that we can register a callback interface with. How can we accomplish this given our client limitations with weblogic 8.1 RMI? Any options?

Yep you speak no lies. Of course once I thought about it some more I realized the error of assuming one could register a jdk rmi object with a weblogic rmi object. JRMP vs T3?. Not good.
We still like using plain jane RMI w/in weblogic. I can register my UnicastRemoteObject stub with a normal RMI object on the server and it can callback and deliver messages. It will also send heartbeats periodically. If the heartbeat isn't heard from in awhile we re-register through http. The advantage of this is that the http session has failed over to another box and the web tier manages the rmi registration for me. The client can remain ignorant of any RMI lookups, which are tedious when not using JNDI or the cluster aware proxy.
All of this to get back a few seconds and keep a few thousand clients from polling through a servlet every second. Argh JDK 1.1.
Thanks for hammering that final point in.

Similar Messages

Questions on InitialContext and replica-aware stub caching

Hi All,
We have a cluster and deployed with some stateless ejb session beans. Currently we only cached the InitialContext object in the client code, and I have several questions:
1. in the current case, if we call lookup() to get a replica-aware stub, which server will return the stub object, the same server we get the InitialContext, or it will load balanced to other servers every time we call the lookup method?
2. should we just cache the stub? is it thread safe? if it is, how does the stub handle concurrent requests from the client threads? in parallels or in sequence?
One more question, when we call new InitialContext(), it will take a long time before it can return a timeout exception if the servers are not reachable, how can we set a timeout for this case?

809364 wrote:
You can set the timeout value programatically by using the
weblogic.jndi.Environment.setRequestTimeout()
Refer: http://docs.oracle.com/cd/E12839_01/apirefs.1111/e13941/weblogic/jndi/Environment.html
or
set the REQUEST_TIMEOUT in the weblogic.jndi.WLContext
Refer: http://docs.oracle.com/cd/E11035_01/wls100/javadocs/weblogic/jndi/WLContext.html
Hi, I tried setting the parameters before, but it only works for stub lookup and ejb call timeout, not for the creation of InitialContext. And any idea for my 2nd question?

Is Replica aware stubs are in infinite loop when fail over????

          Hi
          Any help on this Appreciated
          See in this senario, where there is four weblogic instance runs in the cluster
          and a replica aware stub(stateless bean with idempodent methods) finds a particular
          method fails on a server and it redircets the request to another one server but the
          same method fails on all the server, then what is goin to happen?? is it going to
          throw some exception or gonna be in a loop to keep on redirecting the method request
          to all servers in Round???
          Regards
          Aruna


          Aruna,
          A stateless session bean whose methods have been declared idempotent will automatically
          retry on another service provider in a fail-over situation. When a fail-over situation
          occurs, the stub refreshes its list of service providers. Note: Just because your
          method call fails, doesn't mean it's a fail-over situation.
          Jane
          "Aruna" <[email protected]> wrote:
          >
          >Hi
          >
          > Any help on this Appreciated
          >
          > See in this senario, where there is four weblogic instance runs in
          >the cluster
          >and a replica aware stub(stateless bean with idempodent methods) finds a
          >particular
          >method fails on a server and it redircets the request to another one server
          >but the
          >same method fails on all the server, then what is goin to happen?? is it
          >going to
          >throw some exception or gonna be in a loop to keep on redirecting the method
          >request
          >to all servers in Round???
          >
          >
          >Regards
          >Aruna

Replica-aware stub.

Hi,
Can anyone explain about replica aware stub.
Thanks in advance.
Regards,
Vardhan.

Hi Vardhan,
Please refer to : http://download.oracle.com/docs/cd/E11035_01/wls100/cluster/overview.html
Load balancing and failover for EJBs and RMI objects is handled using replica-aware stubs, which can locate instances of the object throughout the cluster. Replica-aware stubs are created for EJBs and RMI objects as a result of the object compilation process. EJBs and RMI objects are deployed homogeneously—to all the server instances in the cluster.
Failover for EJBs and RMI objects is accomplished using the object’s replica-aware stub. When a client makes a call through a replica-aware stub to a service that fails, the stub detects the failure and retries the call on another replica. To understand failover support for different types of objects, see Replication and Failover for EJBs and RMIs.
WebLogic Server clusters support multiple algorithms for load balancing clustered EJBs and RMI objects: round-robin, weight-based, random, round-robin-affinity, weight-based-affinity, and random-affinity. By default, a WebLogic Server cluster will use the round-robin method. You can configure a cluster to use one of the other methods using the Administration Console. The method you select is maintained within the replica-aware stub obtained for clustered objects. For details, see Load Balancing for EJBs and RMI Objects.
Above kind of Stubs are available only for *"EJBs and RMI Objects"* when we deploy an EJB/RMI based application on Cluster.

RMI callback with JAVA1.5

Since the version 1.5 we have no need to distribute the stub to all the clients.
It's a great feature, but I need to perform a callback from the server to the client, in this case I need to perform a call to UnicastRemoteObject.exportObject() client-side before calling the registration method exposed by the server, and the stub of the class implementing the callback interface must be placed in the classpath of the server, is it true? Is there any other methos to perform an RMI-callback?
To be clear as much as possible I have this interface exposed by the server
public interface Services extends Remote
public Map<String, ApplicationStatus> applicationsList () throws RemoteException;
   public ApplicationStatus startApplication (String identifier) throws RemoteException;
public ApplicationStatus stopApplication (String identifier) throws RemoteException;
public int exitCode (String identifier) throws RemoteException;
   * This method, as the name says, is used by the client to register the listener to some server-side event.
   * @param callback
   * @throws RemoteException
public void registerForNotification (ExitCodeCallback callback) throws RemoteException;
}and the interface of the callback is
public interface ExitCodeCallback extends Remote
public void notifyExitCode (ExitCodeEvent event) throws RemoteException;
}On the server side I export the services in the registry
Services servicesServerSide = new MyServices();
Services services = (Services) UnicastRemoteObject.exportObject(servicesServerSide , 0);and on the client I perform a lookup of the services
Registry registry = LocateRegistry.getRegistry("192.168.0.1", 1099);
Services services = (Services) registry.lookup("SERVICES");I export my implementation of the interface
public class ClientExitCodeCallback implements ExitCodeCallback
public void notifyExitCode (ExitCodeEvent event)
    System.out.println(event.asString());
}through the code
services.registerForNotification(remoteCallback);but on the calling of this method I obtain a ServerSideException
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
     java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
     java.lang.ClassNotFoundException: it.sogei.jscheduler.rmi.client.ClientExitCodeCallback_Stub
     at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:325)
     at sun.rmi.transport.Transport$1.run(Transport.java:153)
     at java.security.AccessController.doPrivileged(Native Method)
     at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
     at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
     at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
     at java.lang.Thread.run(Thread.java:595)
     at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
     at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
     at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
     at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:179)
     at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:132)
     at $Proxy0.registerForNotification(Unknown Source)
     at it.sogei.jscheduler.rmi.client.StartClient.main(StartClient.java:45)
Caused by: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
     java.lang.ClassNotFoundException: it.sogei.jscheduler.rmi.client.ClientExitCodeCallback_Stub
     at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:285)
     at sun.rmi.transport.Transport$1.run(Transport.java:153)
     at java.security.AccessController.doPrivileged(Native Method)
     at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
     at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
     at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
     at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.ClassNotFoundException: it.sogei.jscheduler.rmi.client.ClientExitCodeCallback_Stub
     at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
     at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
     at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
     at java.lang.Class.forName0(Native Method)
     at java.lang.Class.forName(Class.java:246)
     at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
     at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
     at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
     at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
     at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197)
     at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
     at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
     at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
     at sun.rmi.server.UnicastRef.unmarshalValue(UnicastRef.java:290)
     at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:279)
     ... 6 moreIs it true all of the above?

If the server gets that exception, it's because the client found and used the stub when it exported its callback, or else the server is running < 1.5.
If the client explicitly cites a port number or zero and it is running >= 1.5 and there is no stub class, it won't use it; it will create a dynamic stub class; and it will send an object of that class to the server as a parameter to the registration call. If the server is running >= 1.5, it will succesfully deserialize that object, reconstruct the dynamic stub from information in the serialization stream, and execute the registration method implementation.
If the client exports by using a stub class instead of the above, it will create an object of that class and send it to the server as a parameter to the registration call; the server will try to deserialize it; and if it doesn't have the stub class available it will throw that exception.
This is how it works.

RMI Callbacks with Highavailability

Hi,
I would like to use the RMI Callbacks mechanism. The only problem I got is that I need to also implement highavailability, meaning that I will have more than one server. How can this be implement? Do I need to pass the callback reference to all the other servers? Is it possible to keep the reference in a data base?
Thanks!

I resent your remark.
A client can connect to one server. Now, this server has the refernce to later be used by RMI Callback. In order for other servers to use it as well, the server can serialize the reference and save it in the DB (that was my question - if saving it in the database is possible). A server that gets a request from a client and wants to forward it to another client, checks to see if it has its reference. If not, it reads it from the database and uses it.

RMI Callback with Applet

Hi,
I have a simple RMI Callback Client/Sever Application, where the client-side is inplemented in a JApplet. All works fine by local tests (client and server on my machine), but when the client is on remote machine I got an security exception or error (ClassFormatError(Bad magic number)).
How can I make my client/server work?

No, I'm testing inside LAN, no firewalls, no proxys, no nothing. Just a server and the client (applet).
And this strange error, I'll paste the entire stack trace:
java.lang.ClassFormatError: Client (Bad magic number)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at sun.plugin.security.PluginClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadCode(Unknown Source)
at sun.applet.AppletPanel.createApplet(Unknown Source)
at sun.plugin.AppletViewer.createApplet(Unknown Source)
at sun.applet.AppletPanel.runLoader(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
On my local machine oll works fine... is the problem the applet's "sandbox"? Or...?
Any ideas are welcome
Thanks

Re-deploying replica aware EJBs

          How does one update an app server with a new EJB when the app server
          is running in a cluster? Doing a re-deploy on the EJB in a single instance
          can even be a problem. First, you can have beans that are cached and
          in use. locking the server and waiting until the last client has completed
          it's operation until you do the redeploy should work. With clustered SLSBs
          the replica aware stubs get distributed by JNDI so until all the servers
          in the cluster have the update the classes are out of sync.
          It seems like you have to bounce all the app servers in the cluster. Not
          a very amicable solution.


In article <[email protected]>, [email protected] says...
          >
          > How does one update an app server with a new EJB when the app server
          > is running in a cluster? Doing a re-deploy on the EJB in a single instance
          > can even be a problem. First, you can have beans that are cached and
          > in use. locking the server and waiting until the last client has completed
          > it's operation until you do the redeploy should work. With clustered SLSBs
          > the replica aware stubs get distributed by JNDI so until all the servers
          > in the cluster have the update the classes are out of sync.
          >
          > It seems like you have to bounce all the app servers in the cluster. Not
          > a very amicable solution.
          >
          >
          >
          Mike,
          This is a toughy and something I've been trying to figure out for a
          while. Maybe together we'll devise a strategy so here's what I've come
          up with so far:
          Maintain a set of "upgrade servers" on another network line (using a
          switch). When upgrading, bring them online into the main cluster and
          then start kiling the main machines. When they're all dead, unplug them
          from the network and begin the upgrade. Test the upgrade after bringing
          the new main cluster back up. Once confirmed, start locking out
          transactions, etc from the backup cluster and have the web front end
          give a "down for X minutes message to all new requests". Once the
          backup app servers have no more requests, unplug them from the network
          and plug the new app servers in. Reopen the flood gates at the front
          end. You'll still lose some sessions, but this should be in a service
          level agreement and be understood by customers.
          Some variations, in case the switch isn't manageable and being
          physically there is not on option would be to bring various interfaces
          up and down to meet the needs described above.
          It's not perfect; uptime is still purposely limited, but these are thing
          that should be defined in any agreement you make with customers. Even
          NASDAQ goes down. I'm currently working on a strategy for WebLogic 6.0
          JT

Replica aware

Hi,
          I am an absolute newbie in the world of web logic clustering. I am reading
          the article "How Clusters work" in WLS 5.1 documentation.
          I am not quite sure as to what do the term 'Replic aware'.
          It will be great if some one could explain that
          regards,
          Abhishek.


          Replica aware means this stub can be smart enough to know how many replicas(each replica means a deployed service on one server in the cluster) it represents and the detail information about these replicas(ie. it's ip address.)
          The replica-aware stub can support load-balance and fail over accroding to these information. suppose if one replica fails, the stub can remove this replica from this stub and fail over to other.
          Hope this can help you.
          Abhishek <abisheks@no_spam.india.hp.com> wrote:
          >Hi,
          >
          >I am an absolute newbie in the world of web logic clustering. I am reading
          >the article "How Clusters work" in WLS 5.1 documentation.
          >
          >I am not quite sure as to what do the term 'Replic aware'.
          >
          >It will be great if some one could explain that
          >
          >regards,
          >Abhishek.
          >

EJB home stubs in a cluster

The following URL describes how replica-aware EJB home stubs work. Basically,
when you do a lookup for the EJB home in JNDI, you get a home stub on any of the
nodes in the cluster.
However, I want to invoke EJBs on a particular node in the cluster. Can I do
this by simply disabling the replica-aware EJB home in the deployment descriptor
and doing a remote JNDI lookup on the desired node in the cluster? And if so,
would I have to bind each EJB's home to JNDI with a different name?
-reza
http://edocs.bea.com/wls/docs61/cluster/object.html#1006777
All bean homes can be clustered. When a bean is deployed on a server, its home
is bound into the cluster-wide naming service.
Because homes can be clustered, each server can bind an instance of the home under
the same name. When a client looks up this home, it gets a replica-aware stub
that has a reference to the home on each server that deployed the bean. When create()
or find() is called, the replica-aware stub routes the call to one of the replicas.
The home replica receives the find() results or creates an instance of the bean
on this server.

However, I want to invoke EJBs on a particular node in the cluster. Can Ido
this by simply disabling the replica-aware EJB home in the deploymentdescriptor
and doing a remote JNDI lookup on the desired node in the cluster? Andif so,
would I have to bind each EJB's home to JNDI with a different name?Yes. Something like that. We do that with JMS queues sometimes (to send a
message to a particular machine in the cluster).
Peace,
Cameron Purdy
Tangosol, Inc.
Clustering Weblogic? You're either using Coherence, or you should be!
Download a Tangosol Coherence eval today at http://www.tangosol.com/
"Behforooz" <[email protected]> wrote in message
news:3c8fc8bf$[email protected]..
>

RMI callback client stub

I am new to RMI.
We have a server component that runs within its own JVM.It needs to callback on client applets/consoles etc.
Ordinarily,the client would implement an interface, and distribute the interface and remoting stub to the server ,for the server to callback on.
However,rather than the client distributing the interface and stub,we wish the server to define a callback interface and implementation.
Thereby,the server can generate its own stub from the callback implementation.
This implementation can be provided to the client as a packaged class(along with the remote server stub and server interface).
The interested clients can extend this implementation.
The point that we wish to avoid through this framework,is the client providing the RMI stubs to the server for callback,as the server needs to be developed independently.
Is this a possible framework?
Any help will be appreciated.

If you do that you'll have to use the codebase feature to distribute the stub class to the client. I would use JDK 1.5 and forget about stubs altogether.

NAPT Firewall, RMI Callbacks and JRMP MultiplexProtocol

Hi All,
I am looking at having an RMI client behind a Network Address Port Translation firewall receive RMI calls back from an RMI server. NAPT makes it impossible for the client to listen for connection coming from the server through the NAPT firewall.
This is discussed at http://www.rmiproxy.com and http://cssassociates.com/rmifirewall.html but the proposed solutions do not appear to use the MultiplexProtocol protocol defined by JRMP (http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmi-protocol3.html).
The RMI FAQ
"How can I receive incoming RMI calls through a local firewall"?
(http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html#firewallIn) had a section for JSSE 1.3 that explained how to use the multiplex protocol (option 4). It sounds like this option referred to the JRMP MultiplexProtocol protocol.
The multiplex protocol option has been removed from the 1.4 FAQ
(http://java.sun.com/j2se/1.4.2/docs/guide/rmi/faq.html#firewallIn).
Tried the "checkListen" and "socket factory" techniques mentioned in the 1.3 FAQ without success with 1.4.2. The RMI client behind the NAPT firewall runs in a signed Applet.
Is the ability of using the JRMP MultiplexProtocol protocol available in the JRE in order to receive incoming RMI calls through a local firewall? If yes, what do you do in order to use it?
What is the best way to have RMI callbacks work behind NAPT?
Thanks a lot in advance!
Cheers
Bertrand

As of about JDK 1.2.2, the ability of RMI clients to negotiate the multiplex protocol was
removed, but the server-side support remains.
Your best answer for negotiating NAT filrewalls may be the RMI Proxy http://www.rmiproxy.com, although I could be biased as I wrote it.
EJP

RMI callback

Hello everyone!
I have problem with RMI callbacks. I have on server function "connect" which is adding a client to host lists. Then if necessary I send something to people from that list. Everything is working, client can send info to server which is next resend to clients from host list. But problem is at start-up. Sending to a server a reference to a client object is very, very slow. It takes about 10-20 sec.
Then everything is fine, every method gives me an answer within parts of seconds.
How can I eliminate this startup problem?
Thanks in advance,
Daniel

It seems that I resolve the problem first :) Hopfully.
Here is the answer for those of You who has or will have same problem:
If you want to pass the object by reference to server you need to implement Remote interface. Of course this is implemented by class UnicastRemoteObject, which you have to extend, but you must remember to implement it in every object which is called by class as well. I have forgoten about this and insted passing by reference it copied object, which is horrible SLOW!!

"DEADLOCK" when showing dialog from RMI-callback.

Hi!
Today is the 10th day (full time) that I've been searching for a solution in Java Forums and Internet, but I couldn't find anything that helps me. Help is extremely appreciated, otherwise I'll go crazy! :-)
The problem is that RMI-callback thread "somehow blocks" the Event Dispatch Thread.
I want to do following:
1) I push the button in the client (btDoSomething)
(MOUSE_RELEASED,(39,14),button=1,modifiers=Button1,clickCount=1 is automatically pushed onto EventQueue)
2) btDoSomethingActionPerformed is invoked
3) inside of it I make a call to RMI-server (server.doSomething())
4) from this server method I invoke RMI-callback back to the client (client.askUser())
5) in the callback I want to display a question to the user (JOptionPane.showConfirmDialog)
6) user should answers the question
7) callback returns to server
8) client call to the server returns
9) btDoSomethingActionPerformed returns and everybody is happy :-)
This works normally in normal Client, that means, while a button is pushed, you can show Dialogs, but with RMI callback I get problems.
I just made a small client-server sample to simulate real project. What I want to achieve is that client invokes server method, server method does something, but if server method doesn't have enough information to make the decision it needs to do call back to the client and wait for input, so the user gets an JOptionPane.
Here is my callback method:
    /** this is the remote callback method, which is invoked from the sevrer */
    public synchronized String askUser() throws java.rmi.RemoteException {
        System.out.println("askUser() thread group: " + Thread.currentThread().getThreadGroup());
        System.out.println("callback started...");
        try {
            SwingUtilities.invokeLater(new Runnable() {
                public void run() {
                    System.out.println("My event started...");
                    JOptionPane.showConfirmDialog(parentFrame, "Are you OK?", "Question", JOptionPane.YES_NO_OPTION);
                    System.out.println("My event finished.");
        }catch (Exception e) {
            e.printStackTrace();
        try {
            Thread.currentThread().sleep(10000);
        }catch (Exception e) {
            e.printStackTrace();
        System.out.println("callback finished.");
        return "Yo!"; // just return anything
    }Here in this sample I let the callback thread sleep for 10 seconds, but in real project I let it sleep infinitely and I want to wake it up after the user has answered JOptionPane. But I have the DEADLOCK, because event queue is waiting for callback to finish and doesn't schedule the "showing dialog" event which contains the command for waking up the callback thread.
I looked very precisely when the event queue starts again to process events: it is precisely then when btDoSomethingActionPerformed is finished.
When I'm not accessing GUI inside of the callback, this callback mechanism works perfectly, but as soon as I want to show the dialog from inside of the RMI-callback method, the "AWT Event Dispatch Queue" is somehow frozen until RMI-callback thread is finished (and in turn btDoSomethingActionPerformed terminates) . I cannot explain this weird behaviour!!!
If I don't use SwingUtilities.invokeLater (I know this shoudn't be done outside of Event Dispatch Thread), but access the GUI directy, my JOptionPane is shown, but is not painted (it is blank gray) until callback thread returns.
Why showing (or painting) of dialog is not done until btDoSomethingActionPerformed is finished?
I also tried to spawn a new Thread inside of main RMI-callback thread, but nothing changed.
I also tried the workaround from some older posting to use myInvokeLater:
    private final static ThreadGroup _applicationThreadGroup = Thread.currentThread().getThreadGroup();
    public void myInvokeLater(final Runnable code) {
        (new Thread(_applicationThreadGroup, new Runnable() {
            public void run() { SwingUtilities.invokeLater(code); }
        ).start();
    }but this didn't help either.
Then I tried to spawn a new Thread directly from the Client's constructor, so that I'm sure that it belongs to the main appplication thread group. I even started that thread there in the constructor and made it wait for the callback. When callback came in, it would wake up that sleeping thread which should then show the dialog. But this did't help either.
Now I think that it is IMPOSSIBLE to solve this problem this way.
Spawning a new Process could work I think, but I'm not really sure if I want do to that.
I know I could make a solution where server method is invoked and if some information is missing I can raise custom exception, provide the input on client side and call the same server mathod again with this additional data, but for that I need to change server RMI interfaces, etc... to fit in this concept. I thought callback would much easier, but after almost 10 days of trying the callback...I almost regreted it :-(
Is anyone able to help?
Thank you very much!
Please scroll down for the complete sample (with build and run batch files), in case someone wants to try it. Or for the time being for your convenience you can download the whole sample from
http://www.onlineloop.com/~tornado/download/rmi_callback_blocks_gui.zip
######### BEGIN CODE ####################################
package callbackdialog;
public interface ICallback extends java.rmi.Remote {
    public String askUser() throws java.rmi.RemoteException;
package callbackdialog;
public interface IServer extends java.rmi.Remote {
    public void doSomething() throws java.rmi.RemoteException;
package callbackdialog;
import java.rmi.Naming;
public class Server {
    public Server() {
        try {
            IServer s = new ServerImpl();
            Naming.rebind("rmi://localhost:1099/ServerService", s);
        } catch (Exception e) {
            System.out.println("Trouble: " + e);
    public static void main(String args[]) {
        new Server();
package callbackdialog;
import java.rmi.Naming;
public class ServerImpl extends java.rmi.server.UnicastRemoteObject implements IServer {
    // Implementations must have an explicit constructor
    // in order to declare the RemoteException exception
    public ServerImpl() throws java.rmi.RemoteException {
        super();
    public void doSomething() throws java.rmi.RemoteException {
        System.out.println("doSomething started...");
        try {
            // ask the client for the "missing" value via RMI callback
            ICallback client = (ICallback)Naming.lookup("rmi://localhost/ICallback");
            String clientValue = client.askUser();
            System.out.println("Got value from callback: " + clientValue);
        }catch (Exception e) {
            e.printStackTrace();
        System.out.println("doSomething finished.");
package callbackdialog;
import java.rmi.server.RemoteStub;
import java.rmi.server.UnicastRemoteObject;
import java.rmi.registry.Registry;
import java.rmi.registry.LocateRegistry;
import java.rmi.Naming;
import javax.swing.JOptionPane;
import javax.swing.SwingUtilities;
import javax.swing.JFrame;
public class Client extends javax.swing.JFrame implements ICallback {
    private final JFrame parentFrame = this;
    private Registry mRegistry = null;
    private RemoteStub remoteStub = null;
    private IServer server = null;
    private final static ThreadGroup _applicationThreadGroup = Thread.currentThread().getThreadGroup();
    /** Creates new form Client */
    public Client() {
        initComponents();
        System.out.println("Client constructor thread group: " + Thread.currentThread().getThreadGroup());
        try {
            server = (IServer)Naming.lookup("rmi://localhost/ServerService");
            // register client to the registry, so the server can invoke callback on it
            mRegistry = LocateRegistry.getRegistry("localhost", 1099);
            remoteStub = (RemoteStub)UnicastRemoteObject.exportObject((ICallback)this);
            Registry mRegistry = LocateRegistry.getRegistry("localhost", 1099);
            mRegistry.bind("ICallback", remoteStub);
        }catch (java.rmi.AlreadyBoundException e) {
            try {
                mRegistry.unbind("ICallback");
                mRegistry.bind("ICallback", remoteStub);
            }catch (Exception ex) {
                // ignore it
        }catch (Exception e) {
            e.printStackTrace();
    /** This method is called from within the constructor to
     * initialize the form.
     * WARNING: Do NOT modify this code. The content of this method is
     * always regenerated by the Form Editor.
    private void initComponents() {
        java.awt.GridBagConstraints gridBagConstraints;
        secondTestPanel = new javax.swing.JPanel();
        btDoSomething = new javax.swing.JButton();
        getContentPane().setLayout(new java.awt.GridBagLayout());
        setDefaultCloseOperation(javax.swing.WindowConstants.DISPOSE_ON_CLOSE);
        setTitle("RMI-Callback-GUI-problem sample");
        addWindowListener(new java.awt.event.WindowAdapter() {
            public void windowClosing(java.awt.event.WindowEvent evt) {
                formWindowClosing(evt);
        secondTestPanel.setLayout(new java.awt.GridBagLayout());
        btDoSomething.setText("show dialog");
        btDoSomething.addActionListener(new java.awt.event.ActionListener() {
            public void actionPerformed(java.awt.event.ActionEvent evt) {
                btDoSomethingActionPerformed(evt);
        gridBagConstraints = new java.awt.GridBagConstraints();
        gridBagConstraints.gridx = 0;
        gridBagConstraints.gridy = 3;
        gridBagConstraints.insets = new java.awt.Insets(10, 0, 0, 0);
        secondTestPanel.add(btDoSomething, gridBagConstraints);
        gridBagConstraints = new java.awt.GridBagConstraints();
        gridBagConstraints.gridx = 0;
        gridBagConstraints.gridy = 1;
        gridBagConstraints.fill = java.awt.GridBagConstraints.BOTH;
        gridBagConstraints.weightx = 1.0;
        gridBagConstraints.weighty = 1.0;
        getContentPane().add(secondTestPanel, gridBagConstraints);
        pack();
    private void btDoSomethingActionPerformed(java.awt.event.ActionEvent evt) {
        System.out.println(java.awt.EventQueue.getCurrentEvent().paramString());
        try {
            server.doSomething(); // invoke server RMI method, which will do the client RMI-Callback
                                  // in order to show the dialog
        }catch (Exception e) {
            e.printStackTrace();
    private void formWindowClosing(java.awt.event.WindowEvent evt) {
        try {
            mRegistry.unbind("ICallback");
        }catch (Exception e) {
            e.printStackTrace();
        setVisible(false);
        dispose();
        System.exit(0);
    /** this is the remote callback method, which is invoked from the sevrer */
    public synchronized String askUser() throws java.rmi.RemoteException {
        System.out.println("askUser() thread group: " + Thread.currentThread().getThreadGroup());
        System.out.println("callback started...");
        try {
            SwingUtilities.invokeLater(new Runnable() {
                public void run() {
                    System.out.println("My event started...");
                    JOptionPane.showConfirmDialog(parentFrame, "Are you OK?", "Question", JOptionPane.YES_NO_OPTION);
                    System.out.println("My event finished.");
        }catch (Exception e) {
            e.printStackTrace();
        try {
            Thread.currentThread().sleep(10000);
        }catch (Exception e) {
            e.printStackTrace();
        System.out.println("callback finished.");
        return "Yo!"; // just return anything
     * @param args the command line arguments
    public static void main(String args[]) {
        java.awt.EventQueue.invokeLater(new Runnable() {
            public void run() {
                Client client = new Client();
                client.setSize(500,300);
                client.setVisible(true);
    // Variables declaration - do not modify
    private javax.swing.JButton btDoSomething;
    private javax.swing.JPanel secondTestPanel;
    // End of variables declaration
1_build.bat
javac -cp . -d . *.java
rmic callbackdialog.ServerImpl
rmic callbackdialog.Client
pause
2_RunRmiRegistry.bat
rmiregistry
pause
3_RunServer.bat
rem java -classpath .\ Server
java callbackdialog.Server
pause
4_RunClient.bat
java callbackdialog.Client
pause
######### END CODE ####################################

I can understand that only partially, because SwingUtilities.invokeLater puts(redirects) my runnable object directly into AWT thread. The only conclusion I can draw from all things that I have tried until now , is that SwingUtilities.invokeLater(<showing the dialog>) invoked from a RMI thread somehow have lower "priority" than events coming directly from the AWT-thread and therefore it is held back until normal awt event completes (in this case BUTTON_RELEASED).
But what I don't understand is the fact that the dialog is not shown even If I create and start a new thread from the client's constructor. This thread has nothing to do with RMI as it is in the main thread group:
    private BlockingObject dialogBlocker = new BlockingObject();
    private BlockingObject blocker = new BlockingObject();
    public Client() {
        initComponents();
        (new Thread() {
            public void run() {
                try {
                    dialogBlocker.sleep(0);
                    System.out.println("My event started...");
                    JOptionPane.showConfirmDialog(parentFrame, "Are you OK?", "Question", JOptionPane.YES_NO_OPTION);
                    blocker.wake();
                    System.out.println("My event finished.");
                }catch (Exception e) {
                    e.printStackTrace();
        }).start();
        ...Callback is then only used to wake up this thread which should display the dialog:
    public Object askUser() throws java.rmi.RemoteException {
        System.out.println("callback started...");
        dialogBlocker.wake();
        blocker.sleep(0);
        System.out.println("callback finished.");
        return userChoice; // return anything I don't care for now
class BlockingObject {
    public void sleep(long timeout) {
        synchronized(this){
            try {
                wait(timeout);
            }catch (InterruptedException e) {}
    public void wake() {
        synchronized(this){
            notifyAll();
    }In this case the dialog is shown, but it is NOT painted, so I have deadlock again. Why it is not painted?!?
Haven't I uncouple it from RMI-Thread?
But perhaps I'm looking at the wrong side of the whole thing.
If I invoke server.doSomething (as ejp proposed) in a separate thread, then everything is fine (except that I cannot use this solution in my project :-( ).
It seems that the whole problem is NOT AT ALL related to callback itself, but rather to the fact that if client invokes remote call, even dialogs can't be shown until the rmi call returns to the client.
Thank you, Drindilica

RMI Callback Applet Tomcat!

Hello,
First timer here...bear with me.
I am running a RMI server and an applet with one interface for the RMI Server. This part works fine. The .class files and the html is deployed thru TOMCAT 4.1
The problem is however when the server code is changed to handle callbacks with the applet. Have already changed the security policy file. Now the applet too has its own interface.
Compiled the .java files and also rmic applet and rmic server. Started the registry after that. And the server too with the codebase too mentioned with -Djava.rmi.server.codebase. (As in the HelloWorld example on the sun website) So far so good.
However as soon as I load the appletviewer as http://localhost:8080/page.html (As I am running Tomcat) the error I get is:
IO Exception while reading: Connection refused: connect
Is it something to do with firewalls? But then everything is right now local and am lost...Any help will be really appreciated. Thanks a bunch.

More explanation to the mentioned problem:
I am sorry for not being very clear on this. Hope this helps.
This link has the "QuoteServer" example which is on the same lines as my project.
http://engronline.ee.memphis.edu/advjava/Examples/RMI/rmi_example.htm
In the above example I compile all four files and then generate rmic for applet and server. Then I place all the class files and the related html for the applet in TOMCAT.
Policy file:
grant {
// Allow everything for now
permission java.security.AllPermission;
permission java.net.SocketPermission "*:1024-65535", "connect,accept";
permission java.net.SocketPermission "*:80", "connect";
Then I start my TOMCAT and then the server with codebase=http:\\localhost:8080\(my folder)\ and the security file as mentioned above. So far so good.
The problem occurs when I start my applet as
appletviewer -J-Djava.security.policy="above file here" http:\\localhost:8080\page.html
Also when I loaded the applet in IE I got the AccessControlException:access denied. Can you also direct me as to how to direct the above security policy file in IE?
Thanks in advance for your patience. I hope I am clearer this time. Please let me know if more details are required.
Appreciate your help.

RMI callbacks with no replica aware stubs in a cluster?

Similar Messages

Maybe you are looking for