+++ This bug was initially created as a clone of Bug #1132190 +++ Description of problem: JGroupsBroadcastGroupConfiguration is not serializable. That means if you used JGroups config on a connection factory, its serialization will be broken and the client won't be able to use it causing marshaling exceptions on the server. Version-Release number of selected component (if applicable): How reproducible: Always: Steps to Reproduce: 1.Configure JGroups on cluster Discovery 2.Create a connection factory and try to make a remote lookup 3. Actual results: SerializationExceptions Expected results: Additional info: This is a very minimal change. Just adding serialization declarations to the class.
I still can see problems with serialization when I configure discovery using JGroups in connection factory: 16:33:19,833 Thread-0 ERROR [org.jboss.qa.hornetq.apps.clients.ProducerTransAck:146] Producer got exception and ended: org.jboss.naming.remote.protocol.NamingIOException: Failed to lookup [Root exception is java.io.NotSerializableException: org.jboss.as.clustering.jgroups.MuxChannel] at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:49) at org.jboss.naming.remote.protocol.v1.Protocol$1.execute(Protocol.java:104) at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1.lookup(RemoteNamingStoreV1.java:95) at org.jboss.naming.remote.client.HaRemoteNamingStore$1.operation(HaRemoteNamingStore.java:275) at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:137) at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:271) at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79) at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83) at javax.naming.InitialContext.lookup(InitialContext.java:392) at org.jboss.qa.hornetq.apps.clients.ProducerTransAck.run(ProducerTransAck.java:74) Caused by: java.io.NotSerializableException: org.jboss.as.clustering.jgroups.MuxChannel at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:892) at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1064) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1020) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:886) at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1064) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1020) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:886) at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:65) at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:56) at org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:50) at org.jboss.marshalling.river.RiverObjectOutputStream.writeObjectOverride(RiverObjectOutputStream.java:179) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:343) at org.hornetq.api.core.DiscoveryGroupConfiguration.writeObject(DiscoveryGroupConfiguration.java:149) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:271) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1008) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:886) at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1064) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1020) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:886) at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1064) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1020) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:999) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:886) at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:58) at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:111) at org.jboss.naming.remote.protocol.v1.Protocol$1$2.write(Protocol.java:138) at org.jboss.naming.remote.protocol.v1.WriteUtil.write(WriteUtil.java:61) at org.jboss.naming.remote.protocol.v1.Protocol$1.handleServerMessage(Protocol.java:128) at org.jboss.naming.remote.protocol.v1.RemoteNamingServerV1$MessageReciever$1.run(RemoteNamingServerV1.java:73) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: an exception which occurred: in field val$channel in field factory in field discoveryGroupConfiguration in field serverLocator in object org.hornetq.jms.client.HornetQJMSConnectionFactory@57e19e66 Attaching standalone-full-ha.xml.
Created attachment 931991 [details] standalone-full-ha.xml
ok, it's a minor issue.. not need to re-issue the release because of that... Should we open a new issue or move this next version?
Hi, The fix for serialization problem should be in hornetq 2.3.21. However the EAP 6.3 I downloaded includes 2.3.20. Howard
Please ignore my last comment. I'll test again using the new version.
The problem is that that the discovery group references a runtime jgroups stack in EAP <discovery-groups> <discovery-group name="dg-group1"> <jgroups-stack>udp</jgroups-stack> <jgroups-channel>udp</jgroups-channel> <refresh-timeout>10000</refresh-timeout> </discovery-group> </discovery-groups> So when creating a Connection Factory a runtime JChannel object is created and referenced by, and because this JChannel is not serializable, the excpetion. The fix for HornetQ-1389 only works for static jgroups config files, which seems not available in EAP. Let me think about how to deal with it properly. Thanks Howard
If I understood the issue correctly, the issue is with a client looking up a Connection Factroy from EAP which uses JGroups for its discovery group, right? If that's the case (and we want to support that setup), we also need to ensure that JGroups libs are part of the JMS BOM included in our client jar.
Jeff you are right. clients use that kind of Connection Factory need jgroups. I think it's already in the jboss-client.jar. Is that what you mean by JMS BOM? Howard
Hi, I've taken a look at this issue, and it appears it is standing still because Howard Goa PR was denied: https://github.com/jbossas/jboss-eap/pull/1640 Howard fix was deemed "hacky" and therefore the PR was never merged in the branch. I'm looking at the PR right now, to see if I can help solving the issue and got it to be merged.
We decide not to fix it. The new feature (URI connection format) in Artemis will solve this issue but unfortunately this feature cannot be ported back to hornetq.