Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-15733

NoSuchMethodError: org.jgroups.JChannel.setReceiver when using JMS standalone client with jboss-client

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Out of Date
    • Affects Version/s: 7.2.0.Beta
    • Fix Version/s: None
    • Component/s: Application Client, JMS
    • Labels:
      None
    • Target Release:
    • Steps to Reproduce:
      Show
      Use reproducer from https://issues.jboss.org/browse/JBEAP-13196
    • Workaround Description:
      Hide

      Workaround is to use Netty discovery machanism instead of JGroups discovery on standalone JMS client side which provides equivalent functionality - Configuration of EAP server should like:

              <subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
                  <server name="default" persistence-enabled="true" id-cache-size="20000">
      		...
                      <http-connector name="connector" socket-binding="http" endpoint="acceptor"/>		
                      <http-acceptor name="acceptor" http-listener="default"/>
      		...
                      <broadcast-group name="bg-group1" socket-binding="messaging-group" connectors="connector"/>
                      <discovery-group name="dg-group1" socket-binding="messaging-group"/>
                      <cluster-connection name="my-cluster" address="jms" connector-name="connector" check-period="30000" connection-ttl="60000" call-timeout="30000" discovery-group="dg-group1"/>
      		...
                      <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" discovery-group="dg-group1" ha="true" compress-large-messages="false" min-large-message-size="102400" block-on-acknowledge="true" retry-interval="2000" retry-interval-multiplier="1.0" reconnect-attempts="-1"/>
                  </server>
              </subsystem>
      	...
          <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">        
              <socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
      	...
          </socket-binding-group>
      </server>
      

      Client which looks up jms/RemoteConnectionFactory will be then able to connect to running Artemis cluster if it can listen of UDP broadcast on 231.7.7.7 by default.

      Show
      Workaround is to use Netty discovery machanism instead of JGroups discovery on standalone JMS client side which provides equivalent functionality - Configuration of EAP server should like: <subsystem xmlns= "urn:jboss:domain:messaging-activemq:4.0" > <server name= " default " persistence-enabled= " true " id-cache-size= "20000" > ... <http-connector name= "connector" socket-binding= "http" endpoint= "acceptor" /> <http-acceptor name= "acceptor" http-listener= " default " /> ... <broadcast-group name= "bg-group1" socket-binding= "messaging-group" connectors= "connector" /> <discovery-group name= "dg-group1" socket-binding= "messaging-group" /> <cluster-connection name= "my-cluster" address= "jms" connector-name= "connector" check-period= "30000" connection-ttl= "60000" call-timeout= "30000" discovery-group= "dg-group1" /> ... <connection-factory name= "RemoteConnectionFactory" entries= "java:jboss/exported/jms/RemoteConnectionFactory" discovery-group= "dg-group1" ha= " true " compress-large-messages= " false " min-large-message-size= "102400" block-on-acknowledge= " true " retry-interval= "2000" retry-interval-multiplier= "1.0" reconnect-attempts= "-1" /> </server> </subsystem> ... <socket-binding-group name= "standard-sockets" default - interface = " public " port-offset= "${jboss.socket.binding.port-offset:0}" > <socket-binding name= "messaging-group" port= "0" multicast-address= "${jboss.messaging.group.address:231.7.7.7}" multicast-port= "${jboss.messaging.group.port:9876}" /> ... </socket-binding-group> </server> Client which looks up jms/RemoteConnectionFactory will be then able to connect to running Artemis cluster if it can listen of UDP broadcast on 231.7.7.7 by default.

      Description

      Running JMS client with Jboss-client.jar produces the following stack trace:

      java.lang.NoSuchMethodError: org.jgroups.JChannel.setReceiver(Lorg/jgroups/Receiver;)V
          at org.apache.activemq.artemis.api.core.jgroups.JChannelWrapper.<init> (JChannelWrapper.java:55)
          at org.apache.activemq.artemis.api.core.jgroups.JChannelManager.getJChannel (JChannelManager.java:74)
          at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.initChannel (JGroupsBroadcastEndpoint.java:108)
          at org.apache.activemq.artemis.api.core.ChannelBroadcastEndpointFactory.createBroadcastEndpoint (ChannelBroadcastEndpointFactory.java:72)
          at org.apache.activemq.artemis.core.cluster.DiscoveryGroup.<init> (DiscoveryGroup.java:95)
          at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createDiscoveryGroup (ServerLocatorImpl.java:320)
          at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.initialize (ServerLocatorImpl.java:305)
          at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory (ServerLocatorImpl.java:749)
          at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal (ActiveMQConnectionFactory.java:835)
          at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createContext (ActiveMQConnectionFactory.java:304)
          at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createContext (ActiveMQConnectionFactory.java:297)
          at com.redhat.jboss.support.example.client.JGroupsDiscoveryConsumer.main (JGroupsDiscoveryConsumer.java:87)
          at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
          at java.lang.reflect.Method.invoke (Method.java:498)
          at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:282)
          at java.lang.Thread.run (Thread.java:748)
      

      Same application with wildfly-ejb-client-bom works correctly, main difference is that the om packages Artemis 1.5.5(jgroups 3.6.9.Final) and the Jboss-client packages Artemis 2.6.3(jgroups 3.6.13) version of jgroups inside the bom and the Jboss-client jar is the same 4.0.x. (bom was from 7.2.0.beta)

      Artemis 2.6.3 is compiled with jgroups 3.6.13 the Jboss-client packages jgroups 4.x

      jgroups 3.6.9.Final has two setReceiver methods
      jgroups 3.6.13 has one setReceiver
      jgroups 4.x has a one that does not match 3.6.13 signature.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              martyn-taylor Martyn Taylor (Inactive)
              Reporter:
              tmiyar Teresa Miyar Gil (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              13 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: