Re: [VOTE] merge the proton mailing list into the users/dev lists
+1 On 30/03/16 11:25, Robbie Gemmell wrote: Hello folks, Many moons ago, a seperate mailing list was established for Proton, back when it was purely a protocol engine other components would use. Its scope has since expanded beyond that and the separate mailing list has I feel been an increasing source of confusion and hassle of late more than anything else. Collapsing it into the other larger existing lists we have (that the traffic would otherwise have been on) seems to me like it would be an improvement across the board, and as such I have called this vote. I would propose that discussion (such as this) would head to the users@q.a.o list to join the similar/related/duplicate traffic already present, with remaining things going to the dev@q.a.o list as consistent with that list (e.g JIRA, GitHub integration mails, ReviewBoard, though the latter was never actually directed to proton@ to begin with..). Whilst redirecting JIRA etc emails should be easy enough (has been done before), I dont know what the precise options are regarding existing mail subscriptions to the list. There are significantly more subscribers to users@ than proton@, and many are duplicates, but some are not. I'd need to discuss options with infra, but first things first, the vote. I have gone straight to a vote on this because I feel this has already been discussed enough previously over time that many people will have already thought about it enough to quickly vote one way or the other, and it is past time to act on it if things head that way. Obviously things can be further discusssed at this point also if desired. Note that both users@ and proton@ are in the recipients. I expect the thread will splinter when someone forgets to reply-all, as almost all cross-posted thread on the lists do, but at least it can start on both for visibility to all. Robbie - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Does anyone read this list?
+1 on Alan's comments Qpid has lots of components and a single cohesive user list as the "entry point" is the best way to foster community IMHO. F. On 24/03/16 21:29, Alan Conway wrote: On Thu, 2016-03-24 at 18:23 +, Troy Daniels wrote: This was also the only mailing list that I found a reference to when I was looking at the proton site. Which makes me agree that you (or at least the documentation) are trying to recruit developers rather than users. :-) It is a historical accident I think. The Qpid project has a lot of interesting and inter-related things going on around AMQP. Proton is an important sub-project but not the only one. In the early days it was felt by some that proton really needed its own list, but I think in practice that has turned out to be a bad idea that just isolates and breaks up discussions. The user list is not so heavily trafficked and most interesting discussions that touch on proton also touch on other Qpid projects. So I generally post to the user list but I keep an eye on this one. I'd change the reference on the site if I wasn't afeared of a firestorm. Anyone who objects please complain on the proton list only ;)
Re: Fwd: Unable to follow the connection of pn_pipe() with file descriptor used for poll()
Hello Sanny, I know nothing about MQX OS so there is a limit to how much I can help you. I ported proton to JavaScript which has similar complications, though the workarounds are likely different. Firstly the good news is that pipe() is only actually used for pn_messenger_interrupt() in JavaScript I actually just didn't bother to implement that method as it makes little sense in an asynchronous environment. The JavaScript binding uses emscripten https://github.com/kripken/emscripten/wiki to compile from C to JavaScript and has a JavaScript library to emulate many of the posix C network API calls, for the case of pipe() the call is IIRC actually a null/do nothing implementation these two lines in messenger.c // Explicitly initialise pipe file descriptors to invalid values in case pipe // fails, if we don't do this m->ctrl[0] could default to 0 - which is stdin. m->ctrl[0] = -1; m->ctrl[1] = -1; are down to me as a result of that - in the JavaScript pipe does indeed fail and this explicitly ensures I get invalid file descriptors (otherwise you can see spurious activity on stdin!!??#) The bad news is that proton messenger uses poll for much more than just the pipe, the selector module is actually mainly used for handling activity on the main network sockets handling the AMQP transfer. The way I dealt with this stuff can be found in proton-c/bindings/javascript/module.js mostly in _pumpOnce how it works (roughly) is that it receives events from JavaScript WebSocket event handlers (onopen, onmessage, onclose etc.) It actually tries to emulate the flow of class Pump in tests/python/proton_tests/messenger.py (which is another place to look for ideas), my code does use a "poll" of sorts, emscripten actually emulates poll in that it maintains flags corresponding to WebSocket activity on the emulated file descriptors, of course poll is a blocking call so you wouldn't want to use it in the normal way on an async system hence why I call it when I receive any WebSocket event it's really used to map back to the actual (emulated) file descriptor that triggered the event. I have to say that stuff was all pretty fiddly and a bit specific to the environment that you are working with and it took me quite a while to get it working, but it might at least give you a few pointers. Regards, Frase On 27/11/15 05:42, Sanny wrote: 1. I am porting qpid proton c for MQX OS. Now I don't have the equivalent's to pipe() nor poll(). 2.I understand I need to do something similar to Windows. *Questions:* *1> I am unable to follow the code flow used in porting for Windows, I see two sockets being created to simulated the pipe ends. Further on not fully able to grasp. Will there be a document to understand the flow? It would be grateful if someone can help in the right direction?* *2> What is the significance of the selector module? What is the data that is added to the selector's datastructure and how this aids the sending of the AMQP packet?* Thanks in Advance Regards
Proton-c Websocket Listeners - thread from off list discussion
Couple of replies inline. On 06/02/15 13:19, Rafael Schloming wrote: A couple of questions/comments inline, but first off, any reason this isn't on the list? (I don't mind, just curious.) No good reason; Alan PMed me and I replied, then though I'd best copy you guys. It's slightly head explodingly long, so if conversation develops it might be best to split it up a bit - it was mainly a bit of a brain dump for Alan and I got carried away :-D I've moved to the Qpid user and proton lists now for maximum exposure. On Fri, Feb 6, 2015 at 6:20 AM, Fraser Adams fraser.ad...@blueyonder.co.uk mailto:fraser.ad...@blueyonder.co.uk wrote: Hi Again Alan, Sorry this has turned out to be massively TL;DR I kind of got on a roll.. On the WebSocket thing it's worth pointing out that I've mainly been in the game of *using* them and have never had the pleasure of writing an implementation from scratch, but OTOH I've done a reasonable amount ofhacking around - but that's mostly been in JavaScript and Python implementations so for C things are more awkward. I've copied Rafael so he's in the loop I've also copied Gordon, 'cause I'd really quite like WebSocket support in qpidd at some point and Rob because he implemented the WebSocket transport in the Java Broker and I suspect he knows way more than me - especially about the trades around different implementation choices, he also knows the AMQP WebSocket spec intricacies way better than me so will be better placed to advise gotchas - and also I guess an approach that makes is easier for proton-j to introduce WebSocket support too. I guess first off I should say that when I suggested it might be a car crash if not thought through I was perhaps being a little parochial. As you know the JavaScript binding uses emscripten to compile proton-c to JavaScript - the way that works is the core grammar is compiled to LLVM bitcode and ends up as asm.js but library/system calls either wind up calling other compiled code or they break out into some pure JavaScript, that's the case for the network code and basically all the posix network calls get trapped and faked in a useful way; library.js and library_sockfs.js are the main places to look if you're interested. I guess that the key point is that all the *socket* calls in proton-c wind up as *WebSocket* stuff in the compiled JavaScript, for browsers it uses native WebSockets and for Node.js it uses the ws WebSocket library, which is I think the most popular one. The gnarly bit that I can think of is that clearly adding WebSocket support to proton-c risks accidentally causing the JavaScript stuff to implement WebSocket over WebSocket, which would be quite funny but probably not terribly useful :-D It sounds like we quite probably would want to keep any web socket stuff compile-time optional and simply not build it at all with emscripten. That would a) avoid the possibility of nested websocketry, and b) keep useless code out of the already large proton.js file. It's worth keeping an open mind. The proton-messenger.js stuff it indeed a bit big, most of that is actually down to the emscripten runtime stuff and there's a limit to what is easy to strip, there's some work ongoing on emscripten to make this a bit better. It's 500K minified and it could be compressed. I'm all for making it smaller but I doubt it'll make a huge difference I'm afraid. My main concern would be to make sure that any bits of code to add an API to select between TCP and WebSockets *weren't* removed I *want* to be able to pass that info to the emscripten code for when I get round to adding native TCP support. Another thing I worry a little about is how one implements the server side, there are two choices 1. Have a separate WebSocket transport 2. Note that WebSockets are actually a frame based protocol layered on top of TCP and initiated via an HTTP UPGRADE command. The spec is here: https://tools.ietf.org/html/rfc6455 The Java Broker (currently) takes the former approach, it's a sensible and convenient approach because it uses Jetty as the Web Server for its UI and Jetty comes complete with a WebSocket implementation, but there's a down side - you have to stand up a separate port so basically AMQP over TCP connections connect to one port and AMQP over WebSocket connections connect over a different port. But as I say WebSockets are actually layered over TCP so it's possible if you have more control over the server to look at the data on the TCP buffers and detect that it's actually WebSocket, so from a user perspective it would be *really nice* and technically possible to have a single listen port. When I suggested implementing it in proton I meant the latter, simply autodetecting and upgrading. Andrew has
Re: puzzling issue with javascript bindings
That's very generous of Rafael - he spotted the wood when I was still staring at the trees :-) I was quite impressed. I think I can at least claim the dubious honour of being one of the very few people who has managed to introduce an uninitialised pointer error into JavaScript code! I don't know whether to be embarrassed or proud :-D Frase On 02/02/15 12:43, Rafael Schloming wrote: FYI, thanks to some help from Fraser, this issue should now be resolved. --Rafael On Sat, Jan 31, 2015 at 1:24 PM, Rafael Schloming r...@alum.mit.edu wrote: On Sat, Jan 31, 2015 at 12:27 PM, Fraser Adams fraser.ad...@blueyonder.co.uk wrote: Hopefully you got the build I mailed you, but as an update I've upgraded my system to the latest emscripten incoming: emcc (Emscripten GCC-like replacement + linker emulating GNU ld ) 1.29.8 clang version 3.5.0 And did a Debug build on a clean system as before and I'm still not seeing any issues like the one you described and my recv.js seems pretty happy however many times I call send.js I'm pretty stumped!! What system are you running? Is there anything quirky? Do you have any exotic compilers or an unusual path? I did get your build and it worked fine for me. I emailed you a copy of my build just in case you are curious. My versions are: emcc (Emscripten GCC-like replacement) 1.29.0 (commit fdf24b478e1b26c0362a1627aca49ef82fd53f6a) clang version 3.4 My system is just stock fedora 20 as far as I'm aware. I installed emscripten by just following the directions in the README. --Rafael Frase On 31/01/15 15:37, Rafael Schloming wrote: Any chance you could send me a copy of your proton.js so I can try on my system? --Rafael On Sat, Jan 31, 2015 at 10:32 AM, Fraser Adams fraser.ad...@blueyonder.co.uk wrote: Hi again Rafi, As I'm on a roll today. So I've just done: cd build make clean rm CMakeCache.txt cmake -DCMAKE_BUILD_TYPE=Debug .. (which gives the message: JavaScript build type is Debug) make and when I did ./recv.js and in another window ./send.js I'm not seeing any issue: ./recv.js pipe() returning an error as we do not support them Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Looking in node_modules/qpid-proton-messenger/lib/proton-messenger.js I've definitely got the unminified/Debug version in play (which is also borne out by the pipe() returning an error as we do not support them message from emscripten's stub pipe call). So I'm not seeing what you are seeing on my system. I'm running Linux Mint 17.1 Rebecca emcc (Emscripten GCC-like replacement + linker emulating GNU ld ) 1.28.2 clang version 3.4 node v0.10.33 I doubt the changes I've just committed would make any difference, so there's definitely something weird. I'll update my emscripten/fastcomp versions and see if that introduces this quirk. On the plus side, at least it wasn't my imagination and I really haven't seen this behaviour before :-D If it *is* an emscripten issue it'd be good to have a minimal reproducer to attach to an issue report. Frase On 31/01/15 12:17, Rafael Schloming wrote: Hi, I recently uncovered a puzzling issue with the Javascript bindings. If I fire up the simple recv.js example and then run send.js, it works fine the first time, but the second time around I get the error below. This apparently has been happening for a while (possibly a few months), however I haven't noticed because it only happens with debug builds, and only then the second time around. With a regular build everything seems to work fine. I googled around a bit for this particular error and there are a bunch of threads talking about how casting function pointers doesn't work with emscripten and you need to avoid that, but I don't believe we actually do that ever, and I see nothing to indicate that this sort of error would go away with a non Debug build. The stack trace (which you only get after rebuilding with ASSERTIONS=2) seems pretty straightforward. It is inside pn_class_new which delegates to a function pointer held in the pn_class_t struct that is passed in. I believe that function pointer lookup is what is failing, but when I put printfs in the C code to confirm this, the problem goes away. At this point I'm kind of left scratching my head. The only thing I can think of short of a compiler bug is that somehow the pn_class_t struct is becoming corrupted, but I would expect valgrind to show up any sort of memory issues like that, unless somehow it is only being triggered from
Re: puzzling issue with javascript bindings
Hi again Rafi, As I'm on a roll today. So I've just done: cd build make clean rm CMakeCache.txt cmake -DCMAKE_BUILD_TYPE=Debug .. (which gives the message: JavaScript build type is Debug) make and when I did ./recv.js and in another window ./send.js I'm not seeing any issue: ./recv.js pipe() returning an error as we do not support them Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Looking in node_modules/qpid-proton-messenger/lib/proton-messenger.js I've definitely got the unminified/Debug version in play (which is also borne out by the pipe() returning an error as we do not support them message from emscripten's stub pipe call). So I'm not seeing what you are seeing on my system. I'm running Linux Mint 17.1 Rebecca emcc (Emscripten GCC-like replacement + linker emulating GNU ld ) 1.28.2 clang version 3.4 node v0.10.33 I doubt the changes I've just committed would make any difference, so there's definitely something weird. I'll update my emscripten/fastcomp versions and see if that introduces this quirk. On the plus side, at least it wasn't my imagination and I really haven't seen this behaviour before :-D If it *is* an emscripten issue it'd be good to have a minimal reproducer to attach to an issue report. Frase On 31/01/15 12:17, Rafael Schloming wrote: Hi, I recently uncovered a puzzling issue with the Javascript bindings. If I fire up the simple recv.js example and then run send.js, it works fine the first time, but the second time around I get the error below. This apparently has been happening for a while (possibly a few months), however I haven't noticed because it only happens with debug builds, and only then the second time around. With a regular build everything seems to work fine. I googled around a bit for this particular error and there are a bunch of threads talking about how casting function pointers doesn't work with emscripten and you need to avoid that, but I don't believe we actually do that ever, and I see nothing to indicate that this sort of error would go away with a non Debug build. The stack trace (which you only get after rebuilding with ASSERTIONS=2) seems pretty straightforward. It is inside pn_class_new which delegates to a function pointer held in the pn_class_t struct that is passed in. I believe that function pointer lookup is what is failing, but when I put printfs in the C code to confirm this, the problem goes away. At this point I'm kind of left scratching my head. The only thing I can think of short of a compiler bug is that somehow the pn_class_t struct is becoming corrupted, but I would expect valgrind to show up any sort of memory issues like that, unless somehow it is only being triggered from the javascript binding. Anyways, I figured I should give people a heads up. The workaround is easy enough, just build with non Debug build and everything seems to work fine. Beyond that, any insight would be greatly appreciated. == [rhs@localhost proton]$ examples/messenger/javascript/recv.js pipe() returning an error as we do not support them Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Invalid function pointer '14' called with signature 'iii'. Perhaps this is an invalid value (e.g. caused by calling a virtual method on a NULL pointer)? Or calling a function with an incorrect type, which will fail? (it is worth building your source files with -Werror (warnings are errors), as warnings can indicate undefined behavior which can cause this) This pointer might make sense in another type signature: ii: _pn_void_reify : 0 i: 0 ii: 0 vii: 0 vi: 0 14 14 /home/rhs/proton/node_modules/qpid-proton/lib/proton.js:4923 throw ex; ^ abort() at Error at jsStackTrace (/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:5826:13) at stackTrace (/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:5843:22) at abort (/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:76848:25) at nullFunc_iii (/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:11274:705) at Array.b686 [as 14] (/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:73421:47) at _pn_class_new (/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:11761:39) at _pn_map (/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:12759:11) at _pn_hash (/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:13185:11) at Array._pn_transport_initialize [as 76]
[jira] [Commented] (PROTON-810) Publish javascript binding on npm
[ https://issues.apache.org/jira/browse/PROTON-810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14299841#comment-14299841 ] Fraser Adams commented on PROTON-810: - Matteo, I've made the changes to the package name and published qpid-proton-messenger to npm central. Publish javascript binding on npm - Key: PROTON-810 URL: https://issues.apache.org/jira/browse/PROTON-810 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.8 Environment: NodeJS Reporter: Matteo Murgida Labels: javascript, nodejs, npm Fix For: 0.9 It would be very useful to the nodejs community to have the javascript binding published on npm as qpid-proton. If you prefer, I can maintain that release for you :) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: puzzling issue with javascript bindings
Hopefully you got the build I mailed you, but as an update I've upgraded my system to the latest emscripten incoming: emcc (Emscripten GCC-like replacement + linker emulating GNU ld ) 1.29.8 clang version 3.5.0 And did a Debug build on a clean system as before and I'm still not seeing any issues like the one you described and my recv.js seems pretty happy however many times I call send.js I'm pretty stumped!! What system are you running? Is there anything quirky? Do you have any exotic compilers or an unusual path? Frase On 31/01/15 15:37, Rafael Schloming wrote: Any chance you could send me a copy of your proton.js so I can try on my system? --Rafael On Sat, Jan 31, 2015 at 10:32 AM, Fraser Adams fraser.ad...@blueyonder.co.uk wrote: Hi again Rafi, As I'm on a roll today. So I've just done: cd build make clean rm CMakeCache.txt cmake -DCMAKE_BUILD_TYPE=Debug .. (which gives the message: JavaScript build type is Debug) make and when I did ./recv.js and in another window ./send.js I'm not seeing any issue: ./recv.js pipe() returning an error as we do not support them Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Looking in node_modules/qpid-proton-messenger/lib/proton-messenger.js I've definitely got the unminified/Debug version in play (which is also borne out by the pipe() returning an error as we do not support them message from emscripten's stub pipe call). So I'm not seeing what you are seeing on my system. I'm running Linux Mint 17.1 Rebecca emcc (Emscripten GCC-like replacement + linker emulating GNU ld ) 1.28.2 clang version 3.4 node v0.10.33 I doubt the changes I've just committed would make any difference, so there's definitely something weird. I'll update my emscripten/fastcomp versions and see if that introduces this quirk. On the plus side, at least it wasn't my imagination and I really haven't seen this behaviour before :-D If it *is* an emscripten issue it'd be good to have a minimal reproducer to attach to an issue report. Frase On 31/01/15 12:17, Rafael Schloming wrote: Hi, I recently uncovered a puzzling issue with the Javascript bindings. If I fire up the simple recv.js example and then run send.js, it works fine the first time, but the second time around I get the error below. This apparently has been happening for a while (possibly a few months), however I haven't noticed because it only happens with debug builds, and only then the second time around. With a regular build everything seems to work fine. I googled around a bit for this particular error and there are a bunch of threads talking about how casting function pointers doesn't work with emscripten and you need to avoid that, but I don't believe we actually do that ever, and I see nothing to indicate that this sort of error would go away with a non Debug build. The stack trace (which you only get after rebuilding with ASSERTIONS=2) seems pretty straightforward. It is inside pn_class_new which delegates to a function pointer held in the pn_class_t struct that is passed in. I believe that function pointer lookup is what is failing, but when I put printfs in the C code to confirm this, the problem goes away. At this point I'm kind of left scratching my head. The only thing I can think of short of a compiler bug is that somehow the pn_class_t struct is becoming corrupted, but I would expect valgrind to show up any sort of memory issues like that, unless somehow it is only being triggered from the javascript binding. Anyways, I figured I should give people a heads up. The workaround is easy enough, just build with non Debug build and everything seems to work fine. Beyond that, any insight would be greatly appreciated. == [rhs@localhost proton]$ examples/messenger/javascript/recv.js pipe() returning an error as we do not support them Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Invalid function pointer '14' called with signature 'iii'. Perhaps this is an invalid value (e.g. caused by calling a virtual method on a NULL pointer)? Or calling a function with an incorrect type, which will fail? (it is worth building your source files with -Werror (warnings are errors), as warnings can indicate undefined behavior which can cause this) This pointer might make sense in another type signature: ii: _pn_void_reify : 0 i: 0 ii: 0 vii: 0 vi: 0 14 14 /home/rhs/proton/node_modules/qpid-proton/lib/proton.js:4923 throw ex; ^ abort() at Error
Heads up - change to ws WebSocket library causes js binding to break.
Hey All, I was planning on making some tweaks to the JavaScript binding - in particular changing the package name from qpid-proton to qpid-proton-messenger. I think that the latter is better because we'll likely want qpid-proton-reactor IDC and it would be a bit bloaty to put both APIs in one package. Anyway, I did an update to the proton trunk latest and a vanilla build environment and imagine my surprise :-) when send.js barfed. It looks like some change in the ws WebSocket library in npm central has broken something. From what I've been able to ascertain it was the change between 0.5.0 and 0.6.0 where the issue lies (sometime around 5th December by the looks of it). TBH I probably should have been a bit more explicit with versions of dependencies, but I'm kind of learning with npm and rather making up as I go :-D but I've now pushed a change to trunk https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git that pins the ws version to 0.5.0 for now. If you get bitten by this and don't want to update to the latest proton in trunk just yet it's fairly easy to sort out, the following should do the trick: cd proton-root rm -rf node_modules/ws npm install ws@0.5.0 It'll clearly be good to work out what has actually changed, but I'll need a bit of quality time to do more digging, it might be something in the binding code, but it *could* be something in the emscripten network code that has been borked, for now pinning the ws version seems the best approach. Cheers, Frase
Re: puzzling issue with javascript bindings
Thanks for the heads up Rafi. I'll take a look when I've got a moment, that's not actually something I've noticed before. TBH I'm *pretty sure* that when I was developing this stuff I'd have done what you've done, so I'm a bit baffled but I've mostly been using non Debug builds lately and it's quite possible that some emscripten change has caused this - it's quite a dynamic project. Hopefully you noticed my other mail on the ws WebSocket library change borking the bindings, sigh! Be aware that I'm currently in the process of changing the package name to qpid-proton-messenger. F. On 31/01/15 12:17, Rafael Schloming wrote: Hi, I recently uncovered a puzzling issue with the Javascript bindings. If I fire up the simple recv.js example and then run send.js, it works fine the first time, but the second time around I get the error below. This apparently has been happening for a while (possibly a few months), however I haven't noticed because it only happens with debug builds, and only then the second time around. With a regular build everything seems to work fine. I googled around a bit for this particular error and there are a bunch of threads talking about how casting function pointers doesn't work with emscripten and you need to avoid that, but I don't believe we actually do that ever, and I see nothing to indicate that this sort of error would go away with a non Debug build. The stack trace (which you only get after rebuilding with ASSERTIONS=2) seems pretty straightforward. It is inside pn_class_new which delegates to a function pointer held in the pn_class_t struct that is passed in. I believe that function pointer lookup is what is failing, but when I put printfs in the C code to confirm this, the problem goes away. At this point I'm kind of left scratching my head. The only thing I can think of short of a compiler bug is that somehow the pn_class_t struct is becoming corrupted, but I would expect valgrind to show up any sort of memory issues like that, unless somehow it is only being triggered from the javascript binding. Anyways, I figured I should give people a heads up. The workaround is easy enough, just build with non Debug build and everything seems to work fine. Beyond that, any insight would be greatly appreciated. == [rhs@localhost proton]$ examples/messenger/javascript/recv.js pipe() returning an error as we do not support them Address: amqp://0.0.0.0 Subject: UK.WEATHER Content: Hello World! Invalid function pointer '14' called with signature 'iii'. Perhaps this is an invalid value (e.g. caused by calling a virtual method on a NULL pointer)? Or calling a function with an incorrect type, which will fail? (it is worth building your source files with -Werror (warnings are errors), as warnings can indicate undefined behavior which can cause this) This pointer might make sense in another type signature: ii: _pn_void_reify : 0 i: 0 ii: 0 vii: 0 vi: 0 14 14 /home/rhs/proton/node_modules/qpid-proton/lib/proton.js:4923 throw ex; ^ abort() at Error at jsStackTrace (/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:5826:13) at stackTrace (/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:5843:22) at abort (/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:76848:25) at nullFunc_iii (/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:11274:705) at Array.b686 [as 14] (/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:73421:47) at _pn_class_new (/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:11761:39) at _pn_map (/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:12759:11) at _pn_hash (/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:13185:11) at Array._pn_transport_initialize [as 76] (/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:53534:13) at _pn_class_new (/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:11775:29)
[jira] [Created] (PROTON-813) Pulling latest version of ws WebSocket library from npm central breaks JavaScript bindings.
Fraser Adams created PROTON-813: --- Summary: Pulling latest version of ws WebSocket library from npm central breaks JavaScript bindings. Key: PROTON-813 URL: https://issues.apache.org/jira/browse/PROTON-813 Project: Qpid Proton Issue Type: Bug Reporter: Fraser Adams Assignee: Fraser Adams Priority: Blocker It looks like some change in the ws WebSocket library in npm central has broken something. From what I've been able to ascertain it was the change between 0.5.0 and 0.6.0 where the issue lies (sometime around 5th December by the looks of it). TBH I probably should have been a bit more explicit with versions of dependencies, but I'm kind of learning with npm and rather making up as I go but I've now pushed a change to trunk https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git that pins the ws version to 0.5.0 for now. If you get bitten by this and don't want to update to the latest proton in trunk just yet it's fairly easy to sort out, the following should do the trick: cd proton-root rm -rf node_modules/ws npm install ws@0.5.0 It'll clearly be good to work out what has actually changed, but I'll need a bit of quality time to do more digging, it might be something in the binding code, but it *could* be something in the emscripten network code that has been borked, for now pinning the ws version seems the best approach. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-813) Pulling latest version of ws WebSocket library from npm central breaks JavaScript bindings.
[ https://issues.apache.org/jira/browse/PROTON-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fraser Adams closed PROTON-813. --- Pulling latest version of ws WebSocket library from npm central breaks JavaScript bindings. --- Key: PROTON-813 URL: https://issues.apache.org/jira/browse/PROTON-813 Project: Qpid Proton Issue Type: Bug Reporter: Fraser Adams Assignee: Fraser Adams Priority: Blocker It looks like some change in the ws WebSocket library in npm central has broken something. From what I've been able to ascertain it was the change between 0.5.0 and 0.6.0 where the issue lies (sometime around 5th December by the looks of it). TBH I probably should have been a bit more explicit with versions of dependencies, but I'm kind of learning with npm and rather making up as I go but I've now pushed a change to trunk https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git that pins the ws version to 0.5.0 for now. If you get bitten by this and don't want to update to the latest proton in trunk just yet it's fairly easy to sort out, the following should do the trick: cd proton-root rm -rf node_modules/ws npm install ws@0.5.0 It'll clearly be good to work out what has actually changed, but I'll need a bit of quality time to do more digging, it might be something in the binding code, but it *could* be something in the emscripten network code that has been borked, for now pinning the ws version seems the best approach. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-813) Pulling latest version of ws WebSocket library from npm central breaks JavaScript bindings.
[ https://issues.apache.org/jira/browse/PROTON-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fraser Adams resolved PROTON-813. - Resolution: Fixed Sorry - I should've raised this Jira *before* I fixed things for tracking purposes, my bad! Fixed here: https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=e9db8dfba24646d17e7caf17c7e1fea3319cc603 Pulling latest version of ws WebSocket library from npm central breaks JavaScript bindings. --- Key: PROTON-813 URL: https://issues.apache.org/jira/browse/PROTON-813 Project: Qpid Proton Issue Type: Bug Reporter: Fraser Adams Assignee: Fraser Adams Priority: Blocker It looks like some change in the ws WebSocket library in npm central has broken something. From what I've been able to ascertain it was the change between 0.5.0 and 0.6.0 where the issue lies (sometime around 5th December by the looks of it). TBH I probably should have been a bit more explicit with versions of dependencies, but I'm kind of learning with npm and rather making up as I go but I've now pushed a change to trunk https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git that pins the ws version to 0.5.0 for now. If you get bitten by this and don't want to update to the latest proton in trunk just yet it's fairly easy to sort out, the following should do the trick: cd proton-root rm -rf node_modules/ws npm install ws@0.5.0 It'll clearly be good to work out what has actually changed, but I'll need a bit of quality time to do more digging, it might be something in the binding code, but it *could* be something in the emscripten network code that has been borked, for now pinning the ws version seems the best approach. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Welcome Dominic Evans as a Qpid committer
On 15/12/14 11:03, Robbie Gemmell wrote: The Apache Qpid PMC have voted to grant commit rights to Dominic Evans in recognition of his contributions to and involvement with Proton. Welcome, Dominic! Welcome indeed Dominic!
[jira] [Created] (PROTON-774) Fix warnings in log.c and url.c and re-enable -Werror
Fraser Adams created PROTON-774:
---
Summary: Fix warnings in log.c and url.c and re-enable -Werror
Key: PROTON-774
URL: https://issues.apache.org/jira/browse/PROTON-774
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Fraser Adams
Priority: Trivial
The files log.c and url.c generate warnings when compiled with CLang/emscripten
this prevents -Werror being used.
The warnings were:
[ 56%] Building C object
proton-c/bindings/javascript/CMakeFiles/qpid-proton-bitcode.dir/__/__/src/log.c.o
/home/fadams/qpid/git/qpid-proton/proton-c/src/log.c:38:13: warning: explicitly
assigning a variable of type 'bool' to itself [-Wself-assign]
enabled = enabled;
and
[ 58%] Building C object
proton-c/bindings/javascript/CMakeFiles/qpid-proton-bitcode.dir/__/__/src/url.c.o
/home/fadams/qpid/git/qpid-proton/proton-c/src/url.c:133:19: warning: unused
function 'len' [-Wunused-function]
static inline int len(const char *str) { return str ? strlen(str) : 0; }
The trivial fixes were to remove the spurious function in url.c and rename the
formal parameter to pn_log_enable in log.c
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-774) Fix warnings in log.c and url.c and re-enable -Werror
[
https://issues.apache.org/jira/browse/PROTON-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fraser Adams resolved PROTON-774.
-
Resolution: Fixed
Fix warnings in log.c and url.c and re-enable -Werror
-
Key: PROTON-774
URL: https://issues.apache.org/jira/browse/PROTON-774
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Fraser Adams
Priority: Trivial
The files log.c and url.c generate warnings when compiled with
CLang/emscripten this prevents -Werror being used.
The warnings were:
[ 56%] Building C object
proton-c/bindings/javascript/CMakeFiles/qpid-proton-bitcode.dir/__/__/src/log.c.o
/home/fadams/qpid/git/qpid-proton/proton-c/src/log.c:38:13: warning:
explicitly
assigning a variable of type 'bool' to itself [-Wself-assign]
enabled = enabled;
and
[ 58%] Building C object
proton-c/bindings/javascript/CMakeFiles/qpid-proton-bitcode.dir/__/__/src/url.c.o
/home/fadams/qpid/git/qpid-proton/proton-c/src/url.c:133:19: warning: unused
function 'len' [-Wunused-function]
static inline int len(const char *str) { return str ? strlen(str) : 0; }
The trivial fixes were to remove the spurious function in url.c and rename
the formal parameter to pn_log_enable in log.c
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Proton Python install shenanigans
Hey all, I've been tearing my hair out a bit trying to figure why I can't see the relevant Python modules. I build Proton on a clean Linux Mint 17 system (which is based on Ubuntu 14.04) make all builds successfully and sudo make install installs the following: fadams@zappa /usr/local/lib/proton/bindings/python $ ls -al total 2120 drwxr-xr-x 2 root root4096 Nov 30 12:28 . drwxr-xr-x 5 root root4096 Nov 30 12:20 .. -rw-r--r-- 1 root root 89278 Nov 30 11:29 cproton.py -rw-r--r-- 1 root root 103293 Nov 30 12:28 cproton.pyc -rw-r--r-- 1 root root 103293 Nov 30 12:28 cproton.pyo -rw-r--r-- 1 root root 1445471 Nov 30 12:20 _cproton.so -rw-r--r-- 1 root root 109162 Nov 30 11:20 __init__.py -rw-r--r-- 1 root root 151464 Nov 30 12:28 __init__.pyc -rw-r--r-- 1 root root 151257 Nov 30 12:28 __init__.pyo I set PYTHONPATH=/usr/local/lib/proton/bindings/python but when I try ./msgr-recv.py I get Traceback (most recent call last): File ./msgr-recv.py, line 23, in module from proton import * ImportError: No module named proton Now I'm thinking that make install hasn't pulled all of the necessary files into /usr/local/lib/proton/bindings/python the reason I'm thinking that is when I tried running source config.sh I noticed that the PYTHONPATH it created looked like PYTHONPATH=/home/fadams/qpid/git/qpid-proton/tests/python:/home/fadams/qpid/git/qpid-proton/proton-c/bindings/python:/home/fadams/qpid/git/qpid-proton/build/proton-c/bindings/python and this *does* appear to work, the significant bit seems to be the /home/fadams/qpid/git/qpid-proton/proton-c/bindings/python bit, because when I tried: PYTHONPATH=/home/fadams/qpid/git/qpid-proton/proton-c/bindings/python:/usr/local/lib/proton/bindings/python that worked too. So I'm thinking that the directory proton and its contents in qpid-proton/proton-c/bindings/python need to be copied to /usr/local/lib/proton/bindings/python as part of the make install process too. Does that seem about right? Cheers, Frase
[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)
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
Re: proton-c event test stable and fast for 5 billion messages
On Thu, 2014-11-20 at 14:10 -0500, Michael Goulish wrote: I am using two processors, both Intel Xeon E5420 @ 2.50GHz with 6144 KB cache. (Letting the OS decide which processors to use for my two processes.) On that system, with the above credit scheme, the test is sustaining throughput of 408,500 messages per second . That's over a single link, between two singly-threaded processes. This is significantly faster than my previous, non-event-based code, and I find the code*much* easier to understand. Out of curiosity on the same hardware how does that test perform relative to the messenger based soak tests msgr-send/msgr-recv and how about if you tweaked msgr-send/msgr-recv to use non-blocking and passive mode. I'm curious about where the messenger bottlenecks might be? FWIW I definitely think there's mileage in event based operation - I'm also pretty interested in the best way to have things scale across loads of cores too, I think that's one worry I have with qpidd and the traditional clients. Do we know when lock contention starts to limit throughput? Given initiatives in ActiveMQ Apollo for more aync. lock-free operation (I think it uses hawt-dispatch, but I'm no expert) I suspect that now is a good time to think about how qpid based systems might scale across loads of cores. That said with talk of new APIs I think that we should have a reasonably clear roadmap, we've already got qpid::messaging and messenger, two separate AMQP 1.0 JMS clients not to mention potential confusion on the native python versus the python qpid::messaging binding (and don't get me started on QMF - three separate APIs depending on the language :'( ) I don't think we've done a great job clearing up confusion arounf the differing APIs that we have. I could have predicted a change brewing, 'cause I've finally (just about) got my head around Messenger :-D Frase
Re: CorrelationId
On 08/10/14 08:16, xavier wrote:
Hi Frase,
Thanks for your explanation, but here, my code:
In the requester:
char * corrId;
.
.
pn_bytes_t bytes = pn_bytes(correlationId.size(), corrId);
pn_atom_t id;
id.type = PN_STRING;
id.u.as_bytes = bytes;
pn_message_set_correlation_id(message, id);
and after, send it
pn_messenger_put(messengerProducer, message);
I see on the broker, the correlationId is correctly setted, so no pb.
after I wait the answer, but I would like (like JMS) only wake up on an
answer at my question (and the correlationId is here to do that)
in CMS
MessageConsumer* consumer = session-createConsumer(destination,
JMSCorrelationID=' + correlationId + ');
consumer-start();
But with qpid proton and messenger, if I do that:
I get the response, and I does not accept it, if the correlationId recieve,
is not the good one, but for me, it's not a good practice, because we
retrieve the message (network traffic) in right case, but in wrong case too.
So I would like to the same things like CMS, but how
pn_selectable_t ??
pn_selector_t
Thank you
Xav
--
View this message in context:
http://qpid.2158936.n2.nabble.com/CorrelationId-tp7614606p7614771.html
Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
Re:
MessageConsumer* consumer = session-createConsumer(destination,
JMSCorrelationID=' + correlationId + ');
consumer-start();
That's exactly the bit that I've been trying to explain is the complicated bit,
and the bit that Robbie referred to in his previous reply.
In JMS and I guess with CMS that syntax means:
| MessageConsumer
http://docs.oracle.com/javaee/5/api/javax/jms/MessageConsumer.html|
|*createConsumer
http://docs.oracle.com/javaee/5/api/javax/jms/Session.html#createConsumer%28javax.jms.Destination,%20java.lang.String,%20boolean%29*(Destination
http://docs.oracle.com/javaee/5/api/javax/jms/Destination.html destination,
String
http://java.sun.com/j2se/1.5/docs/api/java/lang/String.html messageSelector,
boolean NoLocal)|
Creates|MessageConsumer| for the specified destination, using a
message selector.
At an API level it's nice and simple, but there's a lot going on under the hood
and what it's doing is to pass information on the AMQP link attach (I think)
that configures a Message Selector (which is and AMQP filter
https://svn.apache.org/repos/asf/qpid/trunk/qpid/specs/apache-filters.xml#type-selector-filter).
Unfortunately (and I'd agree somewhat annoyingly!!) proton Messenger does not
yet support this type of sophistication when specifying subscriptions, I wish
it did myself, but unfortunately it currently does not :-(
The stuff:
pn_selectable_t ??
pn_selector_t
Relates to something completely different I'm afraid those are actually related
to low level socket selectors (i.e. more related to the select/poll/epoll
system calls than Message Selectors). Their main use is for replacing
Messenger's internal network event loop so it can be more easily integrated
with other applications.
I can't recall why you said you were using Messenger specifically, If you can
use C++ (rather than C) you might want to look at the qpid::messaging API, you
can definitely do the sort of thing that you want (e.g. using the broker to
perform filtering based on CorrelationID) using qpid::messaging. The syntax is
a little different in that I don't believe that there's a particular overloaded
createConsumer method call to set a selector and you'd have to do it in the
Address String - it'd look *something* like the following (I think, I've not
tried it YMMV) BTW if you haven't come across it drain is a little qpid demo
application that's really useful for trying out Address Strings. So if you have
a queue called queue1 this should filter on messages with a given correlation
ID.
./drain -b localhost -f \
queue1; {create: receiver, link: {name: test-link, selector:
\correlation_id='mycid'\}}
That's the sort of syntax I'd like to see supported for Messenger Subscriptions
too (but as I say it currently isn't).
I've copied my response to the qpid users mailing list, I tend to recommend
that people post questions there as it tends to have a broader readership than
the proton one.
If you have to use C (as opposed to C++) then as I say Messenger won't do what
you want (though clearly you could do your own filtering inside your
consumer/server client), you could also get a bit more low-level and use the
Engine API, which will allow the sort of thing that you want (qpid::messaging
actually uses the proton Engine API under the hood), but I'm afraid that I
couldn't help you make any progress using Engine as I've not got round to
playing with that myself yet.
Sorry I can't give you a simple answer to your question, hopefully my
explanation of the reasons why is better than it was previously.
In short:
* You can't currently do message
Re: CorrelationId
On 08/10/14 18:49, Rafael Schloming wrote:
On Wed, Oct 8, 2014 at 1:30 PM, Fraser Adams fraser.ad...@blueyonder.co.uk
wrote:
On 08/10/14 08:16, xavier wrote:
Hi Frase,
Thanks for your explanation, but here, my code:
In the requester:
char * corrId;
.
.
pn_bytes_t bytes = pn_bytes(correlationId.size(), corrId);
pn_atom_t id;
id.type = PN_STRING;
id.u.as_bytes = bytes;
pn_message_set_correlation_id(message, id);
and after, send it
pn_messenger_put(messengerProducer, message);
I see on the broker, the correlationId is correctly setted, so no pb.
after I wait the answer, but I would like (like JMS) only wake up on an
answer at my question (and the correlationId is here to do that)
in CMS
MessageConsumer* consumer = session-createConsumer(destination,
JMSCorrelationID=' + correlationId + ');
consumer-start();
But with qpid proton and messenger, if I do that:
I get the response, and I does not accept it, if the correlationId
recieve,
is not the good one, but for me, it's not a good practice, because we
retrieve the message (network traffic) in right case, but in wrong case
too.
So I would like to the same things like CMS, but how
pn_selectable_t ??
pn_selector_t
Thank you
Xav
--
View this message in context: http://qpid.2158936.n2.nabble.
com/CorrelationId-tp7614606p7614771.html
Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
Re:
MessageConsumer* consumer = session-createConsumer(destination,
JMSCorrelationID=' + correlationId + ');
consumer-start();
That's exactly the bit that I've been trying to explain is the complicated
bit, and the bit that Robbie referred to in his previous reply.
In JMS and I guess with CMS that syntax means:
| MessageConsumer http://docs.oracle.com/javaee/5/api/javax/jms/
MessageConsumer.html|
|*createConsumer http://docs.oracle.com/javaee/5/api/javax/jms/
Session.html#createConsumer%28javax.jms.Destination,%
20java.lang.String,%20boolean%29*(Destination http://docs.oracle.com/
javaee/5/api/javax/jms/Destination.html destination,
String http://java.sun.com/j2se/1.5/
docs/api/java/lang/String.html messageSelector,
boolean NoLocal)|
Creates|MessageConsumer| for the specified destination, using a
message selector.
At an API level it's nice and simple, but there's a lot going on under the
hood and what it's doing is to pass information on the AMQP link attach (I
think) that configures a Message Selector (which is and AMQP filter
https://svn.apache.org/repos/asf/qpid/trunk/qpid/specs/
apache-filters.xml#type-selector-filter).
Unfortunately (and I'd agree somewhat annoyingly!!) proton Messenger does
not yet support this type of sophistication when specifying subscriptions,
I wish it did myself, but unfortunately it currently does not :-(
The stuff:
pn_selectable_t ??
pn_selector_t
Relates to something completely different I'm afraid those are actually
related to low level socket selectors (i.e. more related to the
select/poll/epoll system calls than Message Selectors). Their main use is
for replacing Messenger's internal network event loop so it can be more
easily integrated with other applications.
I can't recall why you said you were using Messenger specifically, If you
can use C++ (rather than C) you might want to look at the qpid::messaging
API, you can definitely do the sort of thing that you want (e.g. using the
broker to perform filtering based on CorrelationID) using qpid::messaging.
The syntax is a little different in that I don't believe that there's a
particular overloaded createConsumer method call to set a selector and
you'd have to do it in the Address String - it'd look *something* like the
following (I think, I've not tried it YMMV) BTW if you haven't come across
it drain is a little qpid demo application that's really useful for trying
out Address Strings. So if you have a queue called queue1 this should
filter on messages with a given correlation ID.
./drain -b localhost -f \
queue1; {create: receiver, link: {name: test-link, selector:
\correlation_id='mycid'\}}
That's the sort of syntax I'd like to see supported for Messenger
Subscriptions too (but as I say it currently isn't).
I've copied my response to the qpid users mailing list, I tend to
recommend that people post questions there as it tends to have a broader
readership than the proton one.
If you have to use C (as opposed to C++) then as I say Messenger won't do
what you want (though clearly you could do your own filtering inside your
consumer/server client), you could also get a bit more low-level and use
the Engine API, which will allow the sort of thing that you want
(qpid::messaging actually uses the proton Engine API under the hood), but
I'm afraid that I couldn't help you make any progress using Engine as I've
not got round to playing with that myself yet.
Sorry I can't give you a simple answer to your question, hopefully my
Re: CorrelationId
On 07/10/14 08:04, xavier wrote: Hi all, Thanks you for your reply, help? So if I understand properly, to do that with messenger is not trivial??? But I don't understand why, because with the pattern request/reply in asynchronous mode, and with dedicated queue, we must have this feature. isn't it? So to do that must I take some temporally queue? or using selector (in messenger), but I don't know (with the documentation), how it's works? is there any sample? Thanks a lot for your help Regards -- View this message in context: http://qpid.2158936.n2.nabble.com/CorrelationId-tp7614606p7614740.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com. To be clear I didn't say that it wasn't possible to set a correlation ID with messenger, what I said was that there is no mechanism to establish non-trivial link configuration, which means doing things like message selectors, or even doing topic style subscriptions to a topic exchange on a broker isn't possible. If all you want to do is a basic request/response, for example sending a request to a named queue that has an application receiving from it then have the application respond looping back the correlation ID and using the reply-to then that sort of thing is perfectly possible. To set the correlation ID you need to look at the messenger API documentation specifically the method is: pn_message_correlation_id It's slightly convoluted though as that returns a pn_data object that is owned by the pn_message object so then you have to add or retrieve the actual ID to the pn_data object (it's more of a faff than doing something like setting an address on the message for example). so given the pn data representing the correlation ID if you wanted to add an ID that is a ulong you'd do. pn_data_put_ulong(cid, someulong) If you wanted a string correlation id you have to do something like pn_data_put_string(cid, pn_bytes(strlen(text), text)); retrieving the correlation ID is the reverse. I think that in your original question you mentioned filtering using the correlation ID? That was where the assumption about message selectors came in, if you want the infrastructure e.g. the broker to do the filtering then you can't using messenger, for the reasons that I mentioned about not being able to specify things like amqp filters on the link set up, you can of course filter more manually in the application receiving your request messages. I'm afraid that most of my experience with Messenger is actually in the JavaScript binding that I'm writing, that makes things quite easy as it provides nice OO abstractions so I can just do message.setCorrelationID(); and pass in a JavaScript number, string or a UUID or Binary (the latter two are classes that I wrote as part of the binding). Unfortunately that means that I don't have any decent code snippets showing a complete example in C I've done asynchronous request/response using correlation ID - I basically wrote a port of qpid-config in JavaScript, which is all request/response, so as I say that much is *definitely* possible. That example sends messages to a named node - specifically host:port/qmf.default.direct which is actually an exchange on the broker, it sends its responses to host:port/# well that address when used to create a subscription results in a dynamic queue being created on the broker, you have to do pn_subscription_address to get the name of the new queue. HTH, Frase
Re: Proton 0.8 RC1
On 03/10/14 12:34, Dominic Evans wrote: Rafael Schloming-3 wrote I've created 0.8 RC1 and posted it in the usual locations. The source can be found here: http://people.apache.org/~rhs/qpid-proton-0.8rc1/ I know it is a *very* minor issue, but just for tidyness could someone fix PROTON-618 for 0.8 ? -- View this message in context: http://qpid.2158936.n2.nabble.com/Proton-0-8-RC1-tp7614474p7614647.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com. And possibly PROTON-571 too? See the thread proton Messenger error handling/recovery REQUEST FEEDBACK! on the qpid user list, I *think* Dominic's patch should go some way to improving that (is that correct Dominic?) Frase
Re: proton javascript binding problem/question
On 11/09/14 15:25, Dominic Evans wrote: fadams wrote What do you think of the approach that I've taken? My rationale for compiling proton-c to JavaScript and using a thin (ish) binding layer rather than doing a ground-up native JavaScript rewrite was primarily about support. I figured that there was a lot of effort being put into maintaining proton-c and that was what might be considered the canonical or reference implementation, so tracking improvements would end up being a pain with a separate code-base, whereas the binding to a compiled library just needs to cover the public API and ultimately I should pick up improvements to the core code transparently. If you look at what I've done you'll hopefully see a startling similarity with the SWIG bindings particularly the Python one. Hi Fraser, For the first version of our Node.js client, we ended up writing our light C++ module to access the bits of proton-c that we needed and bridge to Javascript. At the time I wasn't aware of your javascript branch, else we would have looked at using that first. However, I did recently also notice that SWIG-3.0.1 has now added a Javascript module for generating Node.js and Javascript bindings in the same way as is currently done for Python, Ruby etc. I wonder how that would compare to your emscripten approach? http://www.swig.org/Release/RELEASENOTES Cheers, Dom Hi Dominic, Yeah I noticed the SWIG thing too recently, though can't recall where - ISTR it was done as part of Google Summer of Code or something. I can't say for sure, but my guess is that the approach is a bit different. At a guess (and I've not really looked at it yet much less played) the SWIG bindings are about being able to integrate/bind with native C/C++ to JavaScript - pretty much analogous to how similar things work with say Python/Perl etc. I suspect that the result is that the JavaScript will only be functional from a node.js environment and not a browser. With the emscripten based approach I'm essentially cross-compiling (or transpiling or whatever you might want to call it) to pure JavaScript, in practice to a subset of JavaScript called asm.js that is optimised for ahead of time compilation in the execution engine (recent versions of Firefox and I think V8 have optimisations for asm.js). There are relative pros and cons to each. I think using SWIG will be closer to the approach that you've already taken - though it's not free and it'll need a wrapper somewhat similar to what I've done in order to make it friendly JavaScript. The advantages are 1 - it'll *probably* perform better because it's a thin wrapper to native code, though by how much I couldn't say yet, with the most recent JavaScript engines the margin likely erodes but I'd suspect it'd perform better whatever. 2 - you are wrapping the C library and you'll be using TCP sockets (The emscripten version is pure JavaScript and uses WebSockets by default, though on my TODO list is to look at configurably using the node net library to use native TCP sockets). Conversely The emscripten based approach is pure JavaScript so runs happily in a browser or node.js. It supports WebSockets and WebRTC (though I've not tried the latter yet) though not (currently) TCP Sockets (though I've written a simple WS-TCP proxy that works pretty well). I've still got a bit of tinkering and tidying up of the emscripten based JavaScript binding, but I'd quite like to get it moved to proton trunk before too long. Once it's settled then I'll move on to my TODO list. FWIW I'm not averse to looking at the SWIG binding too, as I say unless my interpretation is wrong there are relative pros and cons to each and I suspect that they are complementary and not competing approaches. As I say I suspect that the SWIG approach would need Binding code similar to what I've done with emscripten in order to be any fun to use and if a complementary SWIG based binding was contemplated I'd really want to be using the same patterns/API as for the emscripten based one. I'd hope that this wouldn't end up being a whole duplicate as that would be a bit tedious, so I'd expect some relatively non-trivial refactoring to try and have as much shared as possible (take a look at the binding.js, none of it's necessarily rocket science but there was a lot of effort in the proton.Data part to try and make things as nicely idiomatically JavaScript as possible). What I discovered was that compiling the C to JavaScript using emscripten was easy and took me a few weekends of hacking, doing all the binding stuff has taken the best part of a year of spare time (OK not solid effort, but you get the picture) Does that answer your question? Are you the same Dominic Evans who's just filled up my in-box with Jira messages? I got home from work and opened my emails and OMG :-D Cheers, and thanks for taking an interest in the JavaScript bindings. Frase
[jira] [Created] (PROTON-662) decoder.c pn_decoder_decode_value has a test that won't correctly execute.
Fraser Adams created PROTON-662: --- Summary: decoder.c pn_decoder_decode_value has a test that won't correctly execute. Key: PROTON-662 URL: https://issues.apache.org/jira/browse/PROTON-662 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Fraser Adams Priority: Minor In decoder.c pn_decoder_decode_value there is a block of code: pn_type_t type = pn_code2type(acode); if (type 0) return type; The test will not execute correctly because pn_type_t is an unsigned enumeration. The reason for the test seems to be to trap the case where pn_code2type does: return (pn_type_t) PN_ARG_ERR; rather than returning the type. Compiling with Clang rather than gcc flags this warning (which prevents using warnings as errors with Clang): warning: comparison of unsigned enum expression 0 is always false [-Wtautological-compare] if (type 0) return type; ^ ~ Trivial fix is to use correct casting: if ((int)type 0) return (int)type; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-662) decoder.c pn_decoder_decode_value has a test that won't correctly execute.
[ https://issues.apache.org/jira/browse/PROTON-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fraser Adams resolved PROTON-662. - Resolution: Fixed Added the correct casting. Now compiles cleanly on both gcc and Clang. decoder.c pn_decoder_decode_value has a test that won't correctly execute. -- Key: PROTON-662 URL: https://issues.apache.org/jira/browse/PROTON-662 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Fraser Adams Priority: Minor In decoder.c pn_decoder_decode_value there is a block of code: pn_type_t type = pn_code2type(acode); if (type 0) return type; The test will not execute correctly because pn_type_t is an unsigned enumeration. The reason for the test seems to be to trap the case where pn_code2type does: return (pn_type_t) PN_ARG_ERR; rather than returning the type. Compiling with Clang rather than gcc flags this warning (which prevents using warnings as errors with Clang): warning: comparison of unsigned enum expression 0 is always false [-Wtautological-compare] if (type 0) return type; ^ ~ Trivial fix is to use correct casting: if ((int)type 0) return (int)type; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: How to share fixed bugs with you?
On 05/09/14 02:33, Miguel da Rocha Correia Lima wrote: Hi Proton Subscribers, We are using proton qpid for some AMQP software architecture proof of concept. The objective is use proton as our standard AMQP message client to router, gateway and interface with user domain applications and AMQP brokers like qpid, rabitmq, zeromq, etc. While we worked with proton, we found bugs and we fixed they. How can we share they with you? Can we send a patch? Regards, Hi Miguel, The best approach is generally to raise a Jira. In an ideal world explaining the issue, preferably with a reproducer and ideally a patch. TBH plenty of people just raise Jiras giving the symptoms that they've seen, you sound like you've gone a lot further, which is great. For Proton the Jira link is: https://issues.apache.org/jira/browse/PROTON/ For Qpid (The Brokers, JMS, C++ messaging client etc.) the Jira link is: https://issues.apache.org/jira/browse/qpid TBH I personally always suggest opening up a conversation on the main qpid mailing list whether it's more general qpid or more specifically proton as there might be cross pollination of issues (proton is a sub-project of qpid and the qpid AMQP 1.0 support is via proton). HTH, Frase
Re: Javascript bindings: calling subscribe(address) from within a browser
Hi Ernie,
Quick response as I'm just going to bed.
Subscribing is fine from a browser so if say you are connecting to a
broker you can happily do a receive with an address like say localhost
or whatever, but a browser can't really act as a server - you are
clearly trying to get your browser to do a socket listen (using the
address of the form amqp://~0.0.0.0 )
That's just a typical browser security limitation I'm afraid and
something in browser WebSockets don't support.
It's not a defect, just a limitation.
Now technically it's something that just might be possible with WebRTC,
as it happens emscripten supports a WebRTC transport too, but I've not
tried it myself (on my TODO list) but the bottom line is yeah you're
mileage is going to be limited by the art of what's actually possible in
a browser, but as I've mentioned previously the Java Broker supports
WebSocket natively, I've supplied a fairly trivially simple node.js
based WebSocket-TCP Socket proxy and also you can fairly easily stand
up a node based proton intermediary so not having browser peer to
browser peer is probably not a huge issue (though proving AMQP over
WebRTC would be pretty cool and as I say it *should* work I've just not
got round to trying it).
HTH
Frase
On 04/09/14 21:43, Ernest Allen wrote:
I'm getting an error when trying to receive messages from within a browser. The same code
runs fine when run from the command line using node.
The error message is:
Module.MessengerError {name: MessengerError, message: listen: Not
supported, constructor: function, toString: function}
The error happens when calling messenger.subscribe(address);
Is it the case that subscribing is actually not supported from within a
browser, or am I possibly doing something wrong?
I basically just took the code from recv.js and put it in a HTML page.
Here is the code:
!DOCTYPE html !-- HTML5 doctype --
html
head
titleSimple Proton Messenger Send Example/title
meta http-equiv=content-type content=text/html;charset=utf-8 /
script type=text/javascript
src=../../../node_modules/qpid-proton/lib/proton.js/script
script type=text/javascript
var address = amqp://~0.0.0.0;
var message = new proton.Message();
var messenger = new proton.Messenger();
var pumpData = function() {
while (messenger.incoming()) {
var t = messenger.get(message);
console.log(Address: + message.getAddress());
console.log(Subject: + message.getSubject());
// body is the body as a native JavaScript Object, useful for most
real cases.
//console.log(Content: + message.body);
// data is the body as a proton.Data Object, used in this case because
// format() returns exactly the same representation as recv.c
console.log(Content: + message.data.format());
messenger.accept(t);
}
};
console.log(address = ' + address + ');
messenger.setIncomingWindow(1024);
messenger.on('error', function(error) {console.log(error);});
messenger.on('work', pumpData);
messenger.start();
messenger.subscribe(address);
messenger.recv(); // Receive as many messages as messenger can buffer.
/script
/head
body
/body
/html
Regards,
-Ernie
Re: javascript binding in a browser
Hi again Ernie,
I've just committed a few improvements.
In terms of debugging if you specify
cmake .. -DCMAKE_BUILD_TYPE=Debug
or
cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
it will do a build with no JavaScript optimisations and no closure
compiler so any JavaScript errors will be a bit more human readable. The
default build does full Clang optimisations and JavaScript/asm.js
optimisations and minifies/optimises with the closure compiler.
I added code to the status and isBuffered methods that checks for a null
tracker being passed, and if so they now retrieve the outgoing tracker
and use that.
I've also added a soak test and a little send.html
I need to take a look at error handling - if I try to send when there's
no receiver it gets in a state where it won't subsequently send messages
when the receiver is restarted. I might just need to stop and restart
Messenger - TBH I can't claim to really understand the Messenger API.
Hope that you are having fun with this stuff.
Frase
On 30/08/14 16:25, Ernest Allen wrote:
Hi Fraser,
I'm trying to run the proton javascript bindings from within a browser. I'm
getting various errors depending on the way I'm doing it and I was hoping you
could shed some light on the correct approach.
I have node recv.js running in a separate window.
The first way I tried was just including proton.js directly. When I load the
page the console shows the following for the HTML listed below:
pre-main prep time: 6 ms
proton is [object Object]
before put
Uncaught TypeError: Cannot read property 'fa' of null
Uncaught TypeError: Cannot read property 'fa' of null
Here is the HTML:
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
titleAn XHTML 1.0 Strict standard template/title
meta http-equiv=content-type
content=text/html;charset=utf-8 /
script type=text/javascript
src=../../../node_modules/qpid-proton/lib/proton.js/script
script type=text/javascript
//![CDATA[
console.log(proton is + window.proton);
var address = amqp://0.0.0.0;
var subject = BrowserMessage;
var msgtext = Hello From Browser!;
var tracker = null;
var running = true;
var message = new proton.Message();
var messenger = new proton.Messenger();
var pumpData = function() {
var status = messenger.status(tracker);
if (status != proton.Status.PENDING) {
if (running) {
messenger.stop();
running = false;
}
}
if (messenger.isStopped()) {
message.free();
messenger.free();
}
};
messenger.on('error', function(error) {console.log(this is the error +
error);});
messenger.on('work', pumpData);
messenger.setOutgoingWindow(1024);
messenger.start();
message.setAddress(address);
message.setSubject(subject);
message.body = msgtext;
console.log(before put);
messenger.put(message);
//]]
/script
/head
body
/body
/html
The output in the window running node recv.js is:
[0x535398]:ERROR[-2] AMQP header mismatch: '' (connection aborted)
CONNECTION ERROR connection aborted (remote)
When I browserify the proton.js into qpid-proton-browser.js and load that file
instead, I get the following when the page loads:
Uncaught TypeError: Cannot read property 'replace' of undefined
proton is undefined
Uncaught ReferenceError: proton is not defined
The Uncaught TypeError is due to a referece to process.argv[1]. If I manually edit the
qpid-proton-browser.js file to define all the process properties that it wants, I still get the
proton is undefined error.
Do you know what I'm doing wrong?
Thanks,
-Ernie
Re: javascript binding in a browser
Hi Again Ernie,
I take it back, it *was* something you've done ;-p
Or rather it was something that you didn't do.
If you look at the last line of the original send.js it says:
tracker = messenger.put(message);
But your last line below says simply:
messenger.put(message);
The error is simply because null is being passed to
var status = messenger.status(tracker);
If you add the tracker = bit it works fine, yay!!
I'd totally agree that the error was worse than useless :-( I'll have a
think about how best to make things more debuggable.
I suspect that issues around the tracker are some of the quirkiest
techie-alert
I had a world of complexity getting the tracker stuff working. As you
know I'm compiling proton-c to JavaScript using emscripten and 64 bit
integers present complexities in JavaScript.
As it happens compiling directly from C code it is all taken care of
transparently, but for the bindings I'm having to map from native
JavaScript, if you look at the code for messenger.status it looks like this:
/**
* Gets the last known remote state of the delivery associated with the
given tracker.
* @method status
* @memberof! proton.Messenger#
* @param {proton.Data.Long} tracker the tracker whose status is to be
retrieved.
* @returns {proton.Status} one of None, PENDING, REJECTED, or ACCEPTED.
*/
_Messenger_['status'] = function(tracker) {
return _pn_messenger_status(this._messenger,
tracker.getLowBitsUnsigned(), tracker.getHighBits());
};
So basically emscripten uses the LLVM le32 front-end (little endian 32
bit generic front end) and for function calls taking a 64 bit integer it
actually takes *two* parameters - the LSB then MSB. When compiling C
code you don't need this but the binding is logically integrating at the
linker level.
I *suspect* that pn_messenger_status (hopefully) gives and error if it
gets passed a null tracker, but in the case of the binding the tracker
is actually a proton.Data.Long which is a mechanism to allow accurate
representation of 64 bit integers in JavaScript - and of course the
problem is that tracker.getLowBitsUnsigned() is trying to dereference a
null variable, which makes the JS interpreter very sad.
I mentioned in a previous mail that successfully compiling the C code
into JavaScript was the first thing I did, as it happens it has taken me
an age of weekends doing the *binding* stuff because of quirky issues
like this. It's not especially complicated so much as a bit fiddly and
tedious (I did say that JavaScript programmers probably wouldn't want to
use a C API :-).
I personally think that the best bit of the JavaScript binding is being
able to use native JavaScript Objects/Arrays/etc. if you look at the QMF
example it's so much easier than what you have to do in C/C++/Java
(though to be fair python is as nice as JavaScript).
Another couple of things to be aware of are Binaries and explicit types.
I'm planning on writing some docs for this but do
make docs
which should generate documentation for the bindings using jsdoc.
Oh and the spout.js example - which is totally broken and doesn't do
spout yet :-) currently has a bunch of useful stuff commented out (needs
to go in docs really, just haven't got round to it)
so as you probably know JavaScript doesn't have explicit numeric types
it just has number, which is a double. If you are sending to/from
JavaScript you don't have to care, but if you want to send a number of a
particular type you have to be more explicit.
I've added a bunch of conversion functions to the Number prototype, so
for example if you do:
message.body = (12147483649).long();
It will send as an AMQP long
message.body = (12147483649).float();
It will send as an AMQP float (i.e not a double).
In actual fact the binding code tries to make some inferences about the
type, so for example if you do:
message.body = 2147483647;
it will send an int, but if you do:
message.body = 12147483649;
it will send a long ('cause it's more than 32 bits)
and if you do:
message.body = 1.1;
it will send a double, cause it realises it's a floating point type,
however one gotcha is this:
message.body = 1.0;
This will *actually* end up getting sent as an AMQP int, the reason for
this is that JavaScript *transparently* converts floats ending in .0
to integers internally and there's nothing you can do about it :-( so if
your consumer expects particular types you need to be aware of this (you
don't need to do anything fancy when receiving numbers though, just when
sending).
Binary is a little bit interesting too. I support native JavaScript
Binary data using TypedArrays, but I've tried to do it efficiently. The
way emscripten works is that it actually uses a big TypedArray as a
virtual heap, so when you do malloc in C is uses space there, just
twiddling indexes. For Binary what I do is to allocate data on the
emscripten heap so you don't have to copy to and from a separate
ArrayBuffer,
Re: javascript binding in a browser
Hi again Ernie,
There's no real reason why it shouldn't work in a browser except that I
haven't tried it in a while, it tends to be easier to try things out
using node.js and doing some more browser tests was on my TODO list :-)
The error Uncaught TypeError: Cannot read property 'fa' of null is
less than helpful :-) that's 'cause it has been minified with closure.
I doubt that you are doing anything especially wrong it'll just be
something stupid I've done.
If you look in the CMake and set closure 0 in this bit:
LINK_FLAGS -s \EXPORT_NAME='proton'\ -s
\WEBSOCKET_SUBPROTOCOL='AMQPWSB10'\ -O2 --closure 1 --memory-init-file 0
and recompile you'll get a more useful error but TBH if you can bear
with me I'll try to take a look as it tomorrow, I can't do much this
evening 'cause I've been putting up a fence and I'm knackered :-)
I'll give you a ping when I've sorted it .
Frase
On 30/08/14 16:25, Ernest Allen wrote:
Hi Fraser,
I'm trying to run the proton javascript bindings from within a browser. I'm
getting various errors depending on the way I'm doing it and I was hoping you
could shed some light on the correct approach.
I have node recv.js running in a separate window.
The first way I tried was just including proton.js directly. When I load the
page the console shows the following for the HTML listed below:
pre-main prep time: 6 ms
proton is [object Object]
before put
Uncaught TypeError: Cannot read property 'fa' of null
Uncaught TypeError: Cannot read property 'fa' of null
Here is the HTML:
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
titleAn XHTML 1.0 Strict standard template/title
meta http-equiv=content-type
content=text/html;charset=utf-8 /
script type=text/javascript
src=../../../node_modules/qpid-proton/lib/proton.js/script
script type=text/javascript
//![CDATA[
console.log(proton is + window.proton);
var address = amqp://0.0.0.0;
var subject = BrowserMessage;
var msgtext = Hello From Browser!;
var tracker = null;
var running = true;
var message = new proton.Message();
var messenger = new proton.Messenger();
var pumpData = function() {
var status = messenger.status(tracker);
if (status != proton.Status.PENDING) {
if (running) {
messenger.stop();
running = false;
}
}
if (messenger.isStopped()) {
message.free();
messenger.free();
}
};
messenger.on('error', function(error) {console.log(this is the error +
error);});
messenger.on('work', pumpData);
messenger.setOutgoingWindow(1024);
messenger.start();
message.setAddress(address);
message.setSubject(subject);
message.body = msgtext;
console.log(before put);
messenger.put(message);
//]]
/script
/head
body
/body
/html
The output in the window running node recv.js is:
[0x535398]:ERROR[-2] AMQP header mismatch: '' (connection aborted)
CONNECTION ERROR connection aborted (remote)
When I browserify the proton.js into qpid-proton-browser.js and load that file
instead, I get the following when the page loads:
Uncaught TypeError: Cannot read property 'replace' of undefined
proton is undefined
Uncaught ReferenceError: proton is not defined
The Uncaught TypeError is due to a referece to process.argv[1]. If I manually edit the
qpid-proton-browser.js file to define all the process properties that it wants, I still get the
proton is undefined error.
Do you know what I'm doing wrong?
Thanks,
-Ernie
Re: javascript bindings connecting to a qpid c++ broker
Hey Ernie,
You did read what I put in my previous response about the JavaScript
bindings using a *WebSocket* transport didn't you?
send.js and recv.js won't talk *directly* to the C++ broker, however
I've included a simple WebSocket-TCP Socket proxy.
If you stand up proxy.js that should proxy WS port 5673 to TCP port 5672
(you can change the defaults using command line parameters do node
proxy.js -h to see)
Something like
./proxy.js
Proxying ws - tcp
Forwarding port 5673 to 0.0.0.0:5672
./recv.js amqp://localhost:5673/eaq
./send.js -a amqp://localhost:5673/eaq
JavaScript is a bit funny like that :-) I mentioned on my TODO list that
I want to look at native TCP sockets for node, but the main reason for
doing JavaScript is really to get AMQP working in a browser and for that
WebSockets are pretty much the only reasonable transport - though Chrome
packaged apps allow TCP connections.
The Java Broker has a WebSocket transport so I can talk directly to
that, though that has its own quirks at the moment.
Almost certainly the fact that it's a WebSocket transport is the cause
of what you are seeing.
Frase
On 27/08/14 20:34, Ernest Allen wrote:
I'm getting a connection error when using the javascript bindings example
recv.js to receive a message through a qpid c++ broker.
I have a qpid c++ broker running on a remote host with a queue named eaq. I'm
attempting to start up the javascript example recv.js using the remote address/queue, but
I'm getting a connection error:
[eallen@redhat javascript]$ node recv.js amqp://my.remote.host.com/eaq
that._checkErrors = true
error = 3,111,ECONNREFUSED: Connection refused
{ [MessengerError: ECONNREFUSED: Connection refused]
name: 'MessengerError',
message: 'ECONNREFUSED: Connection refused' }
I've tried variations on the address string (without the amqp://, with the ip
address, with a ~) but to no avail.
Notes:
- The proton c examples recv and send work just fine with my broker running on
the remote host and queue. I also tried the python and ruby bindings and they
worked.
- Also, the javascript bindings programs recv.js and send.js work fine together
when going through amqp://0.0.0.0
- When I start recv.js (using the default amqp://0.0.0.0), and send a message using either the c
send example or one of the other language bindings send example programs, I
get an error:
[eallen@redhat py]$ ./send.py Hello
[0xb1d650]:ERROR[-2] SASL header mismatch: ''
CONNECTION ERROR connection aborted (remote)
- I'm also getting the same connection refused error when running the
qpid-config.js example against a broker.
Could this be a problem with my build or environment? Or is this a bug?
Thanks,
-Ernie
Re: proton javascript binding problem/question
Hi Ernie
. In that repository the
fadams-javascript-binding/proton-c/bindings/javascript/qpid-proton does NOT contain a
lib directory. It only contains the files: LICENSE package.json README.md
Yeah that's likely to be the root of your problem, without that lib
directory being in place the copy command will indeed copy proton.js to
a file called lib
My guess is that since lib is an empty directory, it got lost when our
internal repository was created.
:-)
Unfortunately, just changing the CMakeFiles.txt to
${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib/
doesn't work. I get an error since the directory doesn't exist.
Shame it doesn't work, though I guess not surprising. I'm torn between
having the trailing slash or not, though you say that with it you get an
error. Perhaps getting an error is preferable? In your case you had a
silent issue originally, would an error have helped you track things
down more quickly?
When I create the lib dir before the build, everything works as expected.
The real solution is to create the empty lib dir in the Red Hat repository.
I'll look into doing that.
When I pull the source from the public svn link, everything builds just fine.
I'm glad that the public svn link works, yay!!
Thanks for looking into this.
-Ernie Allen
No probs, it's been my personal little baby for a while now, so it's a
good thing that others are starting to take a peek. I think that quality
wise it's pretty decent and pretty well commented and I think that the
functional behaviour is largely all in place, but I haven't really
looked at optimisation/profiling yet.
What do you think of the approach that I've taken? My rationale for
compiling proton-c to JavaScript and using a thin (ish) binding layer
rather than doing a ground-up native JavaScript rewrite was primarily
about support. I figured that there was a lot of effort being put into
maintaining proton-c and that was what might be considered the
canonical or reference implementation, so tracking improvements would
end up being a pain with a separate code-base, whereas the binding to a
compiled library just needs to cover the public API and ultimately I
should pick up improvements to the core code transparently. If you
look at what I've done you'll hopefully see a startling similarity with
the SWIG bindings particularly the Python one. I spent some effort
contributing to emscripten too, putting things in place so that proton-c
compiles cleanly (if you look in
fadams-javascript-binding/bld/proton-c/bindings/javascript/examples you
will see recv-async.js and send-async.js, which are actually the results
of directly compiling recv-async.c and send-async.c. Those were the
first things I got working before I started on the binding stuff - I
figured that JavaScript programmers probably wouldn't enjoy using a C
API ;-)
I did a bit of work on the qpid-config port yesterday and it now does
everything the python one does (well except the xml binding support at
the moment as that loads a file). I'm currently trying to get it to work
with the Java Broker (see my Java Broker AMQP 1.0 support - is it by
default? post to the users list).
Cheers,
Frase
Re: proton javascript binding problem/question
Hi Ernie,
Firstly bear in mind that it's still a bit of a work in progress :-)
though it's getting pretty close to something I'd want to put onto the
main branch, mostly just tidying stuff up now and adding a few more
tests and examples.
That said it was working fine for me when I made the last commit a
couple of weeks ago (r1583389 I think)
I've just done a make from scratch
cd fadams-javascript-binding
mkdir bld
cd bld
cmake ..
make
in my fadams-javascript-binding directory I have a node_modules and in
that a qpid-proton directory.
However in my qpid-proton directory I have
a *directory* named lib and three files named LICENCE, package.json and
README.md
in the lib directory I have a file named proton.js
which is I think exactly what I'd expect to see.
I have no idea why you are seeing a *file* named lib in qpid-proton :-(
I'm using Linux, I don't suppose that you are using some other OS by any
chance? At a guess it's something different between how CMake works
between Linux and Windows, but that's just a guess and if you are using
Linux then it's really weird.
What the make ends up doing is copying the qpid-proton directory and
contents from fadams-javascript-binding/proton-c/bindings/javascript to
the node_modules under fadams-javascript-binding then copying the
proton.js built by the maike into the relevant subdirectory. The
relevant bit from the CMakeLists.txt under
fadams-javascript-binding/proton-c/bindings/javascript is:
# This command packages up the compiled proton.js into a node.js package
called
# qpid-proton and copies it to the proton/node_modules directory. This
allows
# the node.js test and example programs to do proton =
require(qpid-proton);
add_custom_command(
TARGET proton.js
COMMAND ${CMAKE_COMMAND}
-E copy_directory
${CMAKE_CURRENT_SOURCE_DIR}/qpid-proton
${PROJECT_SOURCE_DIR}/node_modules/qpid-proton
COMMAND ${CMAKE_COMMAND}
-E copy
${CMAKE_CURRENT_BINARY_DIR}/proton.js
${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib
COMMENT Building qpid-proton package for node.js
)
I'm no sort of CMake expert I'm afraid I mostly wing it with help from
Mr Google, but as I say above that *should* copy the directory
qpid-proton and its contents from
fadams-javascript-binding/proton-c/bindings/javascript to
fadams-javascript-binding then copy proton.js to
fadams-javascript-binding/node_modules/qpid-proton/lib
Out of curiosity what do you see in
fadams-javascript-binding/proton-c/bindings/javascript/qpid-proton (i.e.
the directory that is being copied to nod_modules) is the lib you are
seeing there a file or a directory?
I'm seeing a directory there too and when I look in subversion at
http://svn.apache.org/repos/asf/qpid/proton/branches/fadams-javascript-binding/proton-c/bindings/javascript/qpid-proton/
I'm seeing a directory called lib too, if you are seeing a file there
then I wonder if it's something weird with the git-svn bridge, but I'm
clutching at straws.
Hmmm re-reading your mail you say When I renamed the lib file to
proton.js, created a lib directory and moved the file under it, all was
well. that's suggesting that proton.js got copied to a file called lib
rather than into the directory called lib, so that second CMake COMMAND:
COMMAND ${CMAKE_COMMAND}
-E copy
${CMAKE_CURRENT_BINARY_DIR}/proton.js
${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib
certainly copies proton.js into node_modules/qpid-proton/lib for me on
my Linux box, but that is the most likely place for things behaving
differently between us...
BTW:
1. You shouldn't need to do a make install, just doing make should copy
this stuff I wanted to make sure a top level node_modules was in place
so that the tests and demos work without too much fuss (clearly I was
delusional :-D)
2. The spout.js and drain.js are currently *very* hacky (they just print
spout not implemented yet and exit ;-) the send.js and recv.js and
client.js and server.js should work pretty much as per the normal proton
examples of the same name and qpid-config.js is pretty much complete
(just the *generic* list mechanism to list AMQP 1.0 QMF objects still to
do).
3. One thing to bear in mind is that this stuff uses a *websocket*
transport, hopefully that's fairly obvious as it's JavaScript, but
perhaps not. I've tried it against the Java Broker's websocket transport
(though not for a couple of months and I've not tried qpid-config.js
with the QMF plugin yet either). If you want to talk to the C++ broker
I've included a simple node.js based WebSocket-TCP proxy (proxy.js). On
my TODO list is to put some more work into the emscripten network
library so that it's possible to configurably choose websockets or TCP
sockets (using the standard node net library)
Hopefully this gives you a few pointers, do let me know how you get on,
though I'm not
[jira] [Commented] (PROTON-436) pn_data_dump is broken for complex types
[ https://issues.apache.org/jira/browse/PROTON-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14004965#comment-14004965 ] Fraser Adams commented on PROTON-436: - Aha - glad I spotted this Jiira, so I'm not going mad then :-) I was trying this out last weekend and wondering was it me or was this how it was supposed to work. pn_data_dump is broken for complex types Key: PROTON-436 URL: https://issues.apache.org/jira/browse/PROTON-436 Project: Qpid Proton Issue Type: Bug Reporter: Bozo Dragojevic Assignee: Rafael H. Schloming Fix For: 0.8 Attachments: 0001-PROTON-436-pni_inspect_atom-can-do-better-than-asser.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Limited message length
On 15/05/14 13:28, Tomáš Šoltys wrote:
Hi all
I have slightly modified an example send.c file to send message
containing 1024 bytes.
Above will result in zero sized message on the receiver side.
Is this an intention or a bug?
Regards,
Tomáš Šoltys
I doubt there's a *deliberate* limit ;-) , my money is that the issue
you're observing is actually on the receiver side. I've just tried
sending an 11K string using the JavaScript binding I'm working on and
that transfered OK.
Assuming that you are using recv.c in examples the bit of code that will
interest you is:
char buffer[1024];
size_t buffsize = sizeof(buffer);
pn_data_t *body = pn_message_body(message);
pn_data_format(body, buffer, buffsize);
format takes the encoded data and displays it in a human readable
format, you pass in a buffer and you get the actual number of bytes back
in the reference parameter - in this case buffsize.
As you can see in recv.c the buffer is a *fixed* 1024 byte buffer.
A more robust implementation would use a dynamically allocated buffer
and check the return value of pn_data_format for PN_OVERFLOW and resize
the buffer.
FWIW here's the implementation of format I've used in the JavaScript
binding - it's somewhat relevant as it the binding actually
cross-compiles proton-c to JavaScript so I need to handle the C style
memory allocations in order to create something idiomatically JavaScript.
/**
* Format the encoded AMQP Data into a string representation and return it.
* @method format
* @memberof! proton.Data#
* @returns {string} a formatted string representation of the encoded Data.
*/
_Data_['format'] = function() {
var size = 1024; // Pass by reference variable - need to use setValue to
initialise it.
while (true) {
setValue(size, size, 'i32'); // Set pass by reference variable.
var bytes = _malloc(size); // Allocate storage from emscripten heap.
var err = _pn_data_format(this._data, bytes, size);
var size = getValue(size, 'i32'); // Dereference the real size value;
if (err === Module['Error']['OVERFLOW']) {
_free(bytes);
size *= 2;
} else {
var string = Pointer_stringify(bytes);
_free(bytes);
this._check(err)
return string;
}
}
}
So as you see I'm checking for OVERFLOW and if I see it I free the
original buffer and try again with a buffer of twice the size. The
Python and Ruby bindings do pretty much the same.
As it happens as I was typing this I actually tried messing a bit more,
when I sent a string of length 22277 it seems to be received OK but my
producer doesn't seem to be terminating correctly, when I double it
again to 44554 I don't seem to be receiving. That's quite possibly a bug
in my binding - this is the first time that I've tried something so
large however I have seen the odd
[0x550ef8]:ERROR amqp:connection:framing-error connection aborted
[0x550ef8]:ERROR[-2] connection aborted
and the underlying implementation is proton-c so it is possible that
there's an issue there, I don't know how far the core proton-c testing
has gone with respect to large messages, somebody like Rafael Schloming
would hopefully know.
HTH,
Frase
Re: map values in message body
Hi Ernie,
Messenger per se certainly supports this, the python binding introspects
the types accurately and I'm currently writing unit tests for my
JavaScript port to prove test the JavaScript introspection behaves
correctly too, so if you are seeing an issue it'll be with the Perl
binding and not with the underlying Messenger.
Unfortunately I don't know Perl especially well so I can't help much
other than to suggest that you take a look in the files
proton/proton-c/bindings/perl/lib/qpid/proton/Message.pm
proton/proton-c/bindings/perl/lib/qpid/proton/Data.pm
The most likely place you want to look is the method preencode() in
Message.pm, when you call $messenger-put() it'll call
$message-preencode();
Inside preencode() it's calling
$body_type-put($body, $my_body) if($my_body $body_type);
which (I think form the following code in Constants.pm
MAP = qpid::proton::Mapping-new(
map,
$cproton_perl::PN_MAP,
put_map_helper,
get_map_helper),
)
results in put_map_helper in Data.pm getting called
- aha!! having just shown my working I see the following:
sub put_map_helper {
my ($self) = @_;
my ($hash) = $_[1];
$self-put_map;
$self-enter;
foreach(keys $hash) {
$self-put_string($_);
$self-put_string($hash-{$_});
}
$self-exit;
}
I guess that the
$self-put_string($_);
$self-put_string($hash-{$_});
are the culprits, so it looks like the Perl binding is indeed putting
string values for the AMQP Map values.
So I'm afraid my long answer to you short question appears to be that
Messenger per se does not have the limitation you observe, but it looks
like the Perl binding does (if my interpretation of the code is correct) :-(
Frase
On 15/05/14 18:04, Ernest Allen wrote:
Does proton messenger support sending complex maps as the message body? That
is, maps whose values are other maps or lists and not just strings?
When I send a message and the body is encoded as qpid::proton::MAP, the map
values appear to have been converted to strings.
For example (in perl)
In the sender
$msg-set_body({foo = 2, bar = [3]}, qpid::proton::MAP);
In the receiver when I dump the body, I'm getting
$VAR1 = \{
'bar' = 'ARRAY(0xa2aad0)',
'foo' = '2'
};
It appears that the array has been converted to the string 'ARRAY(0x...)'. And
the 2 is now a string '2'.
I don't think this is just the way the receiver is dumping the message body as
I'm not able to convert the results to the expected type or variable.
When I send a perl HASH instead of an array as one of the values, it is coming
through as the string'HASH(0x)'.
-Ernie
[jira] [Created] (PROTON-570) Missing Ruby gem dependencies result in a fatal error of Proton build.
Fraser Adams created PROTON-570: --- Summary: Missing Ruby gem dependencies result in a fatal error of Proton build. Key: PROTON-570 URL: https://issues.apache.org/jira/browse/PROTON-570 Project: Qpid Proton Issue Type: Bug Reporter: Fraser Adams Priority: Blocker I did an update to r1589121 and I'm getting a fatal build error when I do cmake .. in a clean build directory CMake Error at proton-c/bindings/ruby/CMakeLists.txt:21 (message): Ruby bindings cannot be tested while missing dependencies In my case I had -- Missing Ruby gem dependency: rspec -- Missing Ruby gem dependency: simplecov and installing those gems sorted the problem out, but I don't believe that missing dependencies for one of the language bindings should fatally stop the entire build. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-569) Initialise pipe file descriptors to -1 in messenger prior to calling pn_pipe
Fraser Adams created PROTON-569: --- Summary: Initialise pipe file descriptors to -1 in messenger prior to calling pn_pipe Key: PROTON-569 URL: https://issues.apache.org/jira/browse/PROTON-569 Project: Qpid Proton Issue Type: Bug Reporter: Fraser Adams Priority: Minor In messenger the pipe file descriptors are not initialised prior to the call to pn_pipe. In most cases this isn't an issue as the call to pipe should do something, however there is no check made for pn_pipe failing and indeed the control pipe/interrupt stuff is essentially not an essential part of messenger so that is reasonable. The issue I've seen though is for the JavaScript bindings I'm working on, in emscripten the pipe call essentially does nothing and just returns -1, the problem however is that the uninitialised pipe file descriptors are zero, in other words m-ctrl[0] = 0, which is the filedescriptor for stdin!!! I kept on getting PN_INTR errors until I worked out what was going on. See also https://github.com/kripken/emscripten/issues/2313 Simply doing m-ctrl[0] = -1; m-ctrl[1] = -1; before pn_pipe(m-io, m-ctrl); Makes things behave as expected. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (PROTON-569) Initialise pipe file descriptors to -1 in messenger prior to calling pn_pipe
[ https://issues.apache.org/jira/browse/PROTON-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fraser Adams resolved PROTON-569. - Resolution: Fixed Initialise pipe file descriptors to -1 in messenger prior to calling pn_pipe Key: PROTON-569 URL: https://issues.apache.org/jira/browse/PROTON-569 Project: Qpid Proton Issue Type: Bug Reporter: Fraser Adams Priority: Minor In messenger the pipe file descriptors are not initialised prior to the call to pn_pipe. In most cases this isn't an issue as the call to pipe should do something, however there is no check made for pn_pipe failing and indeed the control pipe/interrupt stuff is essentially not an essential part of messenger so that is reasonable. The issue I've seen though is for the JavaScript bindings I'm working on, in emscripten the pipe call essentially does nothing and just returns -1, the problem however is that the uninitialised pipe file descriptors are zero, in other words m-ctrl[0] = 0, which is the filedescriptor for stdin!!! I kept on getting PN_INTR errors until I worked out what was going on. See also https://github.com/kripken/emscripten/issues/2313 Simply doing m-ctrl[0] = -1; m-ctrl[1] = -1; before pn_pipe(m-io, m-ctrl); Makes things behave as expected. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Using the messenger API to connect to a server without sending or subscribing
I'm sure others with more detailed knowledge of the background would be able to give a better answer, but in short I think the thing that you need to bear in mind is that proton Messenger is a *Message* oriented API as opposed to a *Connection* oriented API, so for example compare the approach taken with Messenger with say the qpid::messaging API and JMS which are both Connection oriented APIs (where you specify Connection, Session etc.). Messenger is supposed to abstract the (client) user from needing to care about such things, so you specify the address that you want to send a Message to in the Message and let Messenger take care of the Connection and Session stuff. Of course for receiving messages Messenger does connect to the address given via pn_messenger_subscribe (though I'm not sure myself if it is on this call or the pn_messenger_recv call where the connection actually happens). I guess that both approaches have their own relative advantages and disadvantages and TBH I'm generally more familiar with the Connection oriented APIs myself. I think that you will likely just have to live with it, or if you can't then build your higher level API on top of qpid::messenger (which uses Proton engine under the hood when AMQP 1.0 is enabled) or build directly using the proton *Engine* API vice the Messenger API, though that'll take a bit more effort and energy and you'd likely want to look at the qpid::messaging implementation or the dispatch router code for how to talk engine directly (I've never braved using engine directly myself). Sorry it's probably not the answer you were looking for. Regards, Frase On 22/04/14 07:49, Chris White1 wrote: Hi I'm part of the IBM team developing MQ Light ( https://www.ibmdw.net/messaging/mq-light/) and we are implementing our client API using the AMQP Messenger C API. Our client API has a connect function, which is required to be invoked before sending or receiving messages. The AMQP Messager C API does not seem to have an API function to perform a connect, without sending a message or subscribing to receive messages. Looking at the messenger.c source code I found that function pn_messenger_resolve appears to give the connect behaviour we require. So could the pn_messenger_resolve be added to the API please (maybe with a different name, say: pn_messenger_connect, which seems more intuitive)? I was thinking that the pn_messenger_start function should eventually be doing the connect, but that does not take an address argument, so is probably not appropriate. I would also be interested in others opinions about this, as it may seem to be a strange thing to want to do, i.e. why would you want to connect if you're not going to send or receive messages? A use case for this could be that a server wants to be aware of active clients communicating with it before they are ready to send or receive messages. Also a connect function enables a client to determine if a server is available before exchanging data with it. Thanks Chris -- Chris White MP 211 IBM United Kingdom Limited Hursley Park Winchester , England SO21 2JN Tel: +44 (0)1962 818209 (Ext) or 37248209 (Int) E-mail: chris.wh...@uk.ibm.com -- Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [VOTE]: Release Proton 0.7 RC4 as 0.7 final
[X] Yes, release 0.7 RC4 as 0.7 final [ ] No, 0.7 RC4 as the following issues... Regards, Frase
Re: [jira] [Created] (PROTON-564) Messenger.work doesn't receive messages
I must admit that I thought that recv was always necessary for what you are
doing, am I not correct that the python version of recv has an option with no
parameter (the one that use use in your XXX block) where the documentation says
something like if no Message instance is passed to recv then is just pops the
message of the internal queue and discards it.
Sent from my iPad
On 16 Apr 2014, at 14:45, Justin Ross (JIRA) j...@apache.org wrote:
Justin Ross created PROTON-564:
--
Summary: Messenger.work doesn't receive messages
Key: PROTON-564
URL: https://issues.apache.org/jira/browse/PROTON-564
Project: Qpid Proton
Issue Type: Bug
Affects Versions: 0.6, 0.7
Environment: Fedora 19, Python 2.7.5
Reporter: Justin Ross
Sink:
{noformat}
from proton import Messenger, Message
msgr = Messenger()
msgr.start()
try:
msgr.subscribe(amqp://~0.0.0.0:5)
msg = Message()
while True:
print Tick; incoming={}.format(msgr.incoming)
msgr.work()
# msgr.recv() XXX
for i in range(msgr.incoming):
msgr.get(msg)
print(msg)
finally:
msgr.stop()
{noformat}
Source:
{noformat}
from proton import Messenger, Message
msgr = Messenger()
msgr.start()
try:
msg = Message()
msg.address = amqp://0.0.0.0:5/test
for i in range(10):
print Tick {}.format(i)
msg.body = Message {}.format(i)
msgr.put(msg)
msgr.send()
finally:
msgr.stop()
{noformat}
On 0.6, it blocks on one of the work calls with incoming always 0. On 0.7,
it keeps looping through work calls with incoming always 0. The source sends
nothing.
Note the XXX bit in the sink. If you uncomment that. The sink consumes the
messages.
The python API documentation says the following:
{noformat}
Sends or receives any outstanding messages queued for a Messenger. This will
block for the indicated timeout. This method may also do I/O work other than
sending and receiving messages. For example, closing connections after
messenger.stop() has been called.
{noformat}
Based on that, I expect that I should not need to call recv.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: [jira] [Created] (PROTON-564) Messenger.work doesn't receive messages
Sorry Justin, I was thinking of get in my last mail, though I think when I've
done consumers using messenger I call recv once during initialisation and then
call get to retrieve the actual messages.
I've never found the correct workflow to use especially obvious though and I've
largely made it up as I went along ;-)
Sent from my iPad
On 16 Apr 2014, at 14:45, Justin Ross (JIRA) j...@apache.org wrote:
Justin Ross created PROTON-564:
--
Summary: Messenger.work doesn't receive messages
Key: PROTON-564
URL: https://issues.apache.org/jira/browse/PROTON-564
Project: Qpid Proton
Issue Type: Bug
Affects Versions: 0.6, 0.7
Environment: Fedora 19, Python 2.7.5
Reporter: Justin Ross
Sink:
{noformat}
from proton import Messenger, Message
msgr = Messenger()
msgr.start()
try:
msgr.subscribe(amqp://~0.0.0.0:5)
msg = Message()
while True:
print Tick; incoming={}.format(msgr.incoming)
msgr.work()
# msgr.recv() XXX
for i in range(msgr.incoming):
msgr.get(msg)
print(msg)
finally:
msgr.stop()
{noformat}
Source:
{noformat}
from proton import Messenger, Message
msgr = Messenger()
msgr.start()
try:
msg = Message()
msg.address = amqp://0.0.0.0:5/test
for i in range(10):
print Tick {}.format(i)
msg.body = Message {}.format(i)
msgr.put(msg)
msgr.send()
finally:
msgr.stop()
{noformat}
On 0.6, it blocks on one of the work calls with incoming always 0. On 0.7,
it keeps looping through work calls with incoming always 0. The source sends
nothing.
Note the XXX bit in the sink. If you uncomment that. The sink consumes the
messages.
The python API documentation says the following:
{noformat}
Sends or receives any outstanding messages queued for a Messenger. This will
block for the indicated timeout. This method may also do I/O work other than
sending and receiving messages. For example, closing connections after
messenger.stop() has been called.
{noformat}
Based on that, I expect that I should not need to call recv.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: [jira] [Created] (PROTON-564) Messenger.work doesn't receive messages
Sorry, me again -curse being on an iPad, if you try the msg.recv bit before
your while True loop block I.e. do it once during initialisation, the the work
should (probably) be enough during the loop
Sent from my iPad
On 16 Apr 2014, at 14:45, Justin Ross (JIRA) j...@apache.org wrote:
Justin Ross created PROTON-564:
--
Summary: Messenger.work doesn't receive messages
Key: PROTON-564
URL: https://issues.apache.org/jira/browse/PROTON-564
Project: Qpid Proton
Issue Type: Bug
Affects Versions: 0.6, 0.7
Environment: Fedora 19, Python 2.7.5
Reporter: Justin Ross
Sink:
{noformat}
from proton import Messenger, Message
msgr = Messenger()
msgr.start()
try:
msgr.subscribe(amqp://~0.0.0.0:5)
msg = Message()
while True:
print Tick; incoming={}.format(msgr.incoming)
msgr.work()
# msgr.recv() XXX
Caused by: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
for i in range(msgr.incoming):
msgr.get(msg)
print(msg)
finally:
msgr.stop()
{noformat}
Source:
{noformat}
from proton import Messenger, Message
msgr = Messenger()
msgr.start()
try:
msg = Message()
msg.address = amqp://0.0.0.0:5/test
for i in range(10):
print Tick {}.format(i)
msg.body = Message {}.format(i)
msgr.put(msg)
msgr.send()
finally:
msgr.stop()
{noformat}
On 0.6, it blocks on one of the work calls with incoming always 0. On 0.7,
it keeps looping through work calls with incoming always 0. The source sends
nothing.
Note the XXX bit in the sink. If you uncomment that. The sink consumes the
messages.
The python API documentation says the following:
{noformat}
Sends or receives any outstanding messages queued for a Messenger. This will
block for the indicated timeout. This method may also do I/O work other than
sending and receiving messages. For example, closing connections after
messenger.stop() has been called.
{noformat}
Based on that, I expect that I should not need to call recv.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: Quotes in the message body
On 28/03/14 15:20, serega wrote: Thanks for the explanation. Yes, I used recv client. I had to also call pn_data_next(body) to make it work, so it looks like so -- pn_data_t *body = pn_message_body(message); pn_data_next(body); pn_bytes_t bytes = pn_data_get_string(body); -- Ahh sorry I missed the pn_data_next stuff. TBH I'm as much of a novice to this API as you :-/ Funnily enough I'm working my way through it by looking at the python binding in proton/proton-c/bindings/python/proton.py I know it might sound a bit obtuse, but python has a fairly natural OO API and uses introspection, so if you are looking for how to encode and decode things looking at the python stuff shows most of what you need, unfortunately I missed a cheeky post decode call when I first replied .. def _post_decode(self): inst = Data(pn_message_instructions(self._msg)) ann = Data(pn_message_annotations(self._msg)) props = Data(pn_message_properties(self._msg)) body = Data(pn_message_body(self._msg)) if inst.next(): self.instructions = inst.get_object() else: self.instructions = None if ann.next(): self.annotations = ann.get_object() else: self.annotations = None if props.next(): self.properties = props.get_object() else: self.properties = None if body.next(): self.body = body.get_object() else: self.body = None I can see now that there's a call to pn_data_next (wrapped by the body.next() call). By the way judging from this, for safety it looks like you should also be checking the return value of pn_data_next and only calling your pn_data_get_string if the return value is true. The Qpid Proton needs more documentation and/or example code. The messenger.h is very well documented, but I couldn't find any documentation on how to read and write data (properties, body) from and to a message. I agree, I actually posted on a related topic on the qpid users mailing list - the good news is that improved API documentation should be happening fairly soon. Regards, Frase
Re: Quotes in the message body
Hello,
If you are using the recv client (which you look like you are using)
then I *think* that what you are seeing is an artefact of that using
pn_data_format, which generates a *formatted* response. I think that's
because recv is intended to be a fairly general test client - when I
sent a UUID to it the other day it displayed something like
UUID(my-uuid), so the quotes are an artefact of the rendering rather
than anything transmitted over the wire.
What you'd need to do is to have a client that did pn_data_get_string
rather than pn_data_format. One thing to bear in mind is that
pn_data_get_string returns a pn_bytes_t structure and not a char* string
it looks something like:
typedef struct {
size_t size;
char *start;
} pn_bytes_t;
The call you'd need to make would I think look like:
pn_bytes_t bytes = pn_data_get_string(body);
But you'd need to make sure that you then created your own char* style
null terminated string using the start and size stuff from bytes (likely
via malloc and memcpy).
So in short I think that it relates to the recv client and if you want
the unformatted string then you'd need to modify that to retrieve the
string directly.
I'm still finding my own feet with the messenger API if there's a better
approach then hopefully someone more authoritative will chip in.
HTH,
Frase
On 26/03/14 20:56, serega wrote:
I am using Qpid Proton Messenger with SwiftMQ JMS/AMQP broker. On the
receiving side the messenger surrounds message body with quotes.
smeldris@labitpf2:~/qpid-proton-0.6/build/proton-c/examples/messenger/c./send
-a amqp://10.250.0.127:5672/testqueue
Message_without_quotessmeldris@labitpf2:~/qpid-proton-0.6/build/proton-c/examples/messenger/csmeldris@labitpf2:~/qpid-proton-0.6/build/proton-c/examples/messenger/c./recv
amqp://10.250.0.127:5672/testqueueAddress:
amqp://10.250.0.127:5672/testqueueSubject: (no subject)Content:
Message_without_quotes
Notice the '' character on both sides of the body. The SwiftMQ is JMS
broker which gives me more options to test. Receiving this message using JMS
API yields a message body without quotes, so it clearly happens on the
quid-proton receiving side. I am stripping out the quotes, but I prefer to
receive the original message without quotes. - Sergey
--
View this message in context:
http://qpid.2158936.n2.nabble.com/Quotes-in-the-message-body-tp7606053.html
Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
[jira] [Created] (PROTON-535) make docs results in several warnings and an error
Fraser Adams created PROTON-535: --- Summary: make docs results in several warnings and an error Key: PROTON-535 URL: https://issues.apache.org/jira/browse/PROTON-535 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Fraser Adams Priority: Minor When I tried make docs it mostly looks like it works but I saw several warnings: warning: ignoring unsupported tag `INLINE_SIMPLE_STRUCTS =' at line 313, file user.doxygen warning: ignoring unsupported tag `CITE_BIB_FILES =' at line 583, file user.doxygen warning: ignoring unsupported tag `MATHJAX_EXTENSIONS =' at line 1166, file user.doxygen warning: ignoring unsupported tag `LATEX_BIB_STYLE=' at line 1285, file user.doxygen warning: ignoring unsupported tag `INTERACTIVE_SVG=' at line 1699, file user.doxygen and Scanning dependencies of target docs-py +-- | In /home/fadams/qpid/qpid-trunk/proton/proton-c/bindings/python/ | proton.py: | Import failed (but source code parsing was successful). | Error: NameError: name 'PN_CONNECTION_STATE' is not defined (line |3292) | -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application
Hi Cliff,
FYI I've just this minute merged all the latest updates to proton-c onto
the branch I'm using for the JavaScript bindings and have rebuilt
everything, the changes that you've done for this Jira work beautifully
for me too!!! Many thanks, you're a star.
Cheers,
Frase
On 28/02/14 08:48, Cliff Jansen wrote:
Sorry for the delay.
I played a bit with emcripten to see if there was some
misunderstanding going on, but it seems pretty clear that clang knows
exactly what is being passed in via the va_arg call and just plain
refuses to deal with a struct (at least for some architectures).
Consequently the original patch which restricts va_arg processing to
simple types seems to me the most robust and portable solution. I
will proceed with that for 0.7.
Cliff
a bit indicates to me that clang is not somehow confused about
On Thu, Feb 27, 2014 at 9:01 AM, Fraser Adams
fraser.ad...@blueyonder.co.uk wrote:
Hi again Cliff,
Have you made any progress on this?
Cheers,
Frase
On 30/01/14 02:31, Cliff Jansen wrote:
Well thanks for all that. I'll certainly take another look and report
back before committing anything. Giving a compiler family indigestion
is certainly to be avoided.
Cliff
On Tue, Jan 28, 2014 at 11:29 AM, Fraser Adams
fraser.ad...@blueyonder.co.uk wrote:
Hi, me again Cliff.
I've only had time to recheck this against my test case, which is
representative of what I see for real.
Doing:
int pn_data_vfill2(const char *fmt, va_list ap)
{
// Process the PROPERTIES constant - this seems OK
uint64_t prop = va_arg(ap, uint64_t);
printf(prop = %llu\n, prop);
{
pn_bytes_t bytes = va_arg(ap, pn_bytes_t);
printf(pn_data_vfill z, bytes.size = %zu, bytes.start = %s\n,
bytes.size,
bytes.start);
}
// Process the char* returned by pn_string_get()
{
char *start = va_arg(ap, char *);
size_t size = strlen(start);
printf(pn_data_vfill size = %zu\n, size);
printf(pn_data_vfill string = %s\n, start);
}
return 0;
}
E.g. the both passing and retrieving structs approach of your second
approach actually doesn't even compile for me with LLVM le32, I get
error:
cannot compile this aggregate va_arg expression yet
pn_bytes_t bytes = va_arg(ap, pn_bytes_t);
^~
/home/fadams/emscripten/system/include/libc/stdarg.h:15:25: note:
expanded
from
macro 'va_arg'
#define va_arg(v,l) __builtin_va_arg(v,l)
^
1 error generated.
ERRORroot: compiler frontend failed to generate LLVM bitcode, halting
make[2]: *** [CMakeFiles/test_varargs.dir/test_varargs.o] Error 1
make[1]: *** [CMakeFiles/test_varargs.dir/all] Error 2
make: *** [all] Error 2
Though it *does* work if I do EMCC_LLVM_TARGET=i386-pc-linux-gnu make
So in a nutshell:
1) if I fudge the LLVM front end pure struct, put struct retrieve
discrete
and pure discrete values all work correctly.
2) with the standard emscripten le32 LLVM front end (which is what is
recommended)
* pure struct (as above) fails to compile
* put struct, retrieve discrete (as with the original Proton code) gives
the wrong results - that messed with my head :-)
* pure discrete values (as with your pn_string_size(msg-user_id),
pn_string_get(msg-user_id),) patch works correctly.
So I'd *really* like it if you could go down the path of your original
patch
'cause that would fix what you've been seeing and let me compile the
JavaScript stuff without needing the environment tweaked (which is an
accident waiting to happen). I hope that you are agreeable to that?
I think that it would probably be worth putting a comment in the call to
pn_data_fill and within the pn_data_vfill() 'z' case body to document
that
it's safer to pass individual entries to va_arg to avoid upsetting some
compilers - it's not entirely an *obvious* thing really :-D
Cheers,
Frase
On 27/01/14 21:21, Cliff Jansen wrote:
Thanks for the Javascript related info.
Fraser: can you test if the review board patch (with the struct in
and out strategy) works in your case with the unhacked llvm setup?
If that works then I'll go ahead and check it in.
If it fails, please try the first patch. If that works, we will just
have to conclude that compilers have trouble with stucts in this case
and fall back to passing the two basic types. That should be safe to
work in the greatest number of cases.
Many thanks.
On Mon, Jan 27, 2014 at 1:13 PM, Fraser Adams (JIRA) j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883314#comment-13883314
]
Fraser Adams commented on PROTON-488:
-
Oh to be clear
either struct in and out, or separate size_t and char* in and out
what I meant in my previous comment was that the separate size_t and
char* in and out is what LLVM le32
Re: [jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application
Hi again Cliff,
Have you made any progress on this?
Cheers,
Frase
On 30/01/14 02:31, Cliff Jansen wrote:
Well thanks for all that. I'll certainly take another look and report
back before committing anything. Giving a compiler family indigestion
is certainly to be avoided.
Cliff
On Tue, Jan 28, 2014 at 11:29 AM, Fraser Adams
fraser.ad...@blueyonder.co.uk wrote:
Hi, me again Cliff.
I've only had time to recheck this against my test case, which is
representative of what I see for real.
Doing:
int pn_data_vfill2(const char *fmt, va_list ap)
{
// Process the PROPERTIES constant - this seems OK
uint64_t prop = va_arg(ap, uint64_t);
printf(prop = %llu\n, prop);
{
pn_bytes_t bytes = va_arg(ap, pn_bytes_t);
printf(pn_data_vfill z, bytes.size = %zu, bytes.start = %s\n, bytes.size,
bytes.start);
}
// Process the char* returned by pn_string_get()
{
char *start = va_arg(ap, char *);
size_t size = strlen(start);
printf(pn_data_vfill size = %zu\n, size);
printf(pn_data_vfill string = %s\n, start);
}
return 0;
}
E.g. the both passing and retrieving structs approach of your second
approach actually doesn't even compile for me with LLVM le32, I get
error:
cannot compile this aggregate va_arg expression yet
pn_bytes_t bytes = va_arg(ap, pn_bytes_t);
^~
/home/fadams/emscripten/system/include/libc/stdarg.h:15:25: note: expanded
from
macro 'va_arg'
#define va_arg(v,l) __builtin_va_arg(v,l)
^
1 error generated.
ERRORroot: compiler frontend failed to generate LLVM bitcode, halting
make[2]: *** [CMakeFiles/test_varargs.dir/test_varargs.o] Error 1
make[1]: *** [CMakeFiles/test_varargs.dir/all] Error 2
make: *** [all] Error 2
Though it *does* work if I do EMCC_LLVM_TARGET=i386-pc-linux-gnu make
So in a nutshell:
1) if I fudge the LLVM front end pure struct, put struct retrieve discrete
and pure discrete values all work correctly.
2) with the standard emscripten le32 LLVM front end (which is what is
recommended)
* pure struct (as above) fails to compile
* put struct, retrieve discrete (as with the original Proton code) gives
the wrong results - that messed with my head :-)
* pure discrete values (as with your pn_string_size(msg-user_id),
pn_string_get(msg-user_id),) patch works correctly.
So I'd *really* like it if you could go down the path of your original patch
'cause that would fix what you've been seeing and let me compile the
JavaScript stuff without needing the environment tweaked (which is an
accident waiting to happen). I hope that you are agreeable to that?
I think that it would probably be worth putting a comment in the call to
pn_data_fill and within the pn_data_vfill() 'z' case body to document that
it's safer to pass individual entries to va_arg to avoid upsetting some
compilers - it's not entirely an *obvious* thing really :-D
Cheers,
Frase
On 27/01/14 21:21, Cliff Jansen wrote:
Thanks for the Javascript related info.
Fraser: can you test if the review board patch (with the struct in
and out strategy) works in your case with the unhacked llvm setup?
If that works then I'll go ahead and check it in.
If it fails, please try the first patch. If that works, we will just
have to conclude that compilers have trouble with stucts in this case
and fall back to passing the two basic types. That should be safe to
work in the greatest number of cases.
Many thanks.
On Mon, Jan 27, 2014 at 1:13 PM, Fraser Adams (JIRA) j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883314#comment-13883314
]
Fraser Adams commented on PROTON-488:
-
Oh to be clear
either struct in and out, or separate size_t and char* in and out
what I meant in my previous comment was that the separate size_t and
char* in and out is what LLVM le32 is happiest with, the structs seem to
confuse it, I hadn't realised that you'd changed your original patch to now
do all 'z' encodings to be passed as a single pn_bytes_t struct and
retrieved as a single pn_bytes_t struct - although this arguably looks
neater I'd definitely prefer your first approach.
Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv
Application
-
Key: PROTON-488
URL: https://issues.apache.org/jira/browse/PROTON-488
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.6
Environment: Windows 7 64-bit VS 2010
Reporter: Frank Quinn
Assignee: Cliff Jansen
Priority: Critical
Attachments: PROTON-488-0.patch,
qpid-proton-win64-send-crash.png
Steps to recreate:
1. Grab
Re: error when building proton
Starting from scratch is definitely the safest bet, but I *thought* that you could just delete the CMakeCache.txt Frase On 05/02/14 18:53, Ted Ross wrote: There's one other thing to be careful of... Once CMake determines that it's not there, it will not reconsider after you've installed the dependency. Make sure you delete your whole build directory and re-configure. -Ted On 02/05/2014 12:02 PM, Roberto Pagliari wrote: Hi Alan, I have uuid-dev installed but it still cannot find it. Is there a flag on the CMakeLists file? I can't see it when running ccmake. Thank you, Roberto On Wed, Feb 5, 2014 at 11:07 AM, Alan Conway acon...@redhat.com wrote: On Tue, 2014-02-04 at 17:50 -0500, Roberto Pagliari wrote: I'm getting this error when using ccmake to build proton (on Ubuntu 12) CMake Error at proton-c/CMakeLists.txt:126 (message): No Uuid API found does anyone know how to fix it? I can't find this flag in ccmake gui and uuid is available on my system. You may need uuid-devel or whatever is the equivalent package on your distribution. E.g. on fedora 20 the libuuid package contains the uuid library, but libuuid-devel contains the .h files that are also needed to build proton.
[jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application
[ https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883314#comment-13883314 ] Fraser Adams commented on PROTON-488: - Oh to be clear either struct in and out, or separate size_t and char* in and out what I meant in my previous comment was that the separate size_t and char* in and out is what LLVM le32 is happiest with, the structs seem to confuse it, I hadn't realised that you'd changed your original patch to now do all 'z' encodings to be passed as a single pn_bytes_t struct and retrieved as a single pn_bytes_t struct - although this arguably looks neater I'd definitely prefer your first approach. Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application - Key: PROTON-488 URL: https://issues.apache.org/jira/browse/PROTON-488 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Environment: Windows 7 64-bit VS 2010 Reporter: Frank Quinn Assignee: Cliff Jansen Priority: Critical Attachments: PROTON-488-0.patch, qpid-proton-win64-send-crash.png Steps to recreate: 1. Grab latest 0.6 tarball 2. Start up Visual Studio x64 Win64 Command Prompt (2010) and run cmake . to generate the visual studio files 3. Open Up the newly created Proton.sln in VS2010, right click on qpid-proton and add the path to python to executable directories 4. In the configuration manager, select qpid-proton and select active configuration to be Debug, then select Add to add x64 support, copying win32 configuration in the process. 5. Select qpid-proton properties and remove the hard coded /machine:X86 extra command lines in Linker - Command Line (MACHINE:X64 should already be in the command line above so no need to add here) 6. Right click on qpid-proton and select build Repeat steps 3-6 for send / recv applications. When you run recv, then run send, you'll get a crash with the (soon to be attached) trace. Cheers, Frank -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application
[ https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883328#comment-13883328 ] Fraser Adams commented on PROTON-488: - For info I managed to pull out the bits that were affecting me as a cut down reproducer in a GitHub gist, you might notice something of a familiarity. https://gist.github.com/fadams/8315263 The pn_string_get_bytes(), was what caused me the pain (I tried retrieving the struct too but the only things that work were pushing up the separate parts of the struct or messing with the LLVM front end) I'd have preferred the former like your original patch but hadn't got round to doing that as I could work around it and I had a few other things to sort out. Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application - Key: PROTON-488 URL: https://issues.apache.org/jira/browse/PROTON-488 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Environment: Windows 7 64-bit VS 2010 Reporter: Frank Quinn Assignee: Cliff Jansen Priority: Critical Attachments: PROTON-488-0.patch, qpid-proton-win64-send-crash.png Steps to recreate: 1. Grab latest 0.6 tarball 2. Start up Visual Studio x64 Win64 Command Prompt (2010) and run cmake . to generate the visual studio files 3. Open Up the newly created Proton.sln in VS2010, right click on qpid-proton and add the path to python to executable directories 4. In the configuration manager, select qpid-proton and select active configuration to be Debug, then select Add to add x64 support, copying win32 configuration in the process. 5. Select qpid-proton properties and remove the hard coded /machine:X86 extra command lines in Linker - Command Line (MACHINE:X64 should already be in the command line above so no need to add here) 6. Right click on qpid-proton and select build Repeat steps 3-6 for send / recv applications. When you run recv, then run send, you'll get a crash with the (soon to be attached) trace. Cheers, Frank -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application
[ https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883472#comment-13883472 ] Fraser Adams commented on PROTON-488: - Hey Cliff, Re can you test if the review board patch (with the struct in and out strategy) works in your case with the unhacked llvm setup? - I could check it again, though it'll be a couple of days before I can get coding time to try it I'm afraid. I did actually try that approach out previously though on the off-chance - and it didn't work, the only two things that worked for me were passing the two basic types or messing with the LLVM front end. I've copied a link to the issue I raised on the emscripten mailing list on this, mainly for interest, but you'll note a painful similarity with what you've experienced :-D https://github.com/kripken/emscripten/issues/1988 Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application - Key: PROTON-488 URL: https://issues.apache.org/jira/browse/PROTON-488 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Environment: Windows 7 64-bit VS 2010 Reporter: Frank Quinn Assignee: Cliff Jansen Priority: Critical Attachments: PROTON-488-0.patch, qpid-proton-win64-send-crash.png Steps to recreate: 1. Grab latest 0.6 tarball 2. Start up Visual Studio x64 Win64 Command Prompt (2010) and run cmake . to generate the visual studio files 3. Open Up the newly created Proton.sln in VS2010, right click on qpid-proton and add the path to python to executable directories 4. In the configuration manager, select qpid-proton and select active configuration to be Debug, then select Add to add x64 support, copying win32 configuration in the process. 5. Select qpid-proton properties and remove the hard coded /machine:X86 extra command lines in Linker - Command Line (MACHINE:X64 should already be in the command line above so no need to add here) 6. Right click on qpid-proton and select build Repeat steps 3-6 for send / recv applications. When you run recv, then run send, you'll get a crash with the (soon to be attached) trace. Cheers, Frank -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: pn_messenger_send return code
Out of curiosity which version of Proton are you using? I *think* that's a fairly recent fix. I was seeing something similar in my asynchronous experiments (I needed to figure out when the message actually reached the receiver so I could hold off terminating my async producer until then) and Rafael put a fix onto Proton trunk - that'd be ~3-4 weeks ago. It might be worth you trying a build off trunk. Regards, Frase On 10/01/14 22:43, serega wrote: Thanks for your reply. I added the tracker, but with the same scenario it returns 0 which is PN_STATUS_UNKNOWN = 0. - Error 0 read: Connection refused [0x100810800:0] ERROR[-2] SASL header mismatch: '' send: Broken pipe CONNECTION ERROR connection aborted Error 0 Status off M1: 0 --- It looks like internally messenger prints error messages, but it doesn't communicate with the client about the error. The unknown status isn't very meaningful. Sergey. -- View this message in context: http://qpid.2158936.n2.nabble.com/pn-messenger-send-return-code-tp7602570p7602587.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
[jira] [Created] (PROTON-465) FindPerlLibs.cmake module in Proton behaves differently to Qpid's Perl detection
Fraser Adams created PROTON-465: --- Summary: FindPerlLibs.cmake module in Proton behaves differently to Qpid's Perl detection Key: PROTON-465 URL: https://issues.apache.org/jira/browse/PROTON-465 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.5 Environment: Ubuntu 11.10 (at least) Reporter: Fraser Adams Priority: Minor With Proton when I do cmake .. it barfs with -- Trying alternative search for Perl -- PerlLibs Not Found Though I can get it to play nicely by doing cmake .. -DPERL_LIBRARY=`locate -n 1 libperl.so` This might not be so unreasonable as I'm using a fairly old version of Ubuntu that needs upgrading, however the Perl detection on Qpid works perfectly well for me (and I'd assume for others too) which suggests that it's possibly more thorough. At the very least it would seem sensible to maintain consistency with the cmake modules across various Qpid components. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-465) FindPerlLibs.cmake module in Proton behaves differently to Qpid's Perl detection
[ https://issues.apache.org/jira/browse/PROTON-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fraser Adams updated PROTON-465: Assignee: Darryl L. Pierce FindPerlLibs.cmake module in Proton behaves differently to Qpid's Perl detection Key: PROTON-465 URL: https://issues.apache.org/jira/browse/PROTON-465 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.5 Environment: Ubuntu 11.10 (at least) Reporter: Fraser Adams Assignee: Darryl L. Pierce Priority: Minor With Proton when I do cmake .. it barfs with -- Trying alternative search for Perl -- PerlLibs Not Found Though I can get it to play nicely by doing cmake .. -DPERL_LIBRARY=`locate -n 1 libperl.so` This might not be so unreasonable as I'm using a fairly old version of Ubuntu that needs upgrading, however the Perl detection on Qpid works perfectly well for me (and I'd assume for others too) which suggests that it's possibly more thorough. At the very least it would seem sensible to maintain consistency with the cmake modules across various Qpid components. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (PROTON-442) Running swig generates Warning(451): Setting a const char * variable may leak memory.
[ https://issues.apache.org/jira/browse/PROTON-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fraser Adams resolved PROTON-442. - Resolution: Fixed Running swig generates Warning(451): Setting a const char * variable may leak memory. --- Key: PROTON-442 URL: https://issues.apache.org/jira/browse/PROTON-442 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Fraser Adams Priority: Minor When building proton after doing cmake .. the make process is quite noisy generating a number of warnings that ought to be corrected. One such warning is: Warning(451): Setting a const char * variable may leak memory. This relates to the const char *bytes; in the pn_delivery_tag_t struct in engine.h The swig documentation in http://www.swig.org/Doc1.3/Warnings.html suggests how to suppress this warning (due to the way the code works I believe that it's safe to suppress this case) by doing: %warnfilter(451) pn_delivery_tag_t; in the various python.i, perl.i etc. I've make the changes locally and this indeed works. I'll put together a review board request. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (PROTON-442) Running swig generates Warning(451): Setting a const char * variable may leak memory.
Fraser Adams created PROTON-442: --- Summary: Running swig generates Warning(451): Setting a const char * variable may leak memory. Key: PROTON-442 URL: https://issues.apache.org/jira/browse/PROTON-442 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Fraser Adams Priority: Minor When building proton after doing cmake .. the make process is quite noisy generating a number of warnings that ought to be corrected. One such warning is: Warning(451): Setting a const char * variable may leak memory. This relates to the const char *bytes; in the pn_delivery_tag_t struct in engine.h The swig documentation in http://www.swig.org/Doc1.3/Warnings.html suggests how to suppress this warning (due to the way the code works I believe that it's safe to suppress this case) by doing: %warnfilter(451) pn_delivery_tag_t; in the various python.i, perl.i etc. I've make the changes locally and this indeed works. I'll put together a review board request. -- This message was sent by Atlassian JIRA (v6.1#6144)
