[muscle] Re: Java NIO bugs...
- From: Bryan Varner <bryan@xxxxxxxxxxxxx>
- To: muscle@xxxxxxxxxxxxx
- Date: Thu, 11 Sep 2014 20:59:45 -0400
Sorry… it probably won’t.
I’m having issues with connections that appear closed even though they aren’t —
I’m not sure what’s going on there.
I won’t be able to look at it for another 6 weeks or so...
-Bryan
On Sep 11, 2014, at 5:33 PM, Jeremy Friesner <jfriesne@xxxxxxxxx> wrote:
> 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:
