Uploaded image for project: 'JGroups'
  1. JGroups
  2. JGRP-1153

Shared transport badly broken

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Won't Do
    • Icon: Major Major
    • 2.10
    • 2.7
    • None
    • EHCache 1.7.2
      ehcache-jgroupsreplication 1.3
      JGroups 2.7.0.GA

      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.

              rhn-engineering-bban Bela Ban
              Vampire0 Björn Kautler
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved: