[jboss-jira] [JBoss JIRA] Updated: (JGRP-1153) Shared transport badly broken

[Bela Ban (JIRA)]

     [ https://jira.jboss.org/jira/browse/JGRP-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1153:
---------------------------

    Fix Version/s: 2.10


> 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