[muscle] Re: Java NIO bugs...

  • From: Jeremy Friesner <jfriesne@xxxxxxxxx>
  • To: muscle@xxxxxxxxxxxxx
  • Date: Thu, 11 Sep 2014 14:33:11 -0700

Hi Bryan,

Is that change going to arrive soon?  I'm planning a MUSCLE release in the next 
few days, and it would be better to receive the change before then.

-Jeremy

On Sep 3, 2014, at 12:28 PM, Bryan Varner <bryan@xxxxxxxxxxxxx> wrote:

> Thanks Jeremy!
> 
> So you know, I’ve got another change coming… just found a spot where the NIO 
> bits are interpreting a -1 from a read() as a dead connection, which is not 
> the case — it’s reached end of stream. It throws an exception if the socket 
> is dead.
> 
> -Bryan
> 
> 
> 
> On Sep 3, 2014, at 11:31 AM, jeremyf <jfriesne@xxxxxxxxx> wrote:
> 
>> Thanks Bryan; I’ve merged your changes in to my SVN repository and will push 
>> them out to github as part of the next MUSCLE release.
>> 
>> -Jeremy
>> 
>> On Sep 3, 2014, at 6:40 AM, Bryan Varner <bryan@xxxxxxxxxxxxx> wrote:
>> 
>>> It would probably be easier (at least for me) if I fork 
>>> https://github.com/jfriesne/muscle and send you a pull request on github. 
>>> :-)
>>> 
>>> 
>>> 
>>> On Sep 2, 2014, at 2:06 PM, Jeremy Friesner <jfriesne@xxxxxxxxx> wrote:
>>> 
>>>> Hi Bryan,
>>>> 
>>>> Just email me a .zip with the updated file(s) and I'll integrate it in for 
>>>> the next release.
>>>> 
>>>> Thanks!
>>>> Jeremy
>>>> 
>>>> On Sep 2, 2014, at 10:41 AM, Bryan Varner <bryan@xxxxxxxxxxxxx>
>>>> wrote:
>>>> 
>>>>> I recently upgraded some very old java MUSCLE code to the interfaces 
>>>>> using the Java NIO byte buffers, and found some unexpected results.
>>>>> 
>>>>> Specifically, I was getting IOExceptions as if the remote end of the 
>>>>> connection had hung-up. After a lot of sleuthing, I found that the 
>>>>> receive buffer position wasn’t being set prior to throwing a 
>>>>> NotEnoughDataException during message unflattening, which was leaving the 
>>>>> buffer in an inconsistent state and basically reading random bits into 
>>>>> bytes for message length and encoding…
>>>>> 
>>>>> I ran across the root of the problem after noticing that the byte buffers 
>>>>> were being allocated per message received invocation, and were using 
>>>>> indirect byte buffers… 
>>>>> 
>>>>> I have a copy of the source with the issue fixed as well as a set of 
>>>>> changes which changes the scope of the byte buffer, allocated it as 
>>>>> direct, and dramatically reduced the amount of work the GC was doing in 
>>>>> Java to clean up all those byte buffer allocations.
>>>>> 
>>>>> What’s the process for submitting patches these days? :-)
>>>>> 
>>>>> Regards,
>>>>> -Bryan
>>>> 
>>>> 
>>> 
>> 
>> 
> 
> 


Other related posts: