Uploaded image for project: 'AMQ Broker'
  1. AMQ Broker
  2. ENTMQBR-2146

Sync JGroups version between AMQ 7.2 and EAP 7.2 aka NoSuchMethodError: org.jgroups.JChannel.setReceiver when using JMS standalone client with jboss-client

    XMLWordPrintable

Details

    • Bug
    • Resolution: Obsolete
    • Major
    • None
    • AMQ 7.2.1.GA
    • broker-core
    • None
    • 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.
    • Hide

      Use reproducer from https://issues.jboss.org/browse/JBEAP-13196

      Show
      Use reproducer from https://issues.jboss.org/browse/JBEAP-13196

    Description

      This jira is about syncing JGroups version between EAP 7.2.x and AMQ 7.2.x.

      EAP 7.2.0.GA.CR1 is using JGroups 4.0.15.Final.
      AMQ 7.2.1 is using JGroups 3.6.13.Final.

      Can it be synced, please?

      Original jira issue:
      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

          clones

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-15733 NoSuchMethodError: org.jgroups.JChannel.setReceiver when using JMS standalone client with jboss-client

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed
          relates to

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-15460 MDB (Artemis 1.5.x RA) cannot connect to Artemis 2.x broker using JGroups discovery

          • Blocker - To be worked above all other priorities. This term is chosen when the severity of the issue is very high, has no workaround, or the effort for the change is comparatively low. Issues that may be very publicly visible and could generate significant media attention may also drive a higher priority.
          • Closed

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-4017 Remote JNDI lookup of connection factory with discovery group set in connection factory fails

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Activity

            People

              mtaylor1@redhat.com Martyn Taylor (Inactive)
              mnovak1@redhat.com Miroslav Novak
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: