Bug #2523

Copying a participantConfig results in odd behaviour in java

Added by T. Huxohl about 8 years ago. Updated about 8 years ago.

Status:ResolvedStart date:03/16/2016
Priority:NormalDue date:
Assignee:J. Wienke% Done:

100%

Category:Java
Target version:rsb-0.13

Description

We tried to use in process communication and therefore disabled all other transports in the participantConfig.
This works as long as the participantConfig is not copied. After copying it seems like the informer tries to establish a spread connection.
The following code example with the resulting exception demonstrates this.

Code:

ParticipantConfig config = Factory.getInstance().getDefaultParticipantConfig();
config = config.copy();

for (TransportConfig transport : config.getEnabledTransports()) {
            transport.setEnabled(false);
}
config.getOrCreateTransport("inprocess").setEnabled(true);

Informer<Object> informer = Factory.getInstance().createInformer("/test", config);
informer.activate();
informer.send("TestString");

Exception:

Mar 16, 2016 4:33:10 PM rsb.transport.spread.SpreadWrapperImpl makeConnection
WARNING: reoccuring SpreadException during connect to daemon
spread.SpreadException: Socket(): java.net.ConnectException: Connection refused
    at spread.SpreadConnection.connect(SpreadConnection.java:876)
    at rsb.transport.spread.SpreadWrapperImpl.makeConnection(SpreadWrapperImpl.java:146)
    at rsb.transport.spread.SpreadWrapperImpl.activate(SpreadWrapperImpl.java:261)
    at rsb.transport.spread.SpreadReceiver$StateInactive.activate(SpreadReceiver.java:220)
    at rsb.transport.spread.SpreadReceiver.activate(SpreadReceiver.java:342)
    at rsb.transport.spread.SpreadInPushConnector.activate(SpreadInPushConnector.java:77)
    at rsb.eventprocessing.RouteConfiguratorUtility.activate(RouteConfiguratorUtility.java:87)
    at rsb.eventprocessing.DefaultPushInRouteConfigurator.activate(DefaultPushInRouteConfigurator.java:64)
    at rsb.Listener$ListenerStateInactive.activate(Listener.java:118)
    at rsb.Listener.activate(Listener.java:168)
    at rsb.introspection.ProtocolHandler.activate(ProtocolHandler.java:387)
    at rsb.introspection.IntrospectionParticipantObserver.created(IntrospectionParticipantObserver.java:89)
    at rsb.Factory$ParticipantObserverManager.notifyParticipantCreated(Factory.java:104)
    at rsb.Participant.activate(Participant.java:85)
    at rsb.Informer.access$401(Informer.java:52)
    at rsb.Informer$InformerStateInactive.activate(Informer.java:100)
    at rsb.Informer.activate(Informer.java:217)
    at org.dc.jul.extension.rsb.com.RSBCommunicationServiceTest.testInProcessCommunication(RSBCommunicationServiceTest.java:168)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:45)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
    at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
    at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
    at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
    at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)

Associated revisions

Revision 2c8e8307
Added by J. Wienke about 8 years ago

Test ParticipantConfig copies are separated

Ensure that ParticipantConfig are really separated and do not influence
each other.

refs #2523

Revision 981a59e0
Added by J. Wienke about 8 years ago

ParticipantConfig.copy: include introspection status

fixes #2523

Revision 76a1835f
Added by J. Wienke about 8 years ago

ParticipantConfig.copy: include introspection status

refs #2523

(cherry picked from commit 981a59e03ce4dd89d4675077a29f66a3a0ad55e6)

History

#1 Updated by J. Wienke about 8 years ago

  • Description updated (diff)
  • Category set to Java

#2 Updated by J. Wienke about 8 years ago

I can't find any clue that the copy operation of ParticipantConfig is the reason. I just added a unit test which checks that copies are really separated.

Which version are you using?

#3 Updated by J. Wienke about 8 years ago

  • Status changed from New to In Progress
  • Assignee set to J. Wienke

#4 Updated by J. Wienke about 8 years ago

Additionally, could you please try to reproduce this with an isolated executable. The backtrace implies that this happens in a complex unit test. Please check whether this can be reproduced in a more simple setup.

#5 Updated by T. Huxohl about 8 years ago

We are currently using the version on the branch origin/wip-listener-pooling-0.12

And as the backtrace implies this happens in a unit test. But the test just executes the code displayed in this issue and fails due to the thrown exception.

#6 Updated by J. Wienke about 8 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

#7 Updated by J. Wienke about 8 years ago

  • Target version set to rsb-0.13

There was one minor bug in the sense that the introspection status was not copied with the config, which will then always enable introspection. Depending on you local configuration this might however still appear as is, if you do want to have introspection in the unit tests. In that case, the global configuration is assumed for the introspection participants and not your modified one, which will likely be spread in your case.

Also available in: Atom PDF