Announcement

Collapse
No announcement yet.

java.lang.NullPointerException after REST API call with HTTP Sender Connector

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

  • java.lang.NullPointerException after REST API call with HTTP Sender Connector

    After configuring the SSL plugin and making several successful calls via HTTPS to a REST API I attempted using a query parameter to further refine the call. The only difference between a working version of the channel and a non-working version where this null pointer exception is received is the introduction of the query parameter. I've tried adding it into the Query Parameter forms area as well as directly placing it in the URL, but to no avail.

    Response Status
    Code:
    ERROR: Error connecting to HTTP server [NullPointerException: null]
    Full Stack Trace
    Code:
    HTTP Sender error
    ERROR MESSAGE: Error connecting to HTTP server
    java.lang.NullPointerException
    	at java.lang.String.<init>(Unknown Source)
    	at com.mirth.connect.connectors.http.HttpDispatcher.send(HttpDispatcher.java:195)
    	at com.mirth.connect.donkey.server.channel.DestinationConnector.handleSend(DestinationConnector.java:599)
    	at com.mirth.connect.donkey.server.channel.DestinationConnector.process(DestinationConnector.java:336)
    	at com.mirth.connect.donkey.server.channel.DestinationChain.call(DestinationChain.java:224)
    	at com.mirth.connect.donkey.server.channel.Channel.process(Channel.java:1428)
    	at com.mirth.connect.donkey.server.channel.Channel.dispatchRawMessage(Channel.java:956)
    	at com.mirth.connect.donkey.server.channel.SourceConnector.dispatchRawMessage(SourceConnector.java:175)
    	at com.mirth.connect.donkey.server.channel.SourceConnector.dispatchRawMessage(SourceConnector.java:152)
    	at com.mirth.connect.connectors.jdbc.DatabaseReceiver.processRecord(DatabaseReceiver.java:198)
    	at com.mirth.connect.connectors.jdbc.DatabaseReceiver.processResultSet(DatabaseReceiver.java:164)
    	at com.mirth.connect.connectors.jdbc.DatabaseReceiver.poll(DatabaseReceiver.java:121)
    	at com.mirth.connect.donkey.server.channel.PollConnector$PollConnectorTask.run(PollConnector.java:141)
    	at java.util.TimerThread.mainLoop(Unknown Source)
    	at java.util.TimerThread.run(Unknown Source)

  • #2
    The url that works looks like this:
    Code:
    https://hostname/v1/contextPath/resourceName
    while the non-working version looks like this:
    Code:
    https://hostname/v1/contextPath/resourceName?since=1407871630,1

    Comment


    • #3
      The problem is probably not in the query parameters you're sending per se, but rather in the response being returned from the server. What exactly is the difference, if any? Do an in-depth network capture in both cases and post it here.
      Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

      Nicholas Rupley
      Work: 949-237-6069
      Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


      - How do I foo?
      - You just bar.

      Comment


      • #4
        I've attached here two captures from Wire Shark - One from a successful call without query parameters and a failed call with query parameters.
        Attached Files

        Comment


        • #5
          Please let me know as well if there are any filters that would be useful to run in Wire Shark based on the circumstances. I've filtered on port 443 because that's where the traffic resides, but if there is anything else that could be used to narrow the field then I will re-run the captures. Thanks again for all your help Narupley.

          Comment


          • #6
            Updated progress on troubleshooting; what we've found is that the error hinges on the presence of the equals = sign. When trying the same URL, but with encoded equals sign it succeeds, but disregards the query parameter.

            Fails
            Code:
            https://hostname/v1/contextPath/resourceName?since=1407871630,1
            Succeeds, but REST API doesn't use query parameter
            Code:
            https://hostname/v1/contextPath/resourceName?since%3D1407871630%2C1

            Comment


            • #7
              Those captures don't make sense. The one that says "without query parameters" actually does have HTTP requests with query parameters, and those appear to be perfectly successful:



              The second one that says "with query parameters" doesn't have any HTTP requests at all:

              Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

              Nicholas Rupley
              Work: 949-237-6069
              Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


              - How do I foo?
              - You just bar.

              Comment


              • #8
                Originally posted by mirraraenn View Post
                Updated progress on troubleshooting; what we've found is that the error hinges on the presence of the equals = sign. When trying the same URL, but with encoded equals sign it succeeds, but disregards the query parameter.

                Fails
                Code:
                https://hostname/v1/contextPath/resourceName?since=1407871630,1
                Succeeds, but REST API doesn't use query parameter
                Code:
                https://hostname/v1/contextPath/resourceName?since%3D1407871630%2C1
                How do you know it's the equals sign? Have you tried just encoding the comma?

                Code:
                https://hostname/v1/contextPath/resourceName?since=1407871630%2C1
                Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

                Nicholas Rupley
                Work: 949-237-6069
                Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


                - How do I foo?
                - You just bar.

                Comment


                • #9
                  Originally posted by narupley View Post
                  Those captures don't make sense. The one that says "without query parameters" actually does have HTTP requests with query parameters, and those appear to be perfectly successful:



                  The second one that says "with query parameters" doesn't have any HTTP requests at all:

                  The URLs you have for the first filter aren't the ones that the HTTP connector is performing a GET on, that may be just regular browser traffic. I'm worried that the reason you're seeing zero requests in the second trace is because the request is failing to leave Mirth at all.

                  I've sent the bare bones channel that exhibits the behavior in an email to the Mirth Support address so you can test yourself. It has all the right settings to make a successful call in a third party REST client tool, but not in the Mirth channel because of the exception.

                  Comment


                  • #10
                    There are literally no other HTTP requests in the first trace, those two were the only ones. Unless... you haven't decrypted any TLS traffic? There's no way for anyone to see the actual requests if they're still encrypted.
                    Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

                    Nicholas Rupley
                    Work: 949-237-6069
                    Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


                    - How do I foo?
                    - You just bar.

                    Comment


                    • #11
                      Originally posted by narupley View Post
                      There are literally no other HTTP requests in the first trace, those two were the only ones. Unless... you haven't decrypted any TLS traffic? There's no way for anyone to see the actual requests if they're still encrypted.
                      That makes sense Narupley. Unfortunately I don't have the private key for this server, although I can try to see if I can get it. In the meantime, did you see the channel I sent the the [email protected] email address?

                      Comment


                      • #12
                        Originally posted by mirraraenn View Post
                        That makes sense Narupley. Unfortunately I don't have the private key for this server, although I can try to see if I can get it. In the meantime, did you see the channel I sent the the [email protected] email address?
                        I haven't, though if you submitted a ticket help desk will take it from here.
                        Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

                        Nicholas Rupley
                        Work: 949-237-6069
                        Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


                        - How do I foo?
                        - You just bar.

                        Comment


                        • #13
                          One thing we had considered was that one of the possible responses from this API was to return a 204 No Content in the case where there were no further updates to return from a GET. Is it possible that Mirth is failing to process the message because it is trying to process an empty or non-existent response body for an HTTP response with a status of 204 No Content? That could account for the null pointer exception we're experiencing.

                          Comment


                          • #14
                            Originally posted by mirraraenn View Post
                            One thing we had considered was that one of the possible responses from this API was to return a 204 No Content in the case where there were no further updates to return from a GET. Is it possible that Mirth is failing to process the message because it is trying to process an empty or non-existent response body for an HTTP response with a status of 204 No Content? That could account for the null pointer exception we're experiencing.
                            Good catch! I've confirmed that it's a bug on our side: MIRTH-3425. I already fixed it for 3.1, which will be coming out very soon.

                            As a temporary workaround, in that HTTP Sender destination you can set your response data types to Raw, and then do this in the response transformer:

                            Code:
                            if (/.*java\.lang\.NullPointerException.*/.test(responseErrorMessage)) {
                            	responseStatus = SENT;
                            	responseStatusMessage = 'No Content';
                            }
                            Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

                            Nicholas Rupley
                            Work: 949-237-6069
                            Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


                            - How do I foo?
                            - You just bar.

                            Comment


                            • #15
                              Originally posted by narupley View Post
                              Those captures don't make sense. The one that says "without query parameters" actually does have HTTP requests with query parameters, and those appear to be perfectly successful:



                              The second one that says "with query parameters" doesn't have any HTTP requests at all:

                              Originally posted by phatneff View Post
                              Does this have to do with why my Alert messages are not the same in 3.0.0 as they were in 2.2.1?





                              For example, I have this same alert to send me an email in both Mirth versions:

                              ${channelName}

                              ${date}

                              ${errorMessage}

                              ${error}


                              In 2.2.1, I would get a descriptive error:

                              IMPAC_Charges_TCPIP

                              1405713321529

                              No exception message.

                              ERROR-408: MLLP Connector error
                              ERROR MESSAGE: NACK sent from receiver: [Application Error]

                              Charge 480584 is existed already with emr uniq id of xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, message is rejected.: MSH|^~\&|NextGen Rosetta|NextGen Clinic|Billing System|Billing System|20140718155520982||ACK|3492552448|P|2.3
                              MSA|AE|20140718154910159903||||^Charge 480584 is existed already with emr uniq id of xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, message is rejected.
                              ERR|Charge 480584 is existed already with emr uniq id of xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, message is rejected.


                              Now, in 3.0.0, I get:

                              PROD_Mosaiq_Charges_to_NG

                              Aug 25, 2014 5:01:57 PM

                              Software caused connection abort: recv failed

                              Source Connector (TCP Listener) error
                              ERROR MESSAGE: Error receiving message
                              java.net.SocketException: Software caused connection abort: recv failed
                              at java.net.SocketInputStream.socketRead0(Native Method)
                              at java.net.SocketInputStream.read(Unknown Source)
                              at java.net.SocketInputStream.read(Unknown Source)
                              at java.io.BufferedInputStream.fill(Unknown Source)
                              at java.io.BufferedInputStream.read(Unknown Source)
                              at com.mirth.connect.model.transmission.framemode.Fra meStreamHandler.read(FrameStreamHandler.java:120)
                              at com.mirth.connect.connectors.tcp.TcpReceiver$TcpRe ader.call(TcpReceiver.java:560)
                              at com.mirth.connect.connectors.tcp.TcpReceiver$TcpRe ader.call(TcpReceiver.java:462)
                              at java.util.concurrent.FutureTask.run(Unknown Source)
                              at java.util.concurrent.ThreadPoolExecutor.runWorker( Unknown Source)
                              at java.util.concurrent.ThreadPoolExecutor$Worker.run (Unknown Source)
                              at java.lang.Thread.run(Unknown Source)


                              ${msg}


                              These emails are also sent to a user who can correct the issue on the application side. Needless to say, when that user gets the message from 3.0.0, there is nothing that tells her what needs fixed. So are you saying I need the commercial alerting extension to get the message that was coming from 2.2.1?

                              I've attached here two captures from Wire Shark - One from a successful call without query parameters and a failed call with query parameters.
                              Last edited by narupley; 10-10-2014, 12:58 PM.

                              Comment

                              Working...
                              X