web stats
java.lang.NullPointerException after REST API call with HTTP Sender Connector - Page 2 - Mirth Community

Go Back   Mirth Community > Mirth Connect > Support

Reply
 
Thread Tools Display Modes
  #11  
Old 08-28-2014, 01:33 PM
mirraraenn mirraraenn is offline
Mirth Newb
 
Join Date: Jun 2014
Posts: 16
mirraraenn is on a distinguished road
Default

Quote:
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 mirthsupport@mirthcorp.com email address?
Reply With Quote
  #12  
Old 08-28-2014, 01:46 PM
narupley's Avatar
narupley narupley is online now
Mirth Employee
 
Join Date: Oct 2010
Posts: 7,119
narupley is on a distinguished road
Default

Quote:
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 mirthsupport@mirthcorp.com 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.
Reply With Quote
  #13  
Old 08-28-2014, 05:55 PM
mirraraenn mirraraenn is offline
Mirth Newb
 
Join Date: Jun 2014
Posts: 16
mirraraenn is on a distinguished road
Default

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.
Reply With Quote
  #14  
Old 08-29-2014, 07:45 AM
narupley's Avatar
narupley narupley is online now
Mirth Employee
 
Join Date: Oct 2010
Posts: 7,119
narupley is on a distinguished road
Default

Quote:
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.
Reply With Quote
  #15  
Old 10-10-2014, 12:53 PM
midomidi2013 midomidi2013 is offline
What's HL7?
 
Join Date: Oct 2014
Posts: 1
midomidi2013 is on a distinguished road
Default

Quote:
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:

Quote:
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 at 12:58 PM.
Reply With Quote
Reply

Tags
exception, http sender, null pointer exception, query parameter

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 12:19 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Mirth Corporation