This page last changed on Feb 05, 2011 by kurrazyman.

I have noticed on occasions that multiple threads are created for the same sensor, here's the standard output that appears showing the threads being created using the same sensor ID:

INFO: Starting Servlet Engine: Apache Tomcat/6.0.18
------------- CALIMERO PATCH A -------------------------
------------- CALIMERO PATCH A -------------------------
 -------- Started thread for sensor 9 custom org.openremote.controller.protocol.telnet.TelnetCommand@1c63e8c
 -------- Started thread for sensor 9 custom org.openremote.controller.protocol.telnet.TelnetCommand@1c63e8c
 -------- Started thread for sensor 9 custom org.openremote.controller.protocol.telnet.TelnetCommand@e7b3f2
05-Feb-2011 23:18:02 org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
05-Feb-2011 23:18:02 org.apache.catalina.startup.Catalina start
INFO: Server startup in 9503 ms

Any ideas before I go digging in the code?

Rich

Yes the controller definitely has issues with concurrency in its current Alpha 11 iteration (messy implementation) – I haven't gotten far enough yet with my cleanup to chase after this one, so feel free to go after it if you fancy.

Marcus sent a similar report which I suspect might be related:

I just downloaded the controller Alpha11 source to start on my 1-wire stuff and realized that the KNXConnectionManager is started twice. This is done because InitCachedStatusDBListener is calling SpringContext.getInstance() which results in a context initialization if the context is not initilized. But the ContextLoaderListener is also initializing the context. I don't know if this might be a problem. Maybe the KNXConnectionManager has to be able to realize that he was started already or the SpringContext should not be initiliazed twice??

Posted by juha at Feb 07, 2011 07:42

I thought the only place the pollingMachineThreads were instantiated was from the InitCachedStatusDBListener -> PollingMachinesService not from the web.xml definition as well.

Posted by kurrazyman at Feb 07, 2011 08:38

I have tracked down the cause of these duplicate sensor thread messages. They are being generated by the quartz scheduler XMLChangeListener which fires every 15s. It seems that when the controller first starts up the first time this scheduler fires it thinks the controller.xml file has changed (because it's comparing the controller.xml to an empty string) and so it refreshes the controller by running the following commands:

         killAndClearPollingMachineThreads();
         clearChangedStatusTable();
         clearStatusCache();
         clearAndReloadSensors();
         restartPollingMachineThreads();
         success = true;

This causes the Polling Threads to be killed and created again, which produces the first duplicate message. The next time the scheduler runs it thinks the panel.xml file has changed (same reason as the controller.xml) and so it once again refreshes the controller.

I am going to look into a solution for this.

Posted by kurrazyman at Feb 19, 2011 16:27

Richard,

Thank you for investigating and the update on this issue.

– Juha

Posted by juha at Feb 20, 2011 21:31

I have fixed the issue in my connection manager branch using the following change to the isObservedXMLContentChanged method in ControllerXMLChangeServiceImpl:

   private boolean isObservedXMLContentChanged(String observedXMLFileName) {
      //if changed, save the latest controller.xml.
      String observedXMLFilePath = PathUtil.addSlashSuffix(ConfigFactory.getCustomBasicConfigFromDefaultControllerXML().getResourcePath()) + observedXMLFileName;
      File observedXMLFile = new File(observedXMLFilePath);
      StringBuffer fileContent = new StringBuffer();
      String oldXMLFileContent = new String();
      if (Constants.CONTROLLER_XML.equals(observedXMLFileName)) {
         oldXMLFileContent = gatewayManagerService.getControllerXMLFileContent();
      } else if (Constants.PANEL_XML.equals(observedXMLFileName)) {
         oldXMLFileContent = gatewayManagerService.getPanelXMLFileContent();
      }
      try {
         fileContent.append(FileUtils.readFileToString(observedXMLFile, "utf-8"));
      } catch (IOException ioe) {
         logger.warn("Skipped " + observedXMLFileName + " change check, Failed to read " + observedXMLFile.getAbsolutePath());
         return false;
      }
      if (oldXMLFileContent.equals(fileContent.toString()) || oldXMLFileContent.length() == 0) {
         return false;
      }
      return true;
   }

I have also looked at the duplicate 'Calimero Patch A' message that appears at start up and this isn't related to the KNXConnectionManager code as far as I can see but is something internal to the calimero-2.0a4-PATCH-A.jar file that is loaded by tomcat at start up from WEB-INF/libs before any of the controller code 'kicks' in.

Posted by kurrazyman at Feb 20, 2011 21:57
Document generated by Confluence on Jun 05, 2016 09:30