Closed ryanc1024 closed 6 years ago
I see . Looks like a valid issue. Will check it out. Thanks.
@vladimirralev I just wanted to follow up on this issue. Unfortunately it is affecting one of our major customers in production who are recording calls via SIPREC. When this issue is encountered they are unable to establish the recording leg and are therefore missing recordings. I would greatly appreciate anything you can do to look into this issue. Thanks!
OK, I think your idea works and tests look good. Let's see how it does.
@vladimirralev I see that a fix was merged in and a new build, but the build number seems off. Is it supposed to be "1.2.1111"?
OK yes the version string seems off but the binary is fine, you can use it. I will fix the build version string later.
The version substring used to be generated from the svn version. It should be changed to the git version (should be easier to generate that).
Ranga.
From: vladimirralev [mailto:notifications@github.com] Sent: Monday, October 24, 2016 9:45 AM To: usnistgov/jsip jsip@noreply.github.com Subject: Re: [usnistgov/jsip] NoSuchElementException when parsing multipart SIP content (#16)
OK yes the version string seems off but the binary is fine, you can use it. I will fix the build version string later.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/usnistgov/jsip/issues/16#issuecomment-255744205, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AHNZkLJ77D_SwSfwHkkXc8EYVL3Gd9WJks5q3LZJgaJpZM4KVbg2.
@ranganathanm are you saying the version number is correct as-is with 1.2.1111? We are testing the current binaries, but are holding off deploying until we understand whether the versioning is correct to match repo pin.
Hello,
This code was ported from SVN. The version number was (previously) generated from the SVN version number. Since the code moved from SVN to github, the version number generator has not been updated.
BR
Ranga.
From: ryanc1024 [mailto:notifications@github.com] Sent: Tuesday, November 01, 2016 11:31 AM To: usnistgov/jsip jsip@noreply.github.com Cc: Ranganathan, Mudumbai (Fed) mudumbai.ranganathan@nist.gov; Mention mention@noreply.github.com Subject: Re: [usnistgov/jsip] NoSuchElementException when parsing multipart SIP content (#16)
@ranganathanmhttps://github.com/ranganathanm are you saying the version number is correct as-is with 1.2.1111? We are testing the current binaries, but are holding off deploying until we understand whether the versioning is correct to match repo pin.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/usnistgov/jsip/issues/16#issuecomment-257598028, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AHNZkIH0ljWBqPaD2Sq5phm8IebpKUwaks5q51tQgaJpZM4KVbg2.
I've encountered the same issue when trying to run the tests on the jain sip stack. The bug is caused by a jvm bug. Bug for the open jdk jvm: https://bugs.openjdk.java.net/browse/JDK-8139414 Bug for oracle jvm: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8139414. The try catch that was added fixes the issue.
Confirmed that the try-catch resolves the issue.
I have encountered an issue recently within the MultipartMimeContentImpl. It appears that some specifically sized content can trigger a NoSuchElementException while the code is scanning through. Looking into how the scanner works, it seems that a specifically sized piece of content could be read into the buffer with the final region end bytes not read ("--\r\n" remains on the stream yet to be read). The pattern used by the Impl class considers them optional and matches the region. Since there are remaining bytes and there is a matching pattern in the buffer, the Scanner returns "true" that there is another element during the hasNext() check. Unfortunately, the Scanner reads in the final region end bytes, hits the EOF, and determines that there are no more elements (throwing the exception).
Seems like the easiest solution would be to try-catch the call to scanner.next() and breaking out of the loop when the exception is thrown. This may not account for conditions where the body content is malformed.
I have attached an example piece of body content that throws the exception when passed into the Impl. jain-sip bad SIP body.txt