Announcement

Collapse
No announcement yet.

Help please -- Network listeners not deploying (VM Ware)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Help please -- Network listeners not deploying (VM Ware)

    HI all,

    We've just ported a configuration to a VM ware box, and we can't get some of the network connectors to deploy. Here are the symptoms and what we've tried:
    • We get a FatalConnectException with hhtpListener, TCPListener, WebServicesListener and LLPListener.
    • FileReader seems to work, didn't fully test for the DBReader, and it seems ok. It writes and reads from a dir where we can r/w files.
    • WindowsFirewall was tested and eventually fully turned off to eliminate it as a source of error.
    • Updated to latest SQLServer JDBC tier 4 driver (v. 3.0 )
    • Netstat shows nothing listening/sending/etc. on the ports we want to access.
    • Also, I should note that Mirth Connect is NOT installed in the ProgamFiles directory-- instead it is in a Mirth directory off the root (c:\MirthConnect) --not sure if this matters any.

    Some thoughts: since we didn't configure the machine security, could the local Read/write permissions be affecting the network listener? The filereader accesses a known user file store. WE are supposed to have full sysadmin rights on the machine.

    Anyone have any idea what I should check next?[ We need to get the LLPLIstener working first. I could really use the extra brainpower to think this through.

    Here's the gory details of the error:




    [2011-09-28 14:06:01,051] ERROR (com.mirth.connect.server.controllers.MuleEngineCo ntroller:230): Error registering channel.
    org.mule.providers.FatalConnectException: ReconnectStrategy "org.mule.providers.SingleAttemptConnectionStrateg y" failed to reconnect receiver on endpoint "mllp://165.152.9.18:4433"
    at org.mule.providers.SingleAttemptConnectionStrategy .doConnect(SingleAttemptConnectionStrategy.java:34 )
    at org.mule.providers.AbstractConnectionStrategy.conn ect(AbstractConnectionStrategy.java:67)
    at org.mule.providers.AbstractMessageReceiver.start(A bstractMessageReceiver.java:391)
    at org.mule.providers.AbstractConnector.registerListe ner(AbstractConnector.java:508)
    at com.mirth.connect.connectors.mllp.MllpConnector.re gisterListener(MllpConnector.java:390)
    at org.mule.impl.model.AbstractModel.registerListener s(AbstractModel.java:232)
    at org.mule.impl.model.AbstractModel.registerComponen t(AbstractModel.java:188)
    at com.mirth.connect.server.controllers.MuleEngineCon troller.registerChannel(MuleEngineController.java: 364)
    at com.mirth.connect.server.controllers.MuleEngineCon troller.deployChannels(MuleEngineController.java:2 12)
    at com.mirth.connect.server.servlets.EngineServlet.do Post(EngineServlet.java:60)
    at javax.servlet.http.HttpServlet.service(HttpServlet .java:727)
    at javax.servlet.http.HttpServlet.service(HttpServlet .java:820)
    at org.eclipse.jetty.servlet.ServletHolder.handle(Ser vletHolder.java:534)
    at org.eclipse.jetty.servlet.ServletHandler.doHandle( ServletHandler.java:475)
    at org.eclipse.jetty.server.session.SessionHandler.do Handle(SessionHandler.java:224)
    at org.eclipse.jetty.server.handler.ContextHandler.do Handle(ContextHandler.java:929)
    at org.eclipse.jetty.servlet.ServletHandler.doScope(S ervletHandler.java:403)
    at org.eclipse.jetty.server.session.SessionHandler.do Scope(SessionHandler.java:184)
    at org.eclipse.jetty.server.handler.ContextHandler.do Scope(ContextHandler.java:864)
    at org.eclipse.jetty.server.handler.ScopedHandler.han dle(ScopedHandler.java:117)
    at org.eclipse.jetty.server.handler.HandlerList.handl e(HandlerList.java:47)
    at org.eclipse.jetty.server.handler.HandlerWrapper.ha ndle(HandlerWrapper.java:114)
    at org.eclipse.jetty.server.Server.handle(Server.java :352)
    at org.eclipse.jetty.server.HttpConnection.handleRequ est(HttpConnection.java:596)
    at org.eclipse.jetty.server.HttpConnection$RequestHan dler.content(HttpConnection.java:1068)
    at org.eclipse.jetty.http.HttpParser.parseNext(HttpPa rser.java:805)
    at org.eclipse.jetty.http.HttpParser.parseAvailable(H ttpParser.java:212)
    at org.eclipse.jetty.server.HttpConnection.handle(Htt pConnection.java:426)
    at org.eclipse.jetty.io.nio.SelectChannelEndPoint.han dle(SelectChannelEndPoint.java:508)
    at org.eclipse.jetty.io.nio.SelectChannelEndPoint.acc ess$000(SelectChannelEndPoint.java:34)
    at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.r un(SelectChannelEndPoint.java:40)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$2.r un(QueuedThreadPool.java:451)
    at java.lang.Thread.run(Unknown Source)Caused by: org.mule.providers.FatalConnectException: ReconnectStrategy "org.mule.providers.SingleAttemptConnectionStrateg y" failed to reconnect receiver on endpoint "mllp://165.152.9.18:4433"
    at org.mule.providers.SingleAttemptConnectionStrategy .doConnect(SingleAttemptConnectionStrategy.java:34 )
    at org.mule.providers.AbstractConnectionStrategy.conn ect(AbstractConnectionStrategy.java:67)
    at org.mule.providers.AbstractMessageReceiver.connect (AbstractMessageReceiver.java:348)
    at org.mule.providers.SingleAttemptConnectionStrategy .doConnect(SingleAttemptConnectionStrategy.java:32 )
    ... 32 moreCaused by: org.mule.providers.ConnectException: Failed to bind to uri "mllp://165.157.8.17:6633"
    at com.mirth.connect.connectors.mllp.MllpMessageRecei ver.doConnect(MllpMessageReceiver.java:130)
    at org.mule.providers.AbstractMessageReceiver.connect (AbstractMessageReceiver.java:355)
    at org.mule.providers.SingleAttemptConnectionStrategy .doConnect(SingleAttemptConnectionStrategy.java:32 )
    ... 35 moreCaused by: java.net.BindException: Cannot assign requested address: JVM_Bind
    at java.net.PlainSocketImpl.socketBind(Native Method)
    at java.net.PlainSocketImpl.bind(Unknown Source)
    at java.net.ServerSocket.bind(Unknown Source)
    at java.net.ServerSocket.<init>(Unknown Source)
    at com.mirth.connect.connectors.mllp.MllpMessageRecei ver.createServerSocket(MllpMessageReceiver.java:17 5)
    at com.mirth.connect.connectors.mllp.MllpMessageRecei ver.doConnect(MllpMessageReceiver.java:124)

  • #2
    JVM problem???

    Upon deeper inspection in the error, I notice problems with JVM_bind

    has anyone seen this? Other errors with FatalConnectException seem to surround port numbers being used by other apps or resources.

    Looks like this may be it. I think we'll need to run the install again to see if we can get this to go away.

    _Ravi

    Comment


    • #3
      UPDATE-- network listeners don't work, can't register channel!!

      OK... did a fresh install and we still have the same error... not sure what is happening.

      Our settings are:
      LLP listener acting as server
      IP configured-- it pings as live and reachable
      Port is verified as the sending port
      ProcessBatch = no
      LLP frame encoding is hex (tried with ASCII too)
      char data is as default settings
      strict LLP = yes
      send ACk = Yes, with default settings.

      We simply can't register the channel... Anyone have any ideas? this is quite frustrating, since we have a file reader version that parses the messages perfectly. Why would the network listeners not work or not register properly?

      _R

      Comment


      • #4
        I usually get this error when I have a conflicting listening port.

        If you don't have another channel listening on that port, then I would do a netstat and see if there is another process using that particular port (a quick check would be to change the port number and see if the channel deploys).

        I read on another thread that someone got around this by changing the listening IP to 0.0.0.0. Not sure why that would work for him but I don't dabble at the network level that often.
        I can be reached through gmail and Google Talk using davidrothbauer at gmail dot com
        http://www.linkedin.com/pub/david-rothbauer/5/923/518
        codeismydrug.wordpress.com
        hl7coders.wordpress.com

        Test all my code suggestions prior to implementation

        Comment


        • #5
          I've run into this issue in a Linux environment, but not a Windows environment. In a linux environment, we found that the server host name was different than our host file. This was preventing us from starting our listening channels. When we fixed the host name, everything started up.

          Comment


          • #6
            Are you setting the listening IP? Try first with the default 0.0.0.0

            This problems could happend when you haven't configured properly your network. Is 165.152.9.18 your IP? can you get "localhost" ?

            Comment


            • #7
              Got it!

              turns out if you need to listen on a port, and you are acting as a server, "loclahost" or 0.0.0.0 or 127.0.0.0 is the address to use.

              In short, you are listening for the port# on that address (which is yours). Kind of convoluted, if you ask me, but it works.

              Comment

              Working...
              X