Re: RMIJRMPServerImpl

Bordet, Simone a écrit :

>Hi, 
>
>  
>
Hi Simon,

Here is a solution to our problem with JRMP and the UnicastRemoteObject 
class:
If replaceing the
    /UnicastRemoteObject.export(obj, port, clientFactory, 
serverFactory)/ call
with
    /UnicastRemoteObject.export(obj)/, or
    /UnicastRemoteObject.export(obj, 0, clientFactory, serverFactory)/
than, we do not have the exception any more :-)

>>We have a problem related to the
>>javax.management.remote.rmi.RMIJRMPServerImpl class when 
>>creating a JSR 160 JMXConnectorServer in the JOnAS application server.
>>
>>This problem only occures in a particular configuration case 
>>- when trying to start a JOnAS server which does not start 
>>its own registry service, but uses (shares) the registry 
>>service of a previously started JOnAS server.
>>In this situation, when using *JRMP* protocol, the
>>RMIConnectorServer.start() fails, as the
>>RMIJRMPServerImpl.export() fails with a 
>>"java.net.BindException: Address already in use" exception.
>>However, in the same situation, when using *IIOP* protocol, 
>>everything goes well.
>>    
>>
>
>This is strange: Address already in use is not something that should happen.
>Can you please add details of the JMXServiceURLs you use, and of the addresses/ports of the JOnAS servers ?
>  
>
This is the details of the scenario:
- The first JOnAS server starts a registry on a port *P* (maybe 1099 or 
another, here 1962),
than starts a MBean server and creates a RMIConnectorServer which is 
started at     /service:jmx:rmi://host:1962/jndi/jrmpconnector_j1/.

- The second JOnAS servers starts and detects that registry is already 
started on *P*.
Than, it creates its MBean server and a RMIConnectorServer that has to 
be started at
/service:jmx:rmi://host:1962/jndi/jrmpconnector_j3/.

This fails with current code (exception Port already in use: 1962 - 
java.net.BindException: Address already in use)
but goes *ok* with one of the modifications described at the begining of 
my mail.
Note than, when looking to the objects binded in the registry, after the 
second server started, we can see that 2
objects are bound with the following names:
- jrmpconnector_j1
- jrmpconnector_j3
and this is fine !

>>When comparing the 2 implementations of RMIConnectorServer 
>>(RMIJRMPServerImpl and RMIIIOPServerImpl), we can see that 
>>the main difference consists in using UnicastRemoteObject in 
>>the JRMP case, and PortableRemoteObject in the IIOP case.
>>    
>>
>
>Yes.
>
>  
>
>>For us (in JOnAS), PortableRemoteObject is perfect as when 
>>executing the exportObject() method,
>>the proDelegate is checked, and in case its not null, then the
>>exportObject() is called on the proDelegate object. This is 
>>not the case with UnicastRemoteObject. Delegating the 
>>exportObject to proDelegate permits passing towards the JOnAS 
>>registry service, which is the desired behaviour for us.
>>    
>>
>
>Not following. I have always thought there is a delegate only when using IIOP.
>  
>
Yes its true. However, JOnAS includes a module called Carol 
(http://carol.objectweb.org/index.html)
which allows using different RMI implementations, and in Carol, stubs 
are exported over JRMP
by a specific delegate class 
(org.objectweb.carol.rmi.multi.JrmpPRODelegate).

>Otherwise, how can you tell PRO to export() over JRMP (the MX4J jars contains the stub for both JRMP and IIOP) ?
>
>  
>
Anyway, maybe we can resolve our problem (I hope) using 
UnicastRemoteObject.exportObject()
by replacing the use of a particular port number, with the use of a 
anonymous port.

Regards, Adriana




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl