RTC environment intermittently not updating to Build Forge builds
When using the Build Forge/RTC integration sometimes the RTC environment is not getting updated into the Build Forge builds. The ccm.log file does show occasional exceptions (see below). What is causing this and how can I fix it?
java.nio.channels.ClosedChannelException
at sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:157)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:346)
at com.buildforge.services.client.api.APIClientBuffer.flush(APIClientBuffer.java:139)
at com.buildforge.services.common.api.JsonProtocolImpl.writeFooter(JsonProtocolImpl.java:363)
at com.buildforge.services.client.api.APIClientConnection.call(APIClientConnection.java:581)
at com.buildforge.services.client.dbo.Build.updateBuildEnvEntryValue(Build.java:604)
at com.buildforge.services.client.dbo.Build.updateBuildEnvEntryValue(Build.java:581)
at com.ibm.rational.buildforge.team.internal.service.BuildForgeBuildLoopRunnable.handleEnvironmentUpdates(BuildForgeBuildLoopRunnable.java:506)
at com.ibm.rational.buildforge.team.internal.service.BuildForgeBuildLoopRunnable.startBuildForgeProject(BuildForgeBuildLoopRunnable.java:233)
at com.ibm.rational.buildforge.team.internal.service.BuildForgeBuildLoopRunnable.run(BuildForgeBuildLoopRunnable.java:171)
at com.ibm.rational.buildforge.team.internal.service.BuildForgeBuildLoopScheduledTask.runTask(BuildForgeBuildLoopScheduledTask.java:57)
at com.ibm.team.repository.service.async.AbstractAutoScheduledTask.executeTask(AbstractAutoScheduledTask.java:86)
at sun.reflect.GeneratedMethodAccessor208.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:618)
at org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.invoke(ExportProxyServiceRecord.java:370)
at org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.access$0(ExportProxyServiceRecord.java:356)
at org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord$ExportedServiceInvocationHandler.invoke(ExportProxyServiceRecord.java:56)
at $Proxy767.executeTask(Unknown Source)
at com.ibm.team.repository.service.internal.scheduler.AsynchronousTaskRunner.runTask(AsynchronousTaskRunner.java:136)
at com.ibm.team.repository.service.internal.scheduler.AsynchronousTaskRunner.run(AsynchronousTaskRunner.java:99)
at java.lang.Thread.run(Thread.java:811)
|
Accepted answer
|
The problem is a confluence of two problems. In 3.0.1.x there are some weak points in the code for retrying Build Forge API calls when the session has become invalid. The next question though is why is the session becoming invalid? What can stress the retry logic is if the Build Forge user that was used for the RTC/BF integration was used in multiple environments. For an idea of scale, the Build Forge user session by itself will last about 20 minutes. However if the user is used in two RTC environments, the RTC environment has two tasks that run every 15 seconds, so potentially you could invalidate the session more than 4 times a minute, which vastly increases the chances that the retry logic will fail. So to mitigate the problem, create another brand new user id in Build Forge and use that for the integration and see if that resolves the environment problem. If that does not work, the retry logic has been fixed as of 4.0, so upgrading will also prevent the issue.
Spencer Murata selected this answer as the correct answer
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.