Closed danbim closed 12 years ago
This only happens if a user was already connected to the testbed, i.e. if there's an active connection to an experiment.
Still an issue it seems...
The error seems to be linked to the fact that WSNApp tries to reconfigure the default pipeline on the gateway hosts when they are already down, resulting in a timeout. From the logs...
TERM trapped. Shutting down.
2012-07-24 14:51:43,629 | Shutdown-Thread | IWSN | INFO | Stopping IWSN...
2012-07-24 14:51:43,631 | Shutdown-Thread | SessionManagementSoapService | INFO | Stopped Session Management service on http://wisebed.itm.uni-luebeck.de:8888/sessions
2012-07-24 14:51:43,631 | Shutdown-Thread | WSNSoapService | INFO | Stopping WSN service SOAP API...
2012-07-24 14:51:43,635 | Shutdown-Thread | WSNSoapService | INFO | Stopped WSN service SOAP API on http://wisebed.itm.uni-luebeck.de:8888/wsn/DC32D9E2352DC4B248C620AEC63FD530
2012-07-24 14:51:43,635 | Shutdown-Thread | WSNServiceImpl | INFO | Stopping WSN service...
2012-07-24 14:51:43,638 | Shutdown-Thread | WSNServiceImpl | INFO | Stopped WSN service!
2012-07-24 14:51:43,638 | Shutdown-Thread | WSNApp | INFO | Stopping WSNApp...
2012-07-24 14:51:43,638 | Shutdown-Thread | WSNApp | INFO | Setting ChannelPipeline to default configuration for all nodes...
2012-07-24 14:51:53,640 | Shutdown-Thread | WSNApp | ERROR | {}
java.util.concurrent.ExecutionException: de.uniluebeck.itm.tr.iwsn.overlay.messaging.reliable.ReliableMessagingTimeoutException
at com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:289)
at com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:276)
at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:111)
at de.uniluebeck.itm.tr.runtime.wsnapp.WSNAppImpl.setDefaultPipelineOnReservedNodes(WSNAppImpl.java:1266)
at de.uniluebeck.itm.tr.runtime.wsnapp.WSNAppImpl.doStop(WSNAppImpl.java:527)
at com.google.common.util.concurrent.AbstractService.stop(AbstractService.java:115)
at com.google.common.util.concurrent.AbstractService.stopAndWait(AbstractService.java:134)
at de.uniluebeck.itm.tr.runtime.portalapp.WSNServiceHandle.stop(WSNServiceHandle.java:98)
at de.uniluebeck.itm.tr.runtime.portalapp.SessionManagementServiceImpl.freeInternal(SessionManagementServiceImpl.java:493)
at de.uniluebeck.itm.tr.runtime.portalapp.SessionManagementServiceImpl.stop(SessionManagementServiceImpl.java:195)
at de.uniluebeck.itm.tr.runtime.portalapp.PortalServerApplication.doStop(PortalServerApplication.java:119)
at com.google.common.util.concurrent.AbstractService.stop(AbstractService.java:115)
at com.google.common.util.concurrent.AbstractService.stopAndWait(AbstractService.java:134)
at de.uniluebeck.itm.tr.iwsn.IWSNApplicationManager.stop(IWSNApplicationManager.java:273)
at de.uniluebeck.itm.tr.iwsn.IWSNImpl.stop(IWSNImpl.java:76)
at de.uniluebeck.itm.tr.iwsn.IWSNServer$1.run(IWSNServer.java:190)
at java.lang.Thread.run(Thread.java:662)
The issue is not really an issue. The deployment scripts assume a certain timeout until they consider the stopping of IWSN failed. The actual timeouts that are hit when shutting down the IWSN portal after or concurrently with the IWSN gateways seem to be higher. Therefore only the deployment scripts show an error, the IWSN portal are finely stopped.
In order to find a cleaner solution I'll not close this ticket but move it to the next milestone...
From the log files