[CONTROLLER-136] Remote RPC Broker fails configuration transaction if clustering table service is not started. Created: 24/Jan/14  Updated: 25/Jul/23  Resolved: 25/Jan/14

Status: Resolved
Project: controller
Component/s: mdsal
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Tony Tkacik Assignee: Abhishek Kumar
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC

Issue Links:
Blocks
blocks CONTROLLER-120 Restconf not finding the yang models. Resolved
External issue ID: 362
Priority: Highest

 Description   

Remote RPC Broker, requires runtime dependency not managed by config subsystem
which is clustered rpc routing table.

In second phase of commit - when all the verification should be done,
remote-rpc broker throws an exception if routing table is still not available (this one is activated by Felix DM), which tears down whole transaction and config subsystem and prevents logging.

This bug was present before, but was not seen, before performance fix was
applied to MD-SAL startup, which now gets initialized faster then original clustering service.

Remote RPC Broker should postpone it's operations till table is available,
not fail to start without table.

For now Remote RPC Broker is moved to separate transaction
https://git.opendaylight.org/gerrit/#/c/4698/1
to not prevent MD-SAL from starting.

Exception:
ava.lang.NullPointerException: null
at java.lang.StringBuilder.<init>(StringBuilder.java:109) ~[na:1.7.0_21]
at org.opendaylight.controller.sal.connector.remoterpc.ServerImpl.<init>(ServerImpl.java:79) ~[na:na]
at org.opendaylight.controller.config.yang.md.sal.remote.rpc.ZeroMQServerModule.createInstance(ZeroMQServerModule.java:49) ~[na:na]
at org.opendaylight.controller.config.yang.md.sal.remote.rpc.AbstractZeroMQServerModule.getInstance(AbstractZeroMQServerModule.java:107) ~[na:na]
at org.opendaylight.controller.config.manager.impl.ConfigTransactionControllerImpl.secondPhaseCommit(ConfigTransactionControllerImpl.java:381) ~[bundlefile:na]
at org.opendaylight.controller.config.manager.impl.ConfigRegistryImpl.secondPhaseCommit(ConfigRegistryImpl.java:264) [bundlefile:na]
at org.opendaylight.controller.config.manager.impl.ConfigRegistryImpl.commitConfig(ConfigRegistryImpl.java:208) [bundlefile:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_21]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_21]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_21]
at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_21]
at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:192) [na:1.7.0_21]

 Comments   
Comment by Abhishek Kumar [ 24/Jan/14 ]

From the stack trace and looking into the code, it looks like Remote RPC Broker failed to start because it could not acquire host IP address.

There are 2 things I can do:
1. Move the code of acquiring the IP address from constructor to onSessionInitiated(). Is it ok to throw RuntimeException here?

2. I eat the exception, log error message.

I prefer 1st approach as opposed to silently dying in the 2nd approach.

Also, how did we conclude that the failure is due to missing routing table?

Comment by Abhishek Kumar [ 24/Jan/14 ]

Per discussion with Ed Warnicke, we are taking 2nd approach. I have created a tracking defect (https://bugs.opendaylight.org/show_bug.cgi?id=366) to revisit the issue and fix it properly.

Generated at Wed Feb 07 19:52:17 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.