org.mule.umo.provider.ConnectorException: There is already a listener registered on this connector on endpointUri: jdbc://query. Connector that caused exception is: com.mirth.connect.connectors.jdbc.JdbcConnector@6c1194fa

Mirth Project | john voigt | 5 years ago
  1. 0

    While 2 channel were pulling for messages from the SQL database, the sql server did a restart and on the Mirth side there was an exception on two channels as noted in the log "Exception occurred in channel" java.sql.SQLException: I/O Error: Connection reset by peer: socket write error Query: SELECT top 1 [ID] as mid ,[RECEIVED_DATE] ,CAST(HL7_Transaction as varchar(MAX)) AS SOURCE_HL7 FROM [INTEGRATION_NEW_TRANSACTIONS] where PROCESSED_DATE is NULL ORDER BY [RECEIVED_DATE] asc Parameters: [] at org.apache.commons.dbutils.QueryRunner.rethrow(QueryRunner.java:542) at org.apache.commons.dbutils.QueryRunner.query(QueryRunner.java:399) at com.mirth.connect.connectors.jdbc.JdbcMessageReceiver.getMessages(JdbcMessageReceiver.java:266) at org.mule.providers.TransactedPollingMessageReceiver$1.doInTransaction(TransactedPollingMessageReceiver.java:91) at org.mule.transaction.TransactionTemplate.execute(TransactionTemplate.java:72) at org.mule.providers.TransactedPollingMessageReceiver.poll(TransactedPollingMessageReceiver.java:104) at org.mule.providers.PollingMessageReceiver.run(PollingMessageReceiver.java:97) at org.mule.impl.work.WorkerContext.run(WorkerContext.java:290) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575) at java.lang.Thread.run(Unknown Source) This was recorder on both channels. The sql recovered but after that point the messages were not being pulled. We stopped the channels and the status of them read "Stopped" Trying to restart the channels we got messages "Error starting the channel due to a problem at one of the endpoints" org.mule.umo.provider.ConnectorException: There is already a listener registered on this connector on endpointUri: jdbc://query. Connector that caused exception is: com.mirth.connect.connectors.jdbc.JdbcConnector@6c1194fa at org.mule.providers.AbstractConnector.registerListener(AbstractConnector.java:500) at org.mule.impl.model.AbstractModel.registerListeners(AbstractModel.java:231) at org.mule.impl.model.AbstractModel.startComponent(AbstractModel.java:493) at org.mule.management.mbeans.ModelService.startComponent(ModelService.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown Source) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown Source) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(Unknown Source) at com.sun.jmx.mbeanserver.PerInterface.invoke(Unknown Source) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(Unknown Source) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.access$200(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown Source) at sun.reflect.GeneratedMethodAccessor674.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) The only way this stopped was to restart the entire service. The channels should have been able fail gracefully from the server stop and be able to pick up instead of leaving the listener "orphaned".

    Mirth Project | 5 years ago | john voigt
    org.mule.umo.provider.ConnectorException: There is already a listener registered on this connector on endpointUri: jdbc://query. Connector that caused exception is: com.mirth.connect.connectors.jdbc.JdbcConnector@6c1194fa
  2. 0

    While 2 channel were pulling for messages from the SQL database, the sql server did a restart and on the Mirth side there was an exception on two channels as noted in the log "Exception occurred in channel" java.sql.SQLException: I/O Error: Connection reset by peer: socket write error Query: SELECT top 1 [ID] as mid ,[RECEIVED_DATE] ,CAST(HL7_Transaction as varchar(MAX)) AS SOURCE_HL7 FROM [INTEGRATION_NEW_TRANSACTIONS] where PROCESSED_DATE is NULL ORDER BY [RECEIVED_DATE] asc Parameters: [] at org.apache.commons.dbutils.QueryRunner.rethrow(QueryRunner.java:542) at org.apache.commons.dbutils.QueryRunner.query(QueryRunner.java:399) at com.mirth.connect.connectors.jdbc.JdbcMessageReceiver.getMessages(JdbcMessageReceiver.java:266) at org.mule.providers.TransactedPollingMessageReceiver$1.doInTransaction(TransactedPollingMessageReceiver.java:91) at org.mule.transaction.TransactionTemplate.execute(TransactionTemplate.java:72) at org.mule.providers.TransactedPollingMessageReceiver.poll(TransactedPollingMessageReceiver.java:104) at org.mule.providers.PollingMessageReceiver.run(PollingMessageReceiver.java:97) at org.mule.impl.work.WorkerContext.run(WorkerContext.java:290) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575) at java.lang.Thread.run(Unknown Source) This was recorder on both channels. The sql recovered but after that point the messages were not being pulled. We stopped the channels and the status of them read "Stopped" Trying to restart the channels we got messages "Error starting the channel due to a problem at one of the endpoints" org.mule.umo.provider.ConnectorException: There is already a listener registered on this connector on endpointUri: jdbc://query. Connector that caused exception is: com.mirth.connect.connectors.jdbc.JdbcConnector@6c1194fa at org.mule.providers.AbstractConnector.registerListener(AbstractConnector.java:500) at org.mule.impl.model.AbstractModel.registerListeners(AbstractModel.java:231) at org.mule.impl.model.AbstractModel.startComponent(AbstractModel.java:493) at org.mule.management.mbeans.ModelService.startComponent(ModelService.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown Source) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown Source) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(Unknown Source) at com.sun.jmx.mbeanserver.PerInterface.invoke(Unknown Source) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(Unknown Source) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.access$200(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown Source) at sun.reflect.GeneratedMethodAccessor674.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) The only way this stopped was to restart the entire service. The channels should have been able fail gracefully from the server stop and be able to pick up instead of leaving the listener "orphaned".

    Mirth Project | 5 years ago | john voigt
    org.mule.umo.provider.ConnectorException: There is already a listener registered on this connector on endpointUri: jdbc://query. Connector that caused exception is: com.mirth.connect.connectors.jdbc.JdbcConnector@6c1194fa
  3. 0

    To reproduce define 2 global endpoins: {noformat} <global-endpoints> <endpoint name="Endpoint1" address="ftp://user1:pass1@ftpserver"> <endpoint name="Endpoint2" address="ftp://user2:pass2@ftpserver"> </global-endpoints>{noformat} Than later on 2 components : {noformat} <mule-descriptor name="component1" implementation="org.mule.components.simple.BridgeComponent"> <inbound-router> <global-endpoint name="Endpoint1" /> </inbound-router> <outbound-router> ..... </outbound-router>{noformat} {noformat} <mule-descriptor name="component1" implementation="org.mule.components.simple.BridgeComponent"> <inbound-router> <global-endpoint name="Endpoint2" /> </inbound-router> <outbound-router> ..... </outbound-router>{noformat} Starting mule with such configuration ends up with : {noformat} org.mule.umo.provider.ConnectorException: There is already a listener registered on this connector on endpointUri: ftp://user2:pass2@ftpserver. Connector that caused exception is: FtpConnector{this=b29562, started=true, initialised=true, name='connector.ftp.0', disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=true, supportedProtocols=[ftp], serviceOverrides=null} at org.mule.providers.AbstractConnector.registerListener(AbstractConnector.java:767) at org.mule.impl.model.AbstractComponent.registerListeners(AbstractComponent.java:537) at org.mule.impl.model.AbstractComponent.start(AbstractComponent.java:217) at org.mule.impl.model.AbstractComponent.start(AbstractComponent.java:204) at org.mule.impl.model.AbstractModel.start(AbstractModel.java:323) at org.mule.MuleManager.start(MuleManager.java:900) {noformat} Did not have the time to figure it all out but seems like the problem is in : {{UMOMessageReceiver receiver = this.getReceiver(component, endpoint);}} This will produce the same receiver ({{ftp://ftpserver}}) for both endpoints! Trying to register the second one causes an exception to be thrown as there is already such key in {{receivers}} map. In my opinion {{getReceiver}} method should make use of the username to generate the key!

    MuleSoft JIRA | 9 years ago | Milen Dyankov
    org.mule.umo.provider.ConnectorException: There is already a listener registered on this connector on endpointUri: ftp://user2:pass2@ftpserver. Connector that caused exception is: FtpConnector{this=b29562, started=true, initialised=true, name='connector.ftp.0', disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=true, supportedProtocols=[ftp], serviceOverrides=null}
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    To reproduce define 2 global endpoins: {noformat} <global-endpoints> <endpoint name="Endpoint1" address="ftp://user1:pass1@ftpserver"> <endpoint name="Endpoint2" address="ftp://user2:pass2@ftpserver"> </global-endpoints>{noformat} Than later on 2 components : {noformat} <mule-descriptor name="component1" implementation="org.mule.components.simple.BridgeComponent"> <inbound-router> <global-endpoint name="Endpoint1" /> </inbound-router> <outbound-router> ..... </outbound-router>{noformat} {noformat} <mule-descriptor name="component1" implementation="org.mule.components.simple.BridgeComponent"> <inbound-router> <global-endpoint name="Endpoint2" /> </inbound-router> <outbound-router> ..... </outbound-router>{noformat} Starting mule with such configuration ends up with : {noformat} org.mule.umo.provider.ConnectorException: There is already a listener registered on this connector on endpointUri: ftp://user2:pass2@ftpserver. Connector that caused exception is: FtpConnector{this=b29562, started=true, initialised=true, name='connector.ftp.0', disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=true, supportedProtocols=[ftp], serviceOverrides=null} at org.mule.providers.AbstractConnector.registerListener(AbstractConnector.java:767) at org.mule.impl.model.AbstractComponent.registerListeners(AbstractComponent.java:537) at org.mule.impl.model.AbstractComponent.start(AbstractComponent.java:217) at org.mule.impl.model.AbstractComponent.start(AbstractComponent.java:204) at org.mule.impl.model.AbstractModel.start(AbstractModel.java:323) at org.mule.MuleManager.start(MuleManager.java:900) {noformat} Did not have the time to figure it all out but seems like the problem is in : {{UMOMessageReceiver receiver = this.getReceiver(component, endpoint);}} This will produce the same receiver ({{ftp://ftpserver}}) for both endpoints! Trying to register the second one causes an exception to be thrown as there is already such key in {{receivers}} map. In my opinion {{getReceiver}} method should make use of the username to generate the key!

    MuleSoft JIRA | 9 years ago | Milen Dyankov
    org.mule.umo.provider.ConnectorException: There is already a listener registered on this connector on endpointUri: ftp://user2:pass2@ftpserver. Connector that caused exception is: FtpConnector{this=b29562, started=true, initialised=true, name='connector.ftp.0', disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=true, supportedProtocols=[ftp], serviceOverrides=null}

    Root Cause Analysis

    1. org.mule.umo.provider.ConnectorException

      There is already a listener registered on this connector on endpointUri: jdbc://query. Connector that caused exception is: com.mirth.connect.connectors.jdbc.JdbcConnector@6c1194fa

      at org.mule.providers.AbstractConnector.registerListener()
    2. org.mule.providers
      AbstractConnector.registerListener
      1. org.mule.providers.AbstractConnector.registerListener(AbstractConnector.java:500)
      1 frame
    3. org.mule.impl
      AbstractModel.startComponent
      1. org.mule.impl.model.AbstractModel.registerListeners(AbstractModel.java:231)
      2. org.mule.impl.model.AbstractModel.startComponent(AbstractModel.java:493)
      2 frames
    4. org.mule.management
      ModelService.startComponent
      1. org.mule.management.mbeans.ModelService.startComponent(ModelService.java:50)
      1 frame
    5. Java RT
      Thread.run
      1. sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      2. sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
      3. sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
      4. java.lang.reflect.Method.invoke(Unknown Source)
      5. com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown Source)
      6. com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(Unknown Source)
      7. com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(Unknown Source)
      8. com.sun.jmx.mbeanserver.PerInterface.invoke(Unknown Source)
      9. com.sun.jmx.mbeanserver.MBeanSupport.invoke(Unknown Source)
      10. com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source)
      11. com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source)
      12. javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source)
      13. javax.management.remote.rmi.RMIConnectionImpl.access$200(Unknown Source)
      14. javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown Source)
      15. java.security.AccessController.doPrivileged(Native Method)
      16. javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown Source)
      17. javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown Source)
      18. sun.reflect.GeneratedMethodAccessor674.invoke(Unknown Source)
      19. sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
      20. java.lang.reflect.Method.invoke(Unknown Source)
      21. sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
      22. sun.rmi.transport.Transport$1.run(Unknown Source)
      23. java.security.AccessController.doPrivileged(Native Method)
      24. sun.rmi.transport.Transport.serviceCall(Unknown Source)
      25. sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
      26. sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
      27. sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
      28. java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
      29. java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
      30. java.lang.Thread.run(Unknown Source)
      30 frames