Bug 1132196

Summary: [ENG] (6.3.z)JGroupsBroadcastGroupConfiguration Serialization Problem
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Jimmy Wilson <jawilson>
Component: HornetQAssignee: Romain Pelisse <rpelisse>
Status: CLOSED WONTFIX QA Contact: Miroslav Novak <mnovak>
Severity: unspecified Docs Contact: Russell Dickenson <rdickens>
Priority: unspecified    
Version: 6.3.0CC: bbaranow, chaowan, csuconic, dpospisi, hgao, istudens, jawilson, jmesnil, mnovak, msvehla, myarboro, rdickens, rpelisse
Target Milestone: ---Keywords: Triaged
Target Release: EAP 6.3.3   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1132190 Environment:
Last Closed: 2014-12-17 14:17:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1132190    
Bug Blocks: 1132169, 1151405    
Attachments:
Description Flags
standalone-full-ha.xml none

Description Jimmy Wilson 2014-08-20 21:20:25 UTC 
+++ 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.
Comment 3 Miroslav Novak 2014-08-28 14:34:48 UTC 
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.
Comment 4 Miroslav Novak 2014-08-28 14:35:49 UTC 
Created attachment 931991 [details]
standalone-full-ha.xml
Comment 5 Clebert Suconic 2014-08-28 14:37:03 UTC 
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?
Comment 6 Yong Hao Gao 2014-08-29 05:01:32 UTC 
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
Comment 7 Yong Hao Gao 2014-08-29 05:05:30 UTC 
Please ignore my last comment. I'll test again using the new version.
Comment 8 Yong Hao Gao 2014-08-29 08:09:59 UTC 
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
Comment 13 Jeff Mesnil 2014-09-04 09:51:44 UTC 
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.
Comment 14 Yong Hao Gao 2014-09-04 11:52:51 UTC 
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
Comment 18 Romain Pelisse 2014-12-09 15:44:20 UTC 
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.
Comment 23 Yong Hao Gao 2016-02-17 01:37:12 UTC 
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.