[jira] [Commented] (PROTON-817) BlockingConnection doesn't pass options down in create_sender or create_receiver
[ https://issues.apache.org/jira/browse/PROTON-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14308913#comment-14308913 ] ASF subversion and git services commented on PROTON-817: Commit 54795323e2524e650cb7b0de371fd9a7692610d4 in qpid-proton's branch refs/heads/master from [~gsim] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=5479532 ] PROTON-817: pass through options when creating blocking links (patch from Ted Ross) BlockingConnection doesn't pass options down in create_sender or create_receiver Key: PROTON-817 URL: https://issues.apache.org/jira/browse/PROTON-817 Project: Qpid Proton Issue Type: Bug Components: python-binding Reporter: Ted Ross Assignee: Gordon Sim Fix For: 0.9 Attachments: PROTON-817.patch The options argument is not passed down from BlockingConnection.create_receiver to Container.create_receiver. The same is true for create_sender. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-817) BlockingConnection doesn't pass options down in create_sender or create_receiver
[ https://issues.apache.org/jira/browse/PROTON-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-817. --- Resolution: Fixed BlockingConnection doesn't pass options down in create_sender or create_receiver Key: PROTON-817 URL: https://issues.apache.org/jira/browse/PROTON-817 Project: Qpid Proton Issue Type: Bug Components: python-binding Reporter: Ted Ross Assignee: Gordon Sim Fix For: 0.9 Attachments: PROTON-817.patch The options argument is not passed down from BlockingConnection.create_receiver to Container.create_receiver. The same is true for create_sender. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-775) ruby: message annotations send from a ruby client are invalid
[ https://issues.apache.org/jira/browse/PROTON-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14309157#comment-14309157 ] ASF subversion and git services commented on PROTON-775: Commit 4e12b3a064bc8f0481da31c59cfe6b9e6e0a0263 in qpid-proton's branch refs/heads/master from [~mcpierce] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=4e12b3a ] PROTON-775: Ensure that annotation keys in Ruby are encoded as symbols. The AMQP protocol requires that the keys for message annotations be encoded as symbols rather than strings. This change ensures that keys are properly encoded before the message is sent. ruby: message annotations send from a ruby client are invalid - Key: PROTON-775 URL: https://issues.apache.org/jira/browse/PROTON-775 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Darryl L. Pierce Attachments: 0001-PROTON-775-Ensure-that-annotation-keys-in-Ruby-are-e.patch Since PROTON-616, proton-j has attempted to enforce the fact that the key's of a message annotations map *must* be of the Symbol type (or actually ulong, but those are reserved so we don't need to worry about that) [1] Unfortunately, from the Ruby client, the mapping of a native map into proton data always sets the key's as strings rather than symbols. In proton-j, you'll currently hit a `java.lang.ClassCastException: java.lang.String incompatible with org.apache.qpid.proton.amqp.Symbol` if you try to look at keys of the MessageAnnotations object of a message sent from the ruby send.rb example (which sets message annotations for the keys 'version' and 'pill'). -- [1] http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-annotations -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [Fwd: [jira] [Commented] (DISPATCH-103) Websocket Listeners]
On Fri, 2015-02-06 at 08:19 -0500, 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, including list now. Extremely useful discussion, thanks! Taking it all on board. New question: For dispatch I only care about the server side. JavaScript is the only websocket client I know of and as per discussion below we would actually need to *exclude* proton client-side websocket support from the JS client, so maybe we don't need it at all. Are there use cases for a websocket client transport? On Fri, Feb 6, 2015 at 6:20 AM, Fraser Adams 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. 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 done some nice work around this sort of thing already with detecting SSL vs plain and detecting SASL vs just core AMQP, so autodetecting the HTTP header and doing the upgrade would be a natural and hopefully
Re: Ruby, Proton Engine and Records
On Fri, Feb 06, 2015 at 08:37:07AM -0500, Rafael Schloming wrote: Is this the approach you referenced in your other email? (Same request here for a pointer to the highlighted key bits of the approach.) No, this was a third approach to the problem, since we can't directly affect the object created by Swig via Data_Wrap_Struct. You can see the specific changes to ruby.i here [1]. http://github.com/mcpierce/Proton/commit/1e66f39535e71dc376d69abde7b5741929d33a3d -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgprYbkagDgS7.pgp Description: PGP signature
Re: Proton-c Websocket Listeners - thread from off list discussion
On Fri, Feb 6, 2015 at 8:54 AM, Fraser Adams fraser.ad...@blueyonder.co.uk wrote: 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. Ah, that's good to know. For some reason I was assuming the overhead was from our own code, but if it's not then hopefully as you say it will just improve with time and we don't need to do much about it. I think this should be fairly straightforward in proton-c. We already have a similar set of scenarios there with SSL and SASL autodetect. When you configure a Transport, you basically construct a stack of protocols. In server mode you can it autodetect whether each layer is present and fall through to the next. In client mode the stack is just what you have specified. So I can see how the autodetect could be extended to handle this when acting as a server, but this last bit was really about what sort of API one might use for a client to establish a connection giving a runtime choice between a TCP or WebSocket transport. As I say for the qpid::messaging API the Connection allows quite a range of options but in Messenger at any rate I think the options are more limited and ISTR there are some restrictions even on SASL options, so as I say it's probably not technically hard I'm just not sure what the best specify the transport API might be for Proton - if you see what I mean? Yeah, I see what you mean. I suspect there will probably be multiple layers here. When constructing the transport directly the API choices are fairly straightforward, but probably overly verbose and flexible for what you would necessarily want as the common end-user case. I can imagine some sort of more convenience/configuration oriented layer on top that would let you just specify all the relevant details in a connect string or something like that. I believe Gordon already has something like this in the reactive API, so that might give you an answer. --Rafael
[jira] [Resolved] (PROTON-775) ruby: message annotations send from a ruby client are invalid
[ https://issues.apache.org/jira/browse/PROTON-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce resolved PROTON-775. - Resolution: Fixed Fix Version/s: 0.9 ruby: message annotations send from a ruby client are invalid - Key: PROTON-775 URL: https://issues.apache.org/jira/browse/PROTON-775 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Darryl L. Pierce Fix For: 0.9 Attachments: 0001-PROTON-775-Ensure-that-annotation-keys-in-Ruby-are-e.patch Since PROTON-616, proton-j has attempted to enforce the fact that the key's of a message annotations map *must* be of the Symbol type (or actually ulong, but those are reserved so we don't need to worry about that) [1] Unfortunately, from the Ruby client, the mapping of a native map into proton data always sets the key's as strings rather than symbols. In proton-j, you'll currently hit a `java.lang.ClassCastException: java.lang.String incompatible with org.apache.qpid.proton.amqp.Symbol` if you try to look at keys of the MessageAnnotations object of a message sent from the ruby send.rb example (which sets message annotations for the keys 'version' and 'pill'). -- [1] http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-annotations -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-775) ruby: message annotations send from a ruby client are invalid
[ https://issues.apache.org/jira/browse/PROTON-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated PROTON-775: Attachment: 0001-PROTON-775-Ensure-that-annotation-keys-in-Ruby-are-e.patch This patch changes how annotations are encoded to ensure that the keys are sent as symbols. ruby: message annotations send from a ruby client are invalid - Key: PROTON-775 URL: https://issues.apache.org/jira/browse/PROTON-775 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Darryl L. Pierce Attachments: 0001-PROTON-775-Ensure-that-annotation-keys-in-Ruby-are-e.patch Since PROTON-616, proton-j has attempted to enforce the fact that the key's of a message annotations map *must* be of the Symbol type (or actually ulong, but those are reserved so we don't need to worry about that) [1] Unfortunately, from the Ruby client, the mapping of a native map into proton data always sets the key's as strings rather than symbols. In proton-j, you'll currently hit a `java.lang.ClassCastException: java.lang.String incompatible with org.apache.qpid.proton.amqp.Symbol` if you try to look at keys of the MessageAnnotations object of a message sent from the ruby send.rb example (which sets message annotations for the keys 'version' and 'pill'). -- [1] http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-annotations -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Non-reactive engine examples?
On Tue, Feb 3, 2015 at 4:26 PM, Darryl L. Pierce dpie...@redhat.com wrote: On Mon, Feb 02, 2015 at 09:12:22AM -0500, Darryl L. Pierce wrote: Are there any example apps for Python that don't use the reactive APIs? If no examples, perhaps a primer of how the logical components of the enger interact to help guide providing an example? The quick primer is that Connections/Sessions/Links/Deliveries pretty much directly model the endpoint state described in the AMQP specification. In order to wire that endpoint state up to a remote peer, you create, configure, and bind a Transport object into the Connection. The Transport has an interface that lets you pump bytes into/out of it. You can use this to pump bytes into/out of a socket. When you pump bytes from the socket into the Transport, it may change the state of the Connection and/or any of the objects it contains (Sessions, Links, Deliveries, etc). It may in fact cause new Session, Link, or Delivery endpoints to be created. The best way to find out what exactly has happened here is to use the events API. The events API allows you to register the Connection with a Collector. When a Connection is registered with a Collector it will post events to that Collector. Each event has a pointer back into the object model indicating which object has changed state, and a type that indicates how/why it changed state. You can look at event.h (or the doxygen) for a list of all the core events. --Rafael
Re: Ruby memory management (was: Ruby and the Engine APIs)
On Fri, Jan 30, 2015 at 10:40 AM, Darryl L. Pierce dpie...@redhat.com wrote: On Wed, Jan 28, 2015 at 01:22:45PM -0500, Rafael Schloming wrote: snip Also, have you been able to validate your testing strategy for either/both of these POCs? Can you generate seg faults and/or valgrind warnings when you intentionally comment out the line of code that keeps the reference alive? The POC that uses manual wrapping of a C struct works correctly, preventing objects from being reaped without leaking memory. I validated this by creating exhaustive (1M+) instances of both pure Ruby and C structs that have been wrapped via the Data_Wrap_Struct, assigning the Ruby object to the C struct so that only C held a reference to it, then calling GC.start to reap objects and then checking that the expected number of the pure Ruby objects still existed, via ObjectSpace.each_object([class]).count. Accessing the C-help Ruby object and doing functions such as class_eval on it worked without segmentation faults. I then ensures that it wasn't a fluke by commenting out, in the function that marks the Ruby object in C to keep it from being reaped, and re-running the tests. The app *immediately* segfaults after trying to class_eval the first Ruby object after garbage collection. So this path is the right one to follow. This sounds promising, is there any way you could highlight the key bits to look at on the branch you pointed to? Maybe post it in a way that would permit line by line comments? (My git-fu isn't super strong, so if there's already a way to do this with what you posted I apologize for the request.) --Rafael
Re: Ruby, Proton Engine and Records
Is this the approach you referenced in your other email? (Same request here for a pointer to the highlighted key bits of the approach.) On Fri, Jan 30, 2015 at 4:11 PM, Darryl L. Pierce dpie...@redhat.com wrote: So over the last week I've been working on a way to avoid leaking memory or causing segfaults when the underlying C library is giving a reference to a Ruby object. And after much coding and gnashing of teeth I foudn the easiest way to do this with manually wrapping the pn_record_t struct. That would allow for adding a mark function to mark any Ruby objects so that they could not be reaped during garbage collection. And this would work fine but for one problem: the instances of pn_record are created by transport, etc. as part of *their* initializations. So there is no way for us to manually wrap the pn_record_t type for Ruby use in Swig. So looking at things, I have an alternate method that's not brittle and which gives us the feature we're looking for. From the Swig code, we can wrap the call to pn_record_set, at which point we have access to the Ruby wrapper for the pn_record_t type. We can then add/modify instance variables on that Ruby wrapper. Specifically, we can add and then update one named pn_record_attrs (or any other arbitrary name) and use it to track any objects that're added or replaced for the record. And the bonus is that, when the pn_record_t is deleted, it's Ruby wrapper is deleted as well and _all_ instance variables (including our Ruby objects) will be reaped along with it. I'm going to do some more testing on this, but my initial findings support this memory management scheme as viable. I have a test application that creates 500k+ values, storing them in a single record instance. Iterating back over the records and recovering them after running garbage collect returns variables as expected. Commenting out the portion that manages the wrapper instance variable and the same tests fail with a segfault while accessing the records. The work can all be checked out here [1], with the changes to the ruby.i file as the most recent commit in the branch. I'd love to get some feedback on this work in general as well. [1] https://github.com/mcpierce/Proton/tree/PROTON-799-Ruby-engine-apis -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
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
[jira] [Commented] (PROTON-775) ruby: message annotations send from a ruby client are invalid
[ https://issues.apache.org/jira/browse/PROTON-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14309067#comment-14309067 ] Dominic Evans commented on PROTON-775: -- [~mcpierce] do you have any thoughts of how we might be able to fix this? ruby: message annotations send from a ruby client are invalid - Key: PROTON-775 URL: https://issues.apache.org/jira/browse/PROTON-775 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.8 Reporter: Dominic Evans Since PROTON-616, proton-j has attempted to enforce the fact that the key's of a message annotations map *must* be of the Symbol type (or actually ulong, but those are reserved so we don't need to worry about that) [1] Unfortunately, from the Ruby client, the mapping of a native map into proton data always sets the key's as strings rather than symbols. In proton-j, you'll currently hit a `java.lang.ClassCastException: java.lang.String incompatible with org.apache.qpid.proton.amqp.Symbol` if you try to look at keys of the MessageAnnotations object of a message sent from the ruby send.rb example (which sets message annotations for the keys 'version' and 'pill'). -- [1] http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-annotations -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-775) ruby: message annotations send from a ruby client are invalid
[ https://issues.apache.org/jira/browse/PROTON-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce reassigned PROTON-775: --- Assignee: Darryl L. Pierce ruby: message annotations send from a ruby client are invalid - Key: PROTON-775 URL: https://issues.apache.org/jira/browse/PROTON-775 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Darryl L. Pierce Since PROTON-616, proton-j has attempted to enforce the fact that the key's of a message annotations map *must* be of the Symbol type (or actually ulong, but those are reserved so we don't need to worry about that) [1] Unfortunately, from the Ruby client, the mapping of a native map into proton data always sets the key's as strings rather than symbols. In proton-j, you'll currently hit a `java.lang.ClassCastException: java.lang.String incompatible with org.apache.qpid.proton.amqp.Symbol` if you try to look at keys of the MessageAnnotations object of a message sent from the ruby send.rb example (which sets message annotations for the keys 'version' and 'pill'). -- [1] http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-annotations -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [Fwd: [jira] [Commented] (DISPATCH-103) Websocket Listeners]
On Fri, Feb 6, 2015 at 9:28 AM, Alan Conway acon...@redhat.com wrote: On Fri, 2015-02-06 at 08:19 -0500, 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, including list now. Extremely useful discussion, thanks! Taking it all on board. New question: For dispatch I only care about the server side. JavaScript is the only websocket client I know of and as per discussion below we would actually need to *exclude* proton client-side websocket support from the JS client, so maybe we don't need it at all. Are there use cases for a websocket client transport? The main use case I know of for non-browser websocket *client* use is firewall traversal. I think you can also do this by simply using SSL though, although there may be some corner cases where that does't work as well. I think the main benefit of building it out in proton though is to get more uniform support for it on proton based servers, e.g. if proton can just autodetect it, then it should be pretty trivial to support it in qpidd as well as dispatch. --Rafael
Re: request/response stuff has broken the java build
On Thu, 2015-01-29 at 12:13 -0500, Rafael Schloming wrote: On Thu, Jan 29, 2015 at 11:42 AM, Andrew Stitcher astitc...@redhat.com wrote: On Wed, 2015-01-28 at 16:09 -0500, Alan Conway wrote: On Tue, 2015-01-27 at 09:46 -0500, Rafael Schloming wrote: Do you have tracing turned on when they time out? With the protocol trace enabled the tests slow down enough that some of them don't finish before the various timeouts kick in. Much more insidious. It turns out that if you use 0.0.0.0 as a connect address AND you have a VPN running AND you are using jython then things hang (at least on fedora 20 in my house in January.) Looking up the ip(7) man page it seems like 0.0.0.0 is only supposed to be used as a bind address, not a connect address, so I switched the tests in question to use 127.0.0.1 and everything works (it also works if I turn off my VPN or use proper python) I didn't switch everything in python to use 127.0.0.1 for connect (NOTE 0.0.0.0 is still correct for listening) in case there was some hidden disaster there. Probably at least the examples and maybe the default port for class Url should be changed, any dissent? I'm curious to know where 0.0.0.0 as a default connect address came from because it should never have worked at all, unless it is handled specially somewhere. I think it's always worked for me, and I'm pretty sure we don't have any special handling for it. I started using 0.0.0.0 since I started working on proton and dispatch, I never used it with qpid c++. Just copying like an idiot. I have a vague impression there was a discussion about it being better. It *is* definitely better on the *server* side, maybe it just spilled over into client side use without careful thought. Looking at the ip(7) man page it does appear to be just plain wrong for use on client. As Rafi said it is not a special proton thing - ssh 0.0.0.0 also works. I guess most TCP stacks treat 0.0.0.0 as 127.0.0.1 but I don't know if there is a standard that says you MUST treat 0.0.0.0 as 127.0.0.1 so maybe it's not a reliable thing to use. Definitely jython does something completely daft on my laptop if VPN is on.
