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