[jira] [Created] (PROTON-760) Improve the JavaScript binding's internal Event loop and add additional tests
Fraser Adams created PROTON-760: --- Summary: Improve the JavaScript binding's internal Event loop and add additional tests Key: PROTON-760 URL: https://issues.apache.org/jira/browse/PROTON-760 Project: Qpid Proton Issue Type: Improvement Reporter: Fraser Adams Improve the JavaScript binding's internal Event loop and add additional tests. The addition of JavaScript soak/performance tests msgr-send.js and msgr-recv.js, which mirror tests of the same name in C and Python flagged up a few edge cases that caused sporadic failures. The problems seem to be related to the ws WebSocket library directly calling some callbacks rather than posting to the JavaScript internal Event queue. The effect of calling directly mean that the main message handler and the close handler could actually get called *concurrently* which is clearly a bad thing and somewhat undexpected in JavaScript. The improvements here add a number of guard tests and introduce a setTimeout that allows the real close handler to be deferred by posting it onto the Event queue. msgr-send and msgr-recv have been run with counts of several million messages and also with message sizes of up to 2MB and everything seems stable now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-760) Improve the JavaScript binding's internal Event loop and add additional tests
[ https://issues.apache.org/jira/browse/PROTON-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14228746#comment-14228746 ] ASF subversion and git services commented on PROTON-760: Commit 39cd8c5dc75d4e5e68c67360f320fc7a2fd5e29a in qpid-proton's branch refs/heads/master from [~fadams] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=39cd8c5 ] PROTON-760: Improve the JavaScript binding's internal Event loop and add additional tests. Improve the JavaScript binding's internal Event loop and add additional tests - Key: PROTON-760 URL: https://issues.apache.org/jira/browse/PROTON-760 Project: Qpid Proton Issue Type: Improvement Reporter: Fraser Adams Improve the JavaScript binding's internal Event loop and add additional tests. The addition of JavaScript soak/performance tests msgr-send.js and msgr-recv.js, which mirror tests of the same name in C and Python flagged up a few edge cases that caused sporadic failures. The problems seem to be related to the ws WebSocket library directly calling some callbacks rather than posting to the JavaScript internal Event queue. The effect of calling directly mean that the main message handler and the close handler could actually get called *concurrently* which is clearly a bad thing and somewhat undexpected in JavaScript. The improvements here add a number of guard tests and introduce a setTimeout that allows the real close handler to be deferred by posting it onto the Event queue. msgr-send and msgr-recv have been run with counts of several million messages and also with message sizes of up to 2MB and everything seems stable now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: heads up: javascript has landed
On 29 Nov 2014, at 14:20, Fraser Adams fraser.ad...@blueyonder.co.uk wrote: Hopefully this is useful to people, it's been something of a labour of love over the last year. I'm looking forward to checking this out now it has dropped into master. It was only when you recently posted on the mailing list about it that I knew it was in development. Thanks for the instructions to get up and running with it too. Will be interesting to compare the nodejs enscripten performance vs a swig-based proton-c nodejs addon too. Cheers Dom
Re: heads up: javascript has landed
On 29/11/14 16:00, Dominic Evans wrote: I'm looking forward to checking this out now it has dropped into master. It was only when you recently posted on the mailing list about it that I knew it was in development. Thanks for the instructions to get up and running with it too. Yeah I should probably have been a bit more communicative about it, but I'm a bit obsessive and kept on adding just one more thing :-D . Rafael pulling what I had onto master was kind of the kick I needed... Will be interesting to compare the nodejs enscripten performance vs a swig-based proton-c nodejs addon too. Cheers Dom As well as needing to get the Node.js net module support in emscripten sorted out another thing on my TODO list is to look at the latest swig JavaScript binding stuff. I think I've mentioned this previously, but the swig and emscripten approaches are complementary rather than competing, the swig approach is only ever going to work on things like Node.js not a browser, but it might eke a little extra performance. The pure JavaScript emscripten approach is clearly very heavily influenced by the performance of the runtime. From what I've noticed from casual observation the asm.js optimisations in recent Firefox builds make a real difference though. FF 33 looks like it has more than double the throughput of the version of V8 running on Node.js 0.10.33, I need to try it out with Chrome to see if there's a difference there. An interesting wet finger is that my test on FF 33 using the pure JavaScript library and msgr-send.js seemed to have performance in the same ballpark as the msgr-send.py, which obviously uses the swigged native C proton-c. I've not really properly compared apples with apples or anything but it empirically suggests that there might not be too much gain using a swig based proton-c Node.js (well once V8 uses asm.js). I must admit that I'm quite pleased with the way it has turned out, emscripten definitely ranks up there as one of my favourite things in the world of software - it really appeals to my twisted sense of the absurd :-D Frase
