org.mule.umo.provider.ConnectorException

There are no available Samebug tips for this exception. Do you have an idea how to solve this issue? A short tip would help users who saw this issue last week.

  • 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!
    via by Milen Dyankov,
  • 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!
    via by Milen Dyankov,
  • 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".
    via by john voigt,
  • 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".
    via by john voigt,
    • 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)
    No Bugmate found.