Announcement Announcement Module
No announcement yet.
Spring JMX JSR-160 Connector: non-JRMP server at remote endpoint Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring JMX JSR-160 Connector: non-JRMP server at remote endpoint

    I have a working configuration for Windows XP. I can use the JDK 6 jconsole to connect with credentials, and inspect my beans, invoke methods, everything I need/want.

    If I try to run the same configuration on a Linux machine, when the ConnectorServerFactoryBean runs, it throws an exception, the underlying exception of which is "non-JRMP server at remote endpoint".

    A lot of searching suggests that one end is RMI and the other is RMI/SSL. That is all I have come up with. A snippet of the configuration:

    <bean id="serverConnector"
    class=" rverFactoryBean">
    <property name="objectName" value="connector:name=myapp"/>
    <property name="serviceUrl"

    I am using Spring to export services over RMI already, so I am relying on
    the RMI registry to be on port 1099; if I comment out the JMX connector
    beans from my configuration, the rest of my app works great. I just cannot
    get this connector to start up on Linux -- again, it works fine on XP.

    Does anyone have a suggestion about why this exception is being thrown?


  • #2
    Simply listing RMI Registry contents fails with same error message

    I should probably note that the Spring version in use is 2.5.5, and the JDK is 1.6.07.

    I have done a bit more work here. This project has a stand-alone Spring container exposing services through RMI. The java process running Spring comes up OK, only complaining about the creation of the JMX Connector.

    The client programs in this project call services over RMI, and that all works fine. So I wrote a tiny client that does not use Spring to list what's in the RMI registry, and I am running this from a remote machine (the same machine where the other Spring clients work OK):

    import java.rmi.registry.LocateRegistry;
    import java.rmi.registry.Registry;
    public class RmiClient {
        public static void main(String args[]) {
            try {
                String hostName = "";
                Registry registry = LocateRegistry.getRegistry(hostName, 1099);
                String[] names = registry.list();
                for (String name : names) {
            } catch (Exception e) {
    and it spits out an exception:

    java.rmi.ConnectIOException: non-JRMP server at remote endpoint
        at sun.rmi.transport.tcp.TCPChannel.createConnection(
        at sun.rmi.transport.tcp.TCPChannel.newConnection(
        at sun.rmi.server.UnicastRef.newCall(
        at sun.rmi.registry.RegistryImpl_Stub.list(Unknown Source)
        at test.RmiClient.main(
    and this is exactly the same message I am getting at Spring start-up from the ConnectorServerFactoryBean.

    So I am left to wonder how my other clients, which use Spring, are able to make a connection to the services running on my server.


    • #3
      Linux version affects function of ConnectorServerFactoryBean

      So I have tried a different Linux server, and the ConnectorServerFactoryBean starts up OK there. Here is what I have:

      Windows XP: OK
      Linux (Red Hat Enterprise Linux ES release 4 (Nahant Update 1)): OK
      Linux (Red Hat Enterprise Linux WS release 3 (Taroon Update 9)): BAD

      My trivial listing client from the earlier post has no problem contacting the RMI Registry that Spring fires up on Windows XP or Red Hat ES 4. But it gets the non-JRMP server error when the RMI Registry is running on Red Hat WS 3.

      At this point, I don't see anything to do on the Spring side with regards to configuration -- just don't use Red Hat WS 3. Hopefully this helps someone else at some point.


      • #4
        Shouldn't you use

        <property name="objectName" value="connector:name=rmi"/>


        • #5
          Operating System upgrade fixes problem

          I could use that, but it would not change the situation.

          I have since upgraded the computer in question to Red Hat 4, and the problem no longer occurs when the container starts.