[
https://jira.jboss.org/jira/browse/JGRP-1153?page=com.atlassian.jira.plug...
]
Björn Kautler commented on JGRP-1153:
--------------------------------------
Unfortunately not, at least not with my setup, as ehcache-jgroupsreplication 1.3 isn't
compatible with 2.8+. It gets the local address and casts it unconditionally to Ip which
will not work with 2.8+ where UUID is the default address.
Shared transport badly broken
-----------------------------
Key: JGRP-1153
URL:
https://jira.jboss.org/jira/browse/JGRP-1153
Project: JGroups
Issue Type: Bug
Affects Versions: 2.7
Environment: EHCache 1.7.2
ehcache-jgroupsreplication 1.3
JGroups 2.7.0.GA
Reporter: Björn Kautler
Assignee: Bela Ban
Fix For: 2.10
I tried to use JGroups with a shared transport (while using only one JChannel, the one
EHCache uses for replication). At ProtocolStack.java:719 the TP.ProtocolAdapter is added
to the protocol stack when a shared transport is used. This leads to problems after
shunning. When the JChannel.CloserThread tries in line 2018 to reopen the JChannel, the
Protocol Stack is recreated. But now the TP$ProtocolAdapter is part of the protocol stack
and thus of the config string created from the protocol stack at JChannel:327. As the
ProtocolAdapter does not have a default constructor, the whole thing explodes at
Configurator:732 where the newInstance() call of course fails while the ProtocolAdapter
probably shouldn't be in the protocol stack anyway at this point in time. I guess it
would be added a second time at ProtocolStack.java:719 then. Also after disabling the
shared transport it seems that the problem I was able to reproduce halfway reliably
through restarting both instances simultaneously doesn't arise again without shared
transport.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira