RMI across a firwall

Does anyone have any experience with trying to get RMI to work across the firewall? If so what ports do I need to open to transfer data down and any problems you have had.
thanks.

The standard RMI Port is 1099, you'll need to open that up. I have used some crazy "not exactly endorsed by Sun" thing that did RMI over HTTP, but I am not even sure you can get that now. A google search might turn something up.
Hope that helped
Lee

Similar Messages

  • Hang of RMI call when LAN connection removed

    I have a client server application with comms using RMI across a TCP/IP LAN. We are in test at the moment and one of the tests is to ensure that when the LAN connection is removed, the client application handles it correctly.
    We have discovered that if we pull the LAN whilst an RMI call is in progress, the call never returns, even if we subsequently plug the LAN back in. Why should this be? I would have expected a RemoteException as soon as I pull the LAN out. How come the thread gets deadlocked?
    Note that we are running JRE 1.2 on the client (they are soon to be updated but it's 1400 remote, unattended sites so it's an expensive process to update to a recent JRE).
    Thanks
    Mat

    Thanks ejp - couple of dollars coming your way. Be a couple more if you (or anyone else) can help further.
    Firstly, how would I set this property in the code?
    Secondly, would it be set in the client or the factory (yes we do have one)? If it's in the factory, will that help me from the client side (that's where I need it to work). I looked up the responseTimeout property and it looks like this is more for the server to close incoming connections. The problem I have is on the client side - I need the client (i.e. that is making the RMI call via an exported remote object) to be able to kill off a call that has going too long (for instance because it can't detect the closed TCP connection).
    Maybe I've misunderstood the documentation I've found but that's how I read it.
    Thanks again!
    Mat

  • J2EE WAN connection

    I am an architect building Call Center on WLS 5.1 (We are in processes of migrating
    to WLS 6.1). Currently we are debating using RMI across the ocean. We are entertaining
    having a topology as follows webserver (along with web container leveraging STRUTS).
    So in essence calling the EJB across the ocean. There are two thought processes
    one to use the RMI the other to make use of webservices. The concern we have
    is that we are not convinced that RMI would peform on a WAN setting though we
    know it does fine on LAN. Any thoughts? Did anyone have experience with RMI/WAN?

    I do know of a customer that does RMI across the ocean over a private
    WAN network which sounds a lot like what you're doing.
    I would let other factors determine your RMI or web services choice.
    (Both are good options, but it depends a bit on your criteria which one
    will be better for your application.)
    -- Rob
    Yonas wrote:
    I am an architect building Call Center on WLS 5.1 (We are in processes of migrating
    to WLS 6.1). Currently we are debating using RMI across the ocean. We are entertaining
    having a topology as follows webserver (along with web container leveraging STRUTS).
    So in essence calling the EJB across the ocean. There are two thought processes
    one to use the RMI the other to make use of webservices. The concern we have
    is that we are not convinced that RMI would peform on a WAN setting though we
    know it does fine on LAN. Any thoughts? Did anyone have experience with RMI/WAN?

  • Distributed transactions across RMI-IIOP client to RMI-IIOP server do not work

    Hi,
              Based on the links below:
              http://e-docs.bea.com/wls/docs61/jta/trxrmi.html#1018506
              http://e-docs.bea.com/wls/docs61/jta/gstrx.html#1067532
              It appears that is possible to have distributed transactions across RMI-IIOP
              clients and RMI-IIOP applications (servers).
              I followed up the "Transactions Sample RMI Code" section but it appears that
              the transaction context is not propagated from client to server. I am also
              surprised by the note:
              Note: These code fragments do not derive from any of the sample applications
              that ship with WebLogic Server. They merely illustrate the use of the
              UserTransaction object within an RMI application.
              The above note suggests that there is no sample code available.
              Is there anyone who successfully had RMI-IIOP applications (servers)
              participating in distributed transactions?
              Is there any sample code that illustrates RMI-IIOP applications (servers)
              participating in distributed transactions?
              If anyone thinks that this should work I will post my code that does not
              work.
              Regards,
              Dan Cimpoesu
              

    But if you look to the diagram:
    http://e-docs.bea.com/wls/docs61/jta/gstrx.html#1040200
    it suggests that transactional context is passed from clients to RMI-IIOP
    servers.
    Am I wrong?
    Dan
    "Andy Piper" <[email protected]> wrote in message
    news:[email protected]..
    "Dan Cimpoesu" <[email protected]> writes:
    Transactions over IIOP are not supported or implemented in WLS 6.1 or
    previous. This is a feature of WLS 7.0. In 7.0 we implement OTS.
    andy
    Hi,
    Based on the links below:
    http://e-docs.bea.com/wls/docs61/jta/trxrmi.html#1018506
    http://e-docs.bea.com/wls/docs61/jta/gstrx.html#1067532
    It appears that is possible to have distributed transactions across
    RMI-IIOP
    clients and RMI-IIOP applications (servers).
    I followed up the "Transactions Sample RMI Code" section but it appearsthat
    the transaction context is not propagated from client to server. I amalso
    surprised by the note:
    Note: These code fragments do not derive from any of the sampleapplications
    that ship with WebLogic Server. They merely illustrate the use of the
    UserTransaction object within an RMI application.
    The above note suggests that there is no sample code available.
    Is there anyone who successfully had RMI-IIOP applications (servers)
    participating in distributed transactions?
    Is there any sample code that illustrates RMI-IIOP applications(servers)
    participating in distributed transactions?
    If anyone thinks that this should work I will post my code that does not
    work.
    Regards,
    Dan Cimpoesu

  • Distributed transactions across RMI-IIOP client to server do not work

    Hi,
    Based on the links below:
    http://e-docs.bea.com/wls/docs61/jta/trxrmi.html#1018506
    http://e-docs.bea.com/wls/docs61/jta/gstrx.html#1067532
    It appears that is possible to have distributed transactions across RMI-IIOP
    clients and RMI-IIOP applications (servers).
    I followed up the "Transactions Sample RMI Code" section but it appears that
    the transaction context is not propagated from client to server. I am also
    surprised by the note:
    Note: These code fragments do not derive from any of the sample applications
    that ship with WebLogic Server. They merely illustrate the use of the
    UserTransaction object within an RMI application.
    The above note suggests that there is no sample code available.
    Is there anyone who successfully had RMI-IIOP applications (servers)
    participating in distributed transactions?
    Is there any sample code that illustrates RMI-IIOP applications (servers)
    participating in distributed transactions?
    If anyone thinks that this should work I will post my code that does not
    work.
    Regards,
    Dan Cimpoesu

    But if you look to the diagram:
    http://e-docs.bea.com/wls/docs61/jta/gstrx.html#1040200
    it suggests that transactional context is passed from clients to RMI-IIOP
    servers.
    Am I wrong?
    Dan
    "Andy Piper" <[email protected]> wrote in message
    news:[email protected]..
    "Dan Cimpoesu" <[email protected]> writes:
    Transactions over IIOP are not supported or implemented in WLS 6.1 or
    previous. This is a feature of WLS 7.0. In 7.0 we implement OTS.
    andy
    Hi,
    Based on the links below:
    http://e-docs.bea.com/wls/docs61/jta/trxrmi.html#1018506
    http://e-docs.bea.com/wls/docs61/jta/gstrx.html#1067532
    It appears that is possible to have distributed transactions across
    RMI-IIOP
    clients and RMI-IIOP applications (servers).
    I followed up the "Transactions Sample RMI Code" section but it appearsthat
    the transaction context is not propagated from client to server. I amalso
    surprised by the note:
    Note: These code fragments do not derive from any of the sampleapplications
    that ship with WebLogic Server. They merely illustrate the use of the
    UserTransaction object within an RMI application.
    The above note suggests that there is no sample code available.
    Is there anyone who successfully had RMI-IIOP applications (servers)
    participating in distributed transactions?
    Is there any sample code that illustrates RMI-IIOP applications(servers)
    participating in distributed transactions?
    If anyone thinks that this should work I will post my code that does not
    work.
    Regards,
    Dan Cimpoesu

  • Passing a UNIXProcess across the wire through RMI

    hi....
    Well, is it possible to send a remote UNIXProcess across the wire through rmi?
    when Iam trying to do that the following exception is being thrown....
    java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
         java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: java.lang.UNIXProcessThanks for any help.
    cheers.......

    well, since we are talking about streaming, sockets will definitely be closer to what you want. however, in many ways sockets are more work to setup and manage compared to rmi. but, if you are sticking with the core jdk i would definitely recommend using sockets, because streaming over rmi is not easy to implement, and you're much better off dealing with sockets. of course, since you are probably already using rmi for the high level communication, using a library like RMIIO allows you to leverage the existing communication infrastructure, instead of dropping down to sockets for the input/output streaming. each side has its pros and cons.

  • RMI - loading a class across a network

    Hi,
    I've written a client-server program which uses RMI. I can run the server where I put a class into the RMI registry on port 4301 and connect to it from my client with the url : "//hostname:4301/rmi_name".
    This all works fine if I run it all on the same physical machine, as soon as I try to connect my client from a different machine I get "Unable to connect to //hostname:4301/rmi_name".
    However, I can ping the hostname, so the network is active. I've tried changing the hostname to the ip address with no difference. I'm sure the rmi name matches because I can connect on the same physical machine. I've also tried prefixing the url with "http:" and "file:" - then I just get invalid url.
    Anybody know what's wrong here?
    Cheers
    Tomas

    I tried the same thing but still got the error.
    I've discovered what I'm acutally getting is a java.rmi.UnmarshalException where the nested exception is java.lang.ClassNotFoundException.
    I can connect to the remote registry and get a correct list of the bindings. But I get the above error when I try to actually look the object up, either with Naming.lookup or with LocateRegistry.getRegistry(host, port).lookup(name);
    I think it's a codebase issue now. The two properties I'm setting are:
    java.rmi.server.hostname to "<hostname>" java.rmi.server.codebase to "file:/<full pathname>"
    I know this works locally, 'cos if I change the code base the local client won't find the _stub class (or other classes). I've also tried:
    java.rmi.server.codebase "file://<hostname>/<path>" but that just gives a class loader permission error. I can get over that by setting the policy file, but then I just come back to the original error again.
    Cheers
    Tomas
    btw generally to all: This isn't an applet. It's just an application running on the command line. Oh, and I was being a bit dumb, the "Unable to connect..." part is actually in my code. Sorry! ;-) Well spotted previous replier!

  • Java.rmi.ConnectException using webstart Swing client with WL 8.1 SP2 in a

    Hi all,
    I'm receiving the following exception when invoking a remote method on
    a cached remote stub. This only happens if there are at least two
    nodes running in a cluster. It happens more often the more nodes are
    running.
    It seems that the exception occurs if for a call to a remote method a
    cached stub is used, and if that call is referred to a different node
    in the cluster by the load balancer than the one that the stub
    originally came from. But I'm not completely sure about that...
    Client side config:
    Webstart
    JDK 1.4.2_05
    weblogic.jar (we're experiencing other problems already discussed in
    this group when using wlclient.jar)
    Server side config:
    Weblogic 8.1 SP2
    cluster on Sun Solaris machines (two nodes, one manager)
    Here is the exception stacktrace:
    java.rmi.ConnectException: Could not establish a connection with
    2198062098923170717S:shebea219:[7001,7001,-1,-1,7001,-1,-1,0,0]:SHEBEA219,SHEBEA334:DaGama:DaGamaNode1,
    java.security.AccessControlException: access denied
    (java.net.SocketPermission shebea219 resolve)
    at weblogic.rjvm.RJVMImpl.getOutputStream(RJVMImpl.java:316)
    at weblogic.rjvm.RJVMImpl.getRequestStream(RJVMImpl.java:488)
    at weblogic.rjvm.RJVMImpl.getOutboundRequest(RJVMImpl.java:584)
    at
    weblogic.rmi.internal.BasicRemoteRef.getOutboundRequest(BasicRemoteRef.java:91)
    at
    weblogic.rmi.internal.activation.ActivatableRemoteRef.invoke(ActivatableRemoteRef.java:69)
    at
    de.conet.dagama.interesengine.nativesession.SBNativeSession_8da95c_EOImpl_812_WLStub.isConnected(Unknown
    Source)
    at
    de.conet.dagama.agent.flight.nativ.FlightNativeListener.doExitNativeSession(FlightNativeListener.java:244)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at
    de.objektpark.framework.command.CommandInvoker.invoke(CommandInvoker.java:132)
    at
    de.objektpark.framework.command.CommandProcessor.doService(CommandProcessor.java:169)
    at
    de.objektpark.framework.command.CommandProcessor.service(CommandProcessor.java:131)
    at
    de.objektpark.framework.command.CommandProcessor.execute(CommandProcessor.java:71)
    at
    de.conet.webactiv.swing.command.GUICommandProcessor.execute(GUICommandProcessor.java:87)
    at
    de.conet.webactiv.swing.controller.GUICommandController.execute(GUICommandController.java:98)
    at
    de.conet.webactiv.swing.controller.GUICommandController.execute(GUICommandController.java:124)
    at
    de.conet.dagama.agent.flight.nativ.FlightFreeNativeView.this_windowClosing(FlightFreeNativeView.java:84)
    at
    de.conet.dagama.agent.flight.nativ.FlightFreeNativeView$1.windowClosing(FlightFreeNativeView.java:73)
    at java.awt.AWTEventMulticaster.windowClosing(Unknown Source)
    at java.awt.Window.processWindowEvent(Unknown Source)
    at javax.swing.JFrame.processWindowEvent(Unknown Source)
    at java.awt.Window.processEvent(Unknown Source)
    at java.awt.Component.dispatchEventImpl(Unknown Source)
    at java.awt.Container.dispatchEventImpl(Unknown Source)
    at java.awt.Window.dispatchEventImpl(Unknown Source)
    at java.awt.Component.dispatchEvent(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown
    Source)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    Has anyone ever come across the same problem and possibly found a
    solution?
    Any help would be greatly appreciated.
    Thanks in advance
    Rolf

    Hi all,
    I'm receiving the following exception when invoking a remote method on
    a cached remote stub. This only happens if there are at least two
    nodes running in a cluster. It happens more often the more nodes are
    running.
    It seems that the exception occurs if for a call to a remote method a
    cached stub is used, and if that call is referred to a different node
    in the cluster by the load balancer than the one that the stub
    originally came from. But I'm not completely sure about that...
    Client side config:
    Webstart
    JDK 1.4.2_05
    weblogic.jar (we're experiencing other problems already discussed in
    this group when using wlclient.jar)
    Server side config:
    Weblogic 8.1 SP2
    cluster on Sun Solaris machines (two nodes, one manager)
    Here is the exception stacktrace:
    java.rmi.ConnectException: Could not establish a connection with
    2198062098923170717S:shebea219:[7001,7001,-1,-1,7001,-1,-1,0,0]:SHEBEA219,SHEBEA334:DaGama:DaGamaNode1,
    java.security.AccessControlException: access denied
    (java.net.SocketPermission shebea219 resolve)
    at weblogic.rjvm.RJVMImpl.getOutputStream(RJVMImpl.java:316)
    at weblogic.rjvm.RJVMImpl.getRequestStream(RJVMImpl.java:488)
    at weblogic.rjvm.RJVMImpl.getOutboundRequest(RJVMImpl.java:584)
    at
    weblogic.rmi.internal.BasicRemoteRef.getOutboundRequest(BasicRemoteRef.java:91)
    at
    weblogic.rmi.internal.activation.ActivatableRemoteRef.invoke(ActivatableRemoteRef.java:69)
    at
    de.conet.dagama.interesengine.nativesession.SBNativeSession_8da95c_EOImpl_812_WLStub.isConnected(Unknown
    Source)
    at
    de.conet.dagama.agent.flight.nativ.FlightNativeListener.doExitNativeSession(FlightNativeListener.java:244)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at
    de.objektpark.framework.command.CommandInvoker.invoke(CommandInvoker.java:132)
    at
    de.objektpark.framework.command.CommandProcessor.doService(CommandProcessor.java:169)
    at
    de.objektpark.framework.command.CommandProcessor.service(CommandProcessor.java:131)
    at
    de.objektpark.framework.command.CommandProcessor.execute(CommandProcessor.java:71)
    at
    de.conet.webactiv.swing.command.GUICommandProcessor.execute(GUICommandProcessor.java:87)
    at
    de.conet.webactiv.swing.controller.GUICommandController.execute(GUICommandController.java:98)
    at
    de.conet.webactiv.swing.controller.GUICommandController.execute(GUICommandController.java:124)
    at
    de.conet.dagama.agent.flight.nativ.FlightFreeNativeView.this_windowClosing(FlightFreeNativeView.java:84)
    at
    de.conet.dagama.agent.flight.nativ.FlightFreeNativeView$1.windowClosing(FlightFreeNativeView.java:73)
    at java.awt.AWTEventMulticaster.windowClosing(Unknown Source)
    at java.awt.Window.processWindowEvent(Unknown Source)
    at javax.swing.JFrame.processWindowEvent(Unknown Source)
    at java.awt.Window.processEvent(Unknown Source)
    at java.awt.Component.dispatchEventImpl(Unknown Source)
    at java.awt.Container.dispatchEventImpl(Unknown Source)
    at java.awt.Window.dispatchEventImpl(Unknown Source)
    at java.awt.Component.dispatchEvent(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown
    Source)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    Has anyone ever come across the same problem and possibly found a
    solution?
    Any help would be greatly appreciated.
    Thanks in advance
    Rolf

  • Does RMI support the use of UDP?

    Hi, I'm writing a publication and I need a verifiable resource (i.e. a web document written by the people at Sun) that indicates definitively whether RMI is capable of supporting UDP.
    I've been searching the forums and came across some dissonant information concerning this. Here are the posts:
    1.
    RMI is built on top of Java's object and class facilities, its objects serialization protocol and its TCP/IP networking support, so its not possible to run it ontop of UDP.
    2.
    RMI use standard ISO TransfertControlProtocol network layer.TCP is aproximatly the 4th layer and IP the 3.
    3.
    RMI can also use UDP (same layer than TCP)
    The last one disagrees with the previous two.
    Thanks for any references anyone can provide,
    Tim

    just to correct myself. I had a short break and rewinded some years back to remember that NFS uses UDP (in fact sun RPC was developed to support NFS) and that sun RPC allowed both UDP and TCP. sorry about that:)
    Meanwhile, I found out that Berkeley implemented their own version of RMI , one aspect of which is "UDP-RMI".
    check it out at
    http://now.cs.berkeley.edu/Millennium/groups/GRP_SIMS/annual.html
    If you check SUN's RMI implementation code however you may confirm that they don't support UDP.
    Nuno

  • RMI Performance Comp. with Forte

    Hi All,
    I know that this topic has been discussed on the list
    already, but I would like to find out whether the
    current state of Sun's RMI implementation is like
    I imagine it, and I want to compare with our Forte
    Service objects too. Basically, these seem to be
    issues that negatively affect performance,
    1. A thread is created on the server per request, and
    there is no way to change this easily (i.e. reuse
    threads from a pool)
    2. Each call opens a new socket.
    In particular, does it make sense to replace RMI with
    CORBA for increased performance and scalability? Can a
    PC-based server handle loads of about 1000 remote
    calls per second (considering the overhead imposed by
    RMI/other communication methods only)? or Shall we
    compare Forte against RMI.
    Thankx,
    Babu

    Okay,
    A method invocation (or function call or procedure call or whatever) is
    always a synchronous call. This means, you ask the service to do something
    and wait for the function to complete, optionally with return values. It is
    possible, that within the method, a separate thread is started, that
    continues after the method is completed, but that doesn't change the
    mechanism that a method invocation is a synchronous call.
    In Forte, it is possible to start a method as an asynchronous call, with the
    "start task" command. In that case, the caller does not wait for the method
    to complete and return values are not handled. If this method invocation
    happens across a network (making it a Remote Method Invocation) then a
    socket will be opened when the call is made and closed immediately after. It
    does solve the one-socket-per-caller problem, but not the
    one-thread-per-caller problem. Also, it does remove the possibility of
    receiving return values.
    If you want to keep using method invocations as synchronous calls with
    return values, but you also want to share resources like sockets and
    threads, then you have to use TP-monitoring concepts. You must have a two
    way, asynchronous call with an additional parameter. This means, the client
    does a single, brief call that re-uses an existing thread and immediately
    frees the socket it used. The client passes all required parameters and one
    additional parameter to identify itself. In Forte, this would be a reference
    to an anchored object on the client-partition. Then the client waits
    (possibly blocks). The server completes the request and locates the client
    that sent the request. The server invokes a method on the client, informing
    that the request was handled. The server now also passes all return values.
    The client exits its wait-state and continues.
    In Forte (even if you use other mechanisms to hook into Forte), every call
    still is a separete thread. If you wish to re-use existing threads, this
    must be done using events. So, a client invokes a method asynchronously
    (using "start task") and waits. The server start a new thread and posts an
    event. Each existing thread is either idle in an event loop or busy handling
    a previous event. The new event is added to the queue of all event loops and
    the original thread is terminated (the socket was already freed). One event
    loop of the thread-pool will be the first one to respond to the event, mark
    this somewhere (maybe using mutex) and start handling it. All the others
    will eventually respond to the event as well, but will be able to see that
    the event is already being handled and ignore it.
    This does introduce overhead and it makes your application more complex, but
    it also prevents you running out of resources.
    Now, the real issue is not the amount of calls per second, but a combination
    of calls per second and seconds to complete the call. Using these two
    numbers, you can calculate the amount of tasks the server has to be handling
    simultaneously at any given time (average). Using the above described
    technique you can handle intermittent, large loads, because if there are
    more requests than available resources (threads) at any given time, the
    requests will simply be put in a queue and handled later. However, if the
    over-load continues for a prolonged period of time, the queue will simply
    grow and grow and grow until the partition crashes and all queued items will
    be lost.
    Then it is time for load-balancing. You install several additional servers
    and run a serverprocess on each of these machines. And you use a router that
    distributes calls across the different serverprocesses. Forte has built-in
    mechanisms for that, that work reasonably well. However, if the amount of
    calls per second is so high, that even the short time it takes the router to
    relay the request still is too long, so that the router runs out of
    resources, then you have to use more complex models, for which Forte doesn't
    have any ready-to-use solutions. But neither does CORBA or Java I believe.
    One more thing. If you combine the above described mechanism to free sockets
    as quickly as possible and use Forte loadbalancing, you might solve all your
    problems. Just install 6 overloaded server processes. This results in 6
    processes times 256 threads per process equals 1536 simultaneous tasks. If
    each task is an asynchronous method invocation that immediately frees its
    socket, then you never block you're whole server by using all sockets and
    you're still able to do handle 1536 requests simultaneously.
    Remember, if you have such a large load of calls per second, that all pass
    through the same machine (router) then you'll run into hardware limitations
    and no software solution can fix that. You have to find a mechanism to
    distribute calls across different nodes without using a single router. For
    example, cluster clients and have a single server node per cluster.
    Pascal.
    -----Original Message-----
    From: Babu Raj [SMTP:ibcsmartboyyahoo.com]
    Sent: Friday, March 24, 2000 3:42 PM
    To: Rottier, Pascal
    Cc: kamranaminyahoo.com
    Subject: RE: (forte-users) RMI Performance Comp. with Forte
    Hi,
    I believe in CORBA, ORB maintains the same
    connection ( Same Socket) for multiple calls, on the
    same Servant object, unless otherwise its ONEWAY call.
    But RMI uses the same strategy as Forte, I'm not sure
    either on this. Thats the reason, i asked the previous
    question.
    Thankx,
    Babu
    --- "Rottier, Pascal" <Rottier.Pascalpmintl.ch>
    wrote:
    How are CORBA and RMI different then Forte (one
    socket and one thread per
    call)?
    -----Original Message-----
    From: Babu Raj [SMTP:ibcsmartboyyahoo.com]
    Sent: Friday, March 24, 2000 3:18 PM
    To: kamranaminyahoo.com
    Subject: (forte-users) RMI Performance Comp. withForte
    Hi All,
    I know that this topic has been discussed on thelist
    already, but I would like to find out whether the
    current state of Sun's RMI implementation is like
    I imagine it, and I want to compare with our Forte
    Service objects too. Basically, these seem to be
    issues that negatively affect performance,
    1. A thread is created on the server per request,and
    there is no way to change this easily (i.e. reuse
    threads from a pool)
    2. Each call opens a new socket.
    In particular, does it make sense to replace RMIwith
    CORBA for increased performance and scalability?Can a
    PC-based server handle loads of about 1000 remote
    calls per second (considering the overhead imposedby
    RMI/other communication methods only)? or Shall we
    compare Forte against RMI.
    Thankx,
    Babu
    For the archives, go to:
    http://lists.xpedior.com/forte-users and use
    the login: forte and the password: archive. Tounsubscribe, send in a new
    email the word: 'Unsubscribe' to:forte-users-requestlists.xpedior.com
    For the archives, go to:
    http://lists.xpedior.com/forte-users and use
    the login: forte and the password: archive. To
    unsubscribe, send in a new
    email the word: 'Unsubscribe' to:
    forte-users-requestlists.xpedior.com
    For the archives, go to: http://lists.xpedior.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

  • General Question about RMI

    Okay here is what I am trying to do:
    I work for a small consulting firm and part of what we do is we process a tremendous amount of data using a suite of tools written in C/C++. We have a Java application which is really just a script (Written in standard Java) that makes a whole bunch of system calls, namely the commands in the suite of tools written in C. What we want to do is, is over our network, farm some of these system calls (or maybe even just CPU cycles) to multiple machines with the same suite of tools on them. Is this possible/plausible using RMI? Is there something that would be better for it? We have plenty of bandwidth across our network and most of the data is stored on a 15+ TB SAN.
    Also any books on the subject that you could recommend would be very helpful as well :)
    Any help would be very much appreciated.

    ofcourse passing over socket is always an option. Sure in that case you will have to serialize the object yourself or make a mini-protocol of some kind.
    In our project we also use XML to pass object between C++ and Java world, instead of using CORBA.

  • Binding POJOS across network

    I would like to bind two POJO objects across the network. (ie when a setter function is called on the server, the client version of the object gets updated by calling the same function). I was trying to come up with a generic solution, unfortunately it seems hard in Java. The best solution i came up with is to send a runnable object to the client every time a setter function is called. This runnable will be able to run on the client to call the same setter function and sync the two objects. This solution is lengthy and not so clean. Can you suggest another?

    ralph961 wrote:
    I would like to bind two POJO objects across the network. (ie when a setter function is called on the server, the client version of the object gets updated by calling the same function).Which describes RMI.
    Long years of practical use with various schemes like that have shown that solutions that attempt 'setters' like that are not practical however. Any non-trivial solution with even moderate traffic will generate way too much traffic.
    Thus one codes to the business cases instead.

  • Losing RMI-IIOP connection at server end

    Hi all
    I have a system running on Solaris 9, JVM 1.4.2_06 with a webapp hosted in Tomcat 5.5 connecting over RMI-IIOP to another java service on the same machine. The connection is established at webapp initialisation via a lookup to the naming service (currently tnameserv).
    Unfortunately, after a period of time (varies between a few hours and a couple of days), the RMI connection simply disappears from the server-side point of view, and the webapp grinds to a halt. Taking a thread dump of Tomcat and the service at the point of failure shows that Tomcat still has "JavaIDL Reader" threads listening to the service, but the service has lost all of its "JavaIDL Reader" threads listening to Tomcat.
    I've traced the problem as far as line 518 of com.sun.corba.se.internal.iiop.messages.MessageBase:
    bytecount = is.read(buf, offset + n, size - n);This read on the InputStream is throwing an IOException. I have configured the system so that IP address 127.0.0.1 is being used in all places.
    It may well be that this is not the right forum for this question, but has anyone else ever come across a problem like this? All suggestions most welcome.
    Regards
    Brian

    In trying to find an answer to your question, have actually discovered that the root cause of the issue is actually a little lower in the stack.
    SocketInputStream.read(byte[],int,int) is returning -1 (EOF), and this is being interpretted into an IOException by the MessageBase class. So now I need to work out why this unexpected EOF may be occurring on this platform.
    I imagine this is no longer very relevant to the RMI forum. I've posted on the Socket Programming forum.
    Regards
    Brian

  • RMI Cache Coordination

    I'm working on getting RMI based cache coordination functioning in my application using Eclipselink 1. I am using the 'INVALIDATE_CHANGED_OBJECTS' annotation and trying to get changed objects to propigate across 2 servers. I am using a function I got from the eclipselink list:
    public void customize(Session session) throws Exception {
    AbstractSession sessionImpl = (AbstractSession) session;
    RemoteCommandManager cm = new RemoteCommandManager(sessionImpl);
    cm.setShouldPropagateAsynchronously(true);
    cm.getDiscoveryManager().setAnnouncementDelay(10);
    cm.getTransportManager().setNamingServiceType(
    TransportManager.REGISTRY_NAMING_SERVICE);
    cm.setUrl("rmi://localhost:8881");
    cm.setServerPlatform(sessionImpl.getServerPlatform());
    sessionImpl.setCommandManager(cm);
    sessionImpl.setShouldPropagateChanges(true);
    cm.initialize();
    try {
    Thread.sleep(2000);
    } catch (Exception ignore) {
    and getting my factories as such:
    emf = Persistence.createEntityManagerFactory(s);
    new RMICacheCoordinationConfig().customize(JpaHelper.getServerSession(emf));
    em = emf.createEntityManager();
    After I make a few calls, I get several stack traces related to RMI I am fairly new to Toplink/Eclipselink and have not done much in the way of RMI.
    Here are the exceptions:
    [EPS Warning]: 2007.11.30 11:02:16.972--ServerSession(31985466)--Thread(Thread[Thread-8,5,main])--Local Exception Stack:
    Exception [EclipseLink-22102] (Eclipse Persistence Services - 1.0M1 (Build 20071105)): org.eclipse.persistence.exceptions.RemoteCommandManagerException
    Exception Description: Could not post connection in local naming service under name rmi://localhost:8881/13598682 Internal Exception: java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
    at org.eclipse.persistence.exceptions.RemoteCommandManagerException.errorBindingConnection(RemoteCommandManagerException.java:84)
    at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.createLocalConnectionInRegistry(RMITransportManager.java:157)
    at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.createLocalConnection(RMITransportManager.java:110)
    at org.eclipse.persistence.sessions.coordination.DiscoveryManager.run(DiscoveryManager.java:194)
    at java.lang.Thread.run(Thread.java:595)
    Caused by: java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
    at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:273)
    at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
    at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:306)
    at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
    at java.rmi.Naming.rebind(Naming.java:160)
    at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.createLocalConnectionInRegistry(RMITransportManager.java:154)
    ... 3 more
    Caused by: java.net.SocketTimeoutException: Read timed out
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:129)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
    at java.io.DataInputStream.readByte(DataInputStream.java:241)
    at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:215)
    ... 8 more
    Exception in thread "Thread-8" Local Exception Stack:
    Exception [EclipseLink-22102] (Eclipse Persistence Services - 1.0M1 (Build 20071105)): org.eclipse.persistence.exceptions.RemoteCommandManagerException
    Exception Description: Could not post connection in local naming service under name rmi://localhost:8881/13598682 Internal Exception: java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
    at org.eclipse.persistence.exceptions.RemoteCommandManagerException.errorBindingConnection(RemoteCommandManagerException.java:84)
    at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.createLocalConnectionInRegistry(RMITransportManager.java:157)
    at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.createLocalConnection(RMITransportManager.java:110)
    at org.eclipse.persistence.sessions.coordination.DiscoveryManager.run(DiscoveryManager.java:194)
    at java.lang.Thread.run(Thread.java:595)
    Caused by: java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
    at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:273)
    at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
    at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:306)
    at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
    at java.rmi.Naming.rebind(Naming.java:160)
    at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.createLocalConnectionInRegistry(RMITransportManager.java:154)
    ... 3 more
    Caused by: java.net.SocketTimeoutException: Read timed out
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:129)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
    at java.io.DataInputStream.readByte(DataInputStream.java:241)
    at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:215)
    ... 8 more
    [EPS Warning]: 2007.11.30 11:03:17.594--ServerSession(31985466)--Thread(Thread[Finalizer,8,system])--Local Exception Stack:
    Exception [EclipseLink-22107] (Eclipse Persistence Services - 1.0M1 (Build 20071105)): org.eclipse.persistence.exceptions.RemoteCommandManagerException
    Exception Description: Could not remove local connection in local naming service under name rmi://localhost:8881/13598682 Internal Exception: java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
    at org.eclipse.persistence.exceptions.RemoteCommandManagerException.errorUnbindingLocalConnection(RemoteCommandManagerException.java:137)
    at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.removeLocalConnection(RMITransportManager.java:234)
    at org.eclipse.persistence.sessions.coordination.TransportManager.discardConnections(TransportManager.java:432)
    at org.eclipse.persistence.sessions.coordination.RemoteCommandManager.shutdown(RemoteCommandManager.java:179)
    at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.logout(DatabaseSessionImpl.java:718)
    at org.eclipse.persistence.sessions.server.ServerSession.logout(ServerSession.java:625)
    at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.removeSessionFromGlobalSessionManager(EntityManagerSetupImpl.java:138)
    at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.undeploy(EntityManagerSetupImpl.java:1286)
    at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.close(EntityManagerFactoryImpl.java:83)
    at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.finalize(EntityManagerFactoryImpl.java:137)
    at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
    at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
    at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
    at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
    Caused by: java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
    at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:273)
    at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
    at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:306)
    at sun.rmi.registry.RegistryImpl_Stub.unbind(Unknown Source)
    at java.rmi.Naming.unbind(Naming.java:135)
    at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.removeLocalConnection(RMITransportManager.java:226)
    ... 12 more
    Caused by: java.net.SocketTimeoutException: Read timed out
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:129)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
    at java.io.DataInputStream.readByte(DataInputStream.java:241)
    at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:215)
    ... 17 more

    I'm working on getting RMI based cache coordination functioning in my application using Eclipselink 1. I am using the 'INVALIDATE_CHANGED_OBJECTS' annotation and trying to get changed objects to propigate across 2 servers. I am using a function I got from the eclipselink list:
    public void customize(Session session) throws Exception {
    AbstractSession sessionImpl = (AbstractSession) session;
    RemoteCommandManager cm = new RemoteCommandManager(sessionImpl);
    cm.setShouldPropagateAsynchronously(true);
    cm.getDiscoveryManager().setAnnouncementDelay(10);
    cm.getTransportManager().setNamingServiceType(
    TransportManager.REGISTRY_NAMING_SERVICE);
    cm.setUrl("rmi://localhost:8881");
    cm.setServerPlatform(sessionImpl.getServerPlatform());
    sessionImpl.setCommandManager(cm);
    sessionImpl.setShouldPropagateChanges(true);
    cm.initialize();
    try {
    Thread.sleep(2000);
    } catch (Exception ignore) {
    and getting my factories as such:
    emf = Persistence.createEntityManagerFactory(s);
    new RMICacheCoordinationConfig().customize(JpaHelper.getServerSession(emf));
    em = emf.createEntityManager();
    After I make a few calls, I get several stack traces related to RMI I am fairly new to Toplink/Eclipselink and have not done much in the way of RMI.
    Here are the exceptions:
    [EPS Warning]: 2007.11.30 11:02:16.972--ServerSession(31985466)--Thread(Thread[Thread-8,5,main])--Local Exception Stack:
    Exception [EclipseLink-22102] (Eclipse Persistence Services - 1.0M1 (Build 20071105)): org.eclipse.persistence.exceptions.RemoteCommandManagerException
    Exception Description: Could not post connection in local naming service under name rmi://localhost:8881/13598682 Internal Exception: java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
    at org.eclipse.persistence.exceptions.RemoteCommandManagerException.errorBindingConnection(RemoteCommandManagerException.java:84)
    at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.createLocalConnectionInRegistry(RMITransportManager.java:157)
    at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.createLocalConnection(RMITransportManager.java:110)
    at org.eclipse.persistence.sessions.coordination.DiscoveryManager.run(DiscoveryManager.java:194)
    at java.lang.Thread.run(Thread.java:595)
    Caused by: java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
    at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:273)
    at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
    at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:306)
    at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
    at java.rmi.Naming.rebind(Naming.java:160)
    at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.createLocalConnectionInRegistry(RMITransportManager.java:154)
    ... 3 more
    Caused by: java.net.SocketTimeoutException: Read timed out
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:129)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
    at java.io.DataInputStream.readByte(DataInputStream.java:241)
    at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:215)
    ... 8 more
    Exception in thread "Thread-8" Local Exception Stack:
    Exception [EclipseLink-22102] (Eclipse Persistence Services - 1.0M1 (Build 20071105)): org.eclipse.persistence.exceptions.RemoteCommandManagerException
    Exception Description: Could not post connection in local naming service under name rmi://localhost:8881/13598682 Internal Exception: java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
    at org.eclipse.persistence.exceptions.RemoteCommandManagerException.errorBindingConnection(RemoteCommandManagerException.java:84)
    at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.createLocalConnectionInRegistry(RMITransportManager.java:157)
    at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.createLocalConnection(RMITransportManager.java:110)
    at org.eclipse.persistence.sessions.coordination.DiscoveryManager.run(DiscoveryManager.java:194)
    at java.lang.Thread.run(Thread.java:595)
    Caused by: java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
    at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:273)
    at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
    at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:306)
    at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
    at java.rmi.Naming.rebind(Naming.java:160)
    at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.createLocalConnectionInRegistry(RMITransportManager.java:154)
    ... 3 more
    Caused by: java.net.SocketTimeoutException: Read timed out
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:129)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
    at java.io.DataInputStream.readByte(DataInputStream.java:241)
    at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:215)
    ... 8 more
    [EPS Warning]: 2007.11.30 11:03:17.594--ServerSession(31985466)--Thread(Thread[Finalizer,8,system])--Local Exception Stack:
    Exception [EclipseLink-22107] (Eclipse Persistence Services - 1.0M1 (Build 20071105)): org.eclipse.persistence.exceptions.RemoteCommandManagerException
    Exception Description: Could not remove local connection in local naming service under name rmi://localhost:8881/13598682 Internal Exception: java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
    at org.eclipse.persistence.exceptions.RemoteCommandManagerException.errorUnbindingLocalConnection(RemoteCommandManagerException.java:137)
    at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.removeLocalConnection(RMITransportManager.java:234)
    at org.eclipse.persistence.sessions.coordination.TransportManager.discardConnections(TransportManager.java:432)
    at org.eclipse.persistence.sessions.coordination.RemoteCommandManager.shutdown(RemoteCommandManager.java:179)
    at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.logout(DatabaseSessionImpl.java:718)
    at org.eclipse.persistence.sessions.server.ServerSession.logout(ServerSession.java:625)
    at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.removeSessionFromGlobalSessionManager(EntityManagerSetupImpl.java:138)
    at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.undeploy(EntityManagerSetupImpl.java:1286)
    at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.close(EntityManagerFactoryImpl.java:83)
    at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.finalize(EntityManagerFactoryImpl.java:137)
    at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
    at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
    at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
    at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
    Caused by: java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
    at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:273)
    at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
    at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:306)
    at sun.rmi.registry.RegistryImpl_Stub.unbind(Unknown Source)
    at java.rmi.Naming.unbind(Naming.java:135)
    at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.removeLocalConnection(RMITransportManager.java:226)
    ... 12 more
    Caused by: java.net.SocketTimeoutException: Read timed out
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:129)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
    at java.io.DataInputStream.readByte(DataInputStream.java:241)
    at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:215)
    ... 17 more

  • RMI Experts - I cannot connect to server, but connected clients STILL RUN

    I am pulling my hair out, I have 4 identical RMI servers running on RH linux 7.0, JDK1.3. The client is a signed java applet that runs with the JRE1.3 under windows. It binds to each of the 4 servers, and unbinds from the 3 with the most clients connected for load balancing and failover.. The servers are set up as:
    rmi://12.34.56.78:1099/server1
    rmi://12.34.56.78:1098/server2
    rmi://12.34.56.78:1097/server3
    rmi://12.34.56.78:1096/server4
    I am using different ports AND server names, I find that the client confuses things if you don't..
    The problem started when I re-deployed the applet, but it didn't work, so I put the OLD version back out there. NO SERVER SIDE changes at all, and the applet that has been working for months is now the same exact jar file.
    Here's what's happenning: When I look up all 4 servers, 3 are giving me 'No Name Space', even though I'm positive the code is correct. NEW connections are not being allowed, but clients that are ALREADY connected still run perfectly. It's ALWAYS 3 out of 4 servers down, the 4th one NEVER crashes.. When I re-start the server app, it runs for about 3 minutes and crashes again.
    The result is the client only sees one server up and EVERYONE connects to it.. There are about 250 simultaneous connections, and one server cannot handle all this computation..
    PLEASE HELP!
    Doug

    I'm not sure why you care about the connections once
    you have chosen the one you want to keep. You didn't
    say how your servers really know about the number of
    active connections, but if you implement your own
    connect/disconnect on top of RMI, then you should be
    able to keep your connection counts straight.Well, I just assumed that the connections would stay there, but after some testing, it doesn't look like that's the case at all.. In fact, unless you are calling methods, there are NO TCP connections being maintained to the server at all.. 'netstat -a' on the linux server says there is nothing at all when the client app is idle..
    I have a method on the server that gets called by the clients once every couple min's with the user's IP, login, and which app the are using.. The server keep a table of who's logged in (ie, who it's receiving these method calls from), so it konws who's logged in at any given time.. When a user closes the app, this method gets called with some different arguements, then the server removes that entry from the table..
    The server checks it's table every so often and flags a field as 'false' every so often.. The client is responsible for calling this method which changes it back to 'true'. The server checks less frequently than the clients call this method, so if the server checks, and the flag is already false, that means the client app closed and didn't notify the server (ie, power failure, process killed, etc..), so the server has a means of timing out users however frequently you set it up for..
    I have it set up so the client calls the server method every 5 minutes, and the server checks every 10. It works perfectly and there's hardly any overhead at all.. Even with 400 people (which is the highest peak) on the system (across 4 servers), you can't notice a performance decrease at all.. The load is being balanced something like 98 / 102 / 105 / 96, and before this setup it was more like 40 / 153 / 143 / 70.. So it's well worth it..

Maybe you are looking for