Re: Sending messages with the Messenger API
I tried your suggestion and set an outgoing window of 1 and that did in fact allow me to omit the stop() after every send(). It seems that whatever you are suspecting is probably right! :-) Thanks! - Paul On Mon, Jan 28, 2013 at 12:26 PM, Paul O'Fallon wrote: > Thanks for the reply! To your first question -- I haven't created a > special test case for this, but it is in my code here: > > > https://github.com/pofallon/node-qpid/blob/master/src/messenger.cc#L168-L177 > > (I'm in the early stages of writing node.js bindings to proton-c's > Messenger API) > > This code calls put, start, send and stop for each message (and will send > the message). If I comment out the "stop" on line 177 the messages are not > sent. (To see how this is invoked via node.js, see: > https://github.com/pofallon/node-qpid/blob/master/test/test.js#L18) > > To your second question, my end goal is "yes" to share it between threads. > Today my "Messenger" javascript object uses two pn_messenger instances -- > one to send and another to receive. However, I'd like to collapse that > into one instance for both sending and receiving (across multiple threads). > > Thanks again! > > - Paul > > On Mon, Jan 28, 2013 at 6:32 AM, Rafael Schloming wrote: > >> On Fri, Jan 25, 2013 at 9:53 PM, Paul O'Fallon > >wrote: >> >> > Hello! I'm new to proton (and AMQP), and have some questions about >> using >> > the Messenger API in the C library to send messages to Windows Azure. >> I've >> > noticed that it takes three steps before a message is actually sent >> (i.e. >> > before it is fetched when running the 'recv' command line example). I >> call >> > pn_messenger_put(), pn_messenger_send(), and then pn_messenger_stop(). >> My >> > question is about the third call -- to pn_messenger_stop(). If I omit >> that >> > and just call the first two, the message is not actually sent. >> > >> > My concern is whether calling stop() after every send will be a problem >> in >> > the case where I want to use the same instance of messenger to call >> recv() >> > in a separate thread. The API docs state "A messenger cannot send or >> recv >> > messages when it is stopped.". >> > >> > So, two questions: >> > >> > (1) Is the need to call stop() after each send() expected behavior? >> > >> >> I wouldn't expect that you need to call stop() after each send(), however >> you should call it before exiting the program. Do you have a code fragment >> you could post that reproduces the behaviour you're seeing? It sounds like >> it could be a bug, if it is what I suspect you could try working around it >> by setting a positive outgoing window. >> >> >> > (2) Will repeatedly calling stop() affect the recv() running in the >> > separate thread? >> > >> >> Are you sharing a single messenger between the two threads? >> >> --Rafael >> > >
[jira] [Assigned] (PROTON-206) Use const char* variables for string literals
[ https://issues.apache.org/jira/browse/PROTON-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen reassigned PROTON-206: --- Assignee: Cliff Jansen > Use const char* variables for string literals > - > > Key: PROTON-206 > URL: https://issues.apache.org/jira/browse/PROTON-206 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.3 > Environment: all >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Minor > Fix For: 0.4 > > > proton sometimes uses declarations of the form > char *host = "0.0.0.0"; > These should be hunted down and replaced with a const declaration. Where > these variables are passed as arguments to other functions, those should be > additionally changed to const where appropriate. This occurs in > examples/messenger/c/send.c > examples/messenger/c/recv.c > src/messenger.c > src/util.c > src/proton.c -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-206) Use const char* variables for string literals
Cliff Jansen created PROTON-206: --- Summary: Use const char* variables for string literals Key: PROTON-206 URL: https://issues.apache.org/jira/browse/PROTON-206 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.3 Environment: all Reporter: Cliff Jansen Priority: Minor Fix For: 0.4 proton sometimes uses declarations of the form char *host = "0.0.0.0"; These should be hunted down and replaced with a const declaration. Where these variables are passed as arguments to other functions, those should be additionally changed to const where appropriate. This occurs in examples/messenger/c/send.c examples/messenger/c/recv.c src/messenger.c src/util.c src/proton.c -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-204) Handling of partial messages is broken in java messenger
[
https://issues.apache.org/jira/browse/PROTON-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13564521#comment-13564521
]
Gordon Sim commented on PROTON-204:
---
This requires an additional method to be exposed on Delivery, equivalent to
pn_delivery_partial(). Patch posted below in case there is any comment, but it
is a trivial addition:
{noformat}
Index:
proton-j/proton-api/src/main/java/org/apache/qpid/proton/engine/Delivery.java
===
---
proton-j/proton-api/src/main/java/org/apache/qpid/proton/engine/Delivery.java
(revision 1439491)
+++
proton-j/proton-api/src/main/java/org/apache/qpid/proton/engine/Delivery.java
(working copy)
@@ -68,4 +68,6 @@
public Object getContext();
public boolean isUpdated();
+
+public boolean isPartial();
}
Index:
proton-j/proton/src/main/java/org/apache/qpid/proton/engine/impl/DeliveryImpl.java
===
---
proton-j/proton/src/main/java/org/apache/qpid/proton/engine/impl/DeliveryImpl.java
(revision 1439491)
+++
proton-j/proton/src/main/java/org/apache/qpid/proton/engine/impl/DeliveryImpl.java
(working copy)
@@ -408,6 +408,11 @@
_complete = true;
}
+public boolean isPartial()
+{
+return !_complete;
+}
+
void setRemoteDeliveryState(DeliveryState remoteDeliveryState)
{
_remoteDeliveryState = remoteDeliveryState;
{noformat}
> Handling of partial messages is broken in java messenger
>
>
> Key: PROTON-204
> URL: https://issues.apache.org/jira/browse/PROTON-204
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Affects Versions: 0.3
>Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: 0.4
>
>
> I.e. where a read from the network reads part of a message but doesn't get
> all the data yet. This exhibits itself as a buffer underflow in
> MessengerImpl.get().
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-205) java messenger does not set source and target correctly
Gordon Sim created PROTON-205: - Summary: java messenger does not set source and target correctly Key: PROTON-205 URL: https://issues.apache.org/jira/browse/PROTON-205 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.3 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.4 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-204) Handling of partial messages is broken in java messenger
Gordon Sim created PROTON-204: - Summary: Handling of partial messages is broken in java messenger Key: PROTON-204 URL: https://issues.apache.org/jira/browse/PROTON-204 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.3 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.4 I.e. where a read from the network reads part of a message but doesn't get all the data yet. This exhibits itself as a buffer underflow in MessengerImpl.get(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-199) [Proton-c] Python binding requires python 2.6+
[ https://issues.apache.org/jira/browse/PROTON-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13564429#comment-13564429 ] Ken Giusti commented on PROTON-199: --- I'm able to run the proton unit tests on Centos 5.9 (python 2.4.3) with the following patch: https://reviews.apache.org/r/9123/ which addresses some syntax changes and the alias of the 'bytes' type. Centos 5.9 provides the necessary python UUID stuff via the python-uuid package (I've got python-uuid-1.30-3.el5 installed). > [Proton-c] Python binding requires python 2.6+ > -- > > Key: PROTON-199 > URL: https://issues.apache.org/jira/browse/PROTON-199 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.3 > Environment: python versions < 2.5 >Reporter: Ken Giusti >Priority: Minor > > Python bindings make use of (at least two) python language features that > require python versions newer than 2.5: > - uuid > - bytes > In order to support older versions of the python language, these features > would have to be removed, or a compatibility layer would need to be provided. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Sending messages with the Messenger API
Thanks for the reply! To your first question -- I haven't created a special test case for this, but it is in my code here: https://github.com/pofallon/node-qpid/blob/master/src/messenger.cc#L168-L177 (I'm in the early stages of writing node.js bindings to proton-c's Messenger API) This code calls put, start, send and stop for each message (and will send the message). If I comment out the "stop" on line 177 the messages are not sent. (To see how this is invoked via node.js, see: https://github.com/pofallon/node-qpid/blob/master/test/test.js#L18) To your second question, my end goal is "yes" to share it between threads. Today my "Messenger" javascript object uses two pn_messenger instances -- one to send and another to receive. However, I'd like to collapse that into one instance for both sending and receiving (across multiple threads). Thanks again! - Paul On Mon, Jan 28, 2013 at 6:32 AM, Rafael Schloming wrote: > On Fri, Jan 25, 2013 at 9:53 PM, Paul O'Fallon >wrote: > > > Hello! I'm new to proton (and AMQP), and have some questions about using > > the Messenger API in the C library to send messages to Windows Azure. > I've > > noticed that it takes three steps before a message is actually sent (i.e. > > before it is fetched when running the 'recv' command line example). I > call > > pn_messenger_put(), pn_messenger_send(), and then pn_messenger_stop(). > My > > question is about the third call -- to pn_messenger_stop(). If I omit > that > > and just call the first two, the message is not actually sent. > > > > My concern is whether calling stop() after every send will be a problem > in > > the case where I want to use the same instance of messenger to call > recv() > > in a separate thread. The API docs state "A messenger cannot send or > recv > > messages when it is stopped.". > > > > So, two questions: > > > > (1) Is the need to call stop() after each send() expected behavior? > > > > I wouldn't expect that you need to call stop() after each send(), however > you should call it before exiting the program. Do you have a code fragment > you could post that reproduces the behaviour you're seeing? It sounds like > it could be a bug, if it is what I suspect you could try working around it > by setting a positive outgoing window. > > > > (2) Will repeatedly calling stop() affect the recv() running in the > > separate thread? > > > > Are you sharing a single messenger between the two threads? > > --Rafael >
[jira] [Resolved] (PROTON-203) pn_listener_set_context() not wrapped correctly in the python bindings
[ https://issues.apache.org/jira/browse/PROTON-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-203. Resolution: Fixed Fix Version/s: 0.4 Looks like Ken already fixed this issue. It should be included in the upcoming 0.4 release. > pn_listener_set_context() not wrapped correctly in the python bindings > -- > > Key: PROTON-203 > URL: https://issues.apache.org/jira/browse/PROTON-203 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Saggi Mizrahi >Priority: Minor > Fix For: 0.4 > > Attachments: > 0001-Add-missing-wrapper-around-pn_listener_set_context.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-150) [Proton-J] Surface necessary methods in interface to remove need to cast to Impl
[ https://issues.apache.org/jira/browse/PROTON-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-150: --- Fix Version/s: (was: 0.3) 0.4 > [Proton-J] Surface necessary methods in interface to remove need to cast to > Impl > > > Key: PROTON-150 > URL: https://issues.apache.org/jira/browse/PROTON-150 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: 0.4 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-33) Provide API for user managed pn_message_t payload/memory
[ https://issues.apache.org/jira/browse/PROTON-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-33: -- Fix Version/s: (was: 0.2) 0.4 > Provide API for user managed pn_message_t payload/memory > > > Key: PROTON-33 > URL: https://issues.apache.org/jira/browse/PROTON-33 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: William Henry >Priority: Blocker > Labels: api > Fix For: 0.4 > > > Some users will have their own frameworks and methods of managing the data > received. > Currently in the pn_message_t the only way to get at the payload/data is to > call pn_message_save with a pre-allocated buffer of data. pn_message_save > copies to that data buffer and returns the actual size. (so for example if I > passed an allocated buffer of 1028 I might be returned 8 bytes). > In many situations this alloc is expensive - especially when integrating with > established frameworks that already do the copy - now there are two allocs. > I suggest an API call that returns the message payload as a pointer. There > is a risk that this might get deleted and a pn_message_t should check that > it's buffer is still valid (I assume it would.) In the case I'm looking at > the "other" framework is merely making it's own copy but doesn't free the > memory (but, as I said, there is a risk it could). > I'm willing to debate pn_message_t having an API that returns a copy but I > imagine many users will any up complaining about the alloc in the that API > call. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-144) Reduce byte overhead for small payloads
[
https://issues.apache.org/jira/browse/PROTON-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming updated PROTON-144:
---
Fix Version/s: (was: 0.2)
0.4
> Reduce byte overhead for small payloads
> ---
>
> Key: PROTON-144
> URL: https://issues.apache.org/jira/browse/PROTON-144
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.2, 0.3
>Reporter: Affan Dar
> Labels: message, performance
> Fix For: 0.4
>
>
> In constrained bandwidth scenarios (e.g. on a cellular data network) any byte
> overhead is very costly.
> From the traces for a simple app, we are seeing a large overhead (>100 bytes)
> in the message payload for sending a two byte message. It seems like there
> are some default properties like the to and reply-to addresses that the
> proton client stamps onto a message and also there is padding on the actual
> two byte payload itself.
> To be able to successfully embed the proton lib in such resource constrained
> devices the byte overhead needs to be trimmed down as much as the protocol
> allows.
> ---
> Details of test app
> ---
> The testing environment is OpenSUSE 11.4 64bit, the AMQP library is from SVN
> updated usually once a day although commits have slowed since the push for
> 0.2 and libopenssl version 1.0.0e-34.17.1.
> The debugging output is all from proton, to get the debugging output set the
> Env variable "PN_TRACE_FRM=1"
> The test is done connecting to localhost and sending a message across as
> simply as possible:
> client:
> pn_messenger_t *messenger = pn_messenger("b");
> pn_messenger_start(messenger);
> pn_message_t *message = pn_message();
> pn_message_set_address(message, "amqps://0.0.0.0/a");
> char data[2] = {(unsigned char)0xff, (unsigned char)0xff};
> pn_message_load_data(message, data, 2);
> pn_messenger_put(messenger, message);
> pn_messenger_send(messenger);
>
> server code:
> pn_messenger_t *messenger = pn_messenger("a");
> pn_messenger_start(messenger);
> pn_messenger_subscribe(messenger, "amqps://~0.0.0.0");
> pn_message_t *message = pn_message();
> pn_messenger_recv(messenger, 1);
> pn_messenger_get(messenger, message);
> size_t size = 2;
> char data[2];
> pn_message_save_data(message, data, &size);
>
> server output:
> Accepted from localhost.localdomain:36331
> -> SASL
> [0x622180:0] -> SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]]
> [0x622180:0] -> SASL-OUTCOME @68 [0]
> -> AMQP
> [0x61c7c0:0] -> OPEN @16 ["a", null, null, null, null, null, null, null, null]
> <- SASL
> [0x622180:0] <- SASL-INIT @65 [:ANONYMOUS, b""]
> <- AMQP
> [0x61c7c0:0] <- OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null,
> null]
> [0x61c7c0:1] <- BEGIN @17 [null, 0, 1024, 1024]
> [0x61c7c0:1] <- ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["a", 0,
> null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0,
> false, null, null], null, null, 0]
> [0x61c7c0:1] -> BEGIN @17 [1, 0, 1024, 1024]
> [0x61c7c0:1] -> ATTACH @18 ["sender-xxx", 1, true, null, null, @40 ["a", 0,
> null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0,
> false, null, null], null, null, 0]
> [0x61c7c0:1] -> FLOW @19 [0, 1024, 0, 1024, 1, 0, 1, null, false]
> [0x61c7c0:1] <- TRANSFER @20 [1, 0, b"\x00\x00\x00\x00\x00\x00\x00\x00", 0,
> true, false] (133)
> "\x00\x80\x00\x00\x00\x00\x00\x00\x00p\xd0\x00\x00\x00\x10\x00\x00\x00\x05V\x00P\x04@V\x00p\x00\x00\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00s\xd0\x00\x00\x00F\x00\x00\x00\x0d@@\xb1\x00\x00\x00\x11amqps://0.0.0.0/a@\xb1\x00\x00\x00\x08amqp://b@@@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@p\x00\x00\x00\x00@\x00\x80\x00\x00\x00\x00\x00\x00\x00w\xb0\x00\x00\x00\x02\xff\xff"
>
> client output:
> Connected to 0.0.0.0:5671
> -> SASL
> [0x620020:0] -> SASL-INIT @65 [:ANONYMOUS, b""]
> <- SASL
> [0x620020:0] <- SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]]
> [0x620020:0] <- SASL-OUTCOME @68 [0]
> <- AMQP
> [0x61a840:0] <- OPEN @16 ["a", null, null, null, null, null, null, null, null]
> -> AMQP
> [0x61a840:0] -> OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null,
> null]
> [0x61a840:1] -> BEGIN @17 [null, 0, 1024, 1024]
> [0x61a840:1] -> ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["a", 0,
> null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0,
> false, null, null], null, null, 0]
> [0x61a840:1] <- BEGIN @17 [1, 0, 1024, 1024]
> [0x61a840:1] <- ATTACH @18 ["sender-xxx", 1, true, null, null, @40 ["a", 0,
> null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0,
> false, null, null], null, null, 0]
> [0x61a840:1] <- FLOW @19 [0, 1024, 0, 1024, 1, 0,
[jira] [Updated] (PROTON-100) Clean up examples README.txt file
[ https://issues.apache.org/jira/browse/PROTON-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-100: --- Fix Version/s: (was: 0.1) 0.4 > Clean up examples README.txt file > - > > Key: PROTON-100 > URL: https://issues.apache.org/jira/browse/PROTON-100 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.1 >Reporter: William Henry > Fix For: 0.4 > > > The README.txt file in the examples directory needs to be cleaned up. > Still mentions examples mailbox and broker. > Doesn't mention example ruby. > $ more README.txt > This directory contains example applications that use the Proton library. > broker/- a python message broker > mailbox/ - a toy mailbox client/server example > messenger/ - simple examples using the messenger API -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-203) pn_listener_set_context() not wrapped correctly in the python bindings
[ https://issues.apache.org/jira/browse/PROTON-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saggi Mizrahi updated PROTON-203: - Attachment: 0001-Add-missing-wrapper-around-pn_listener_set_context.patch > pn_listener_set_context() not wrapped correctly in the python bindings > -- > > Key: PROTON-203 > URL: https://issues.apache.org/jira/browse/PROTON-203 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Saggi Mizrahi >Priority: Minor > Attachments: > 0001-Add-missing-wrapper-around-pn_listener_set_context.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-203) pn_listener_set_context() not wrapped correctly in the python bindings
Saggi Mizrahi created PROTON-203: Summary: pn_listener_set_context() not wrapped correctly in the python bindings Key: PROTON-203 URL: https://issues.apache.org/jira/browse/PROTON-203 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Saggi Mizrahi Priority: Minor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Reducing the visibility of proton-j constructors
I'm using proton in more that one place :)
So the proton-hawtdispatch module gets used by Apollo and the
amqp-benchmark projects, but ActiveMQ 5.x use proton more directly.
On Mon, Jan 28, 2013 at 8:21 AM, Phil Harvey wrote:
> Yeah, I don't have a problem with doing this for Proton 0.4 if people think
> the API change caused by our constructor visibility reduction is too
> abrupt.
>
> I don't think this is strictly necessary for Hiram's code to continue
> working, since Keith and I are modifying it to use factories. This is
> already done on the JNI branch - take a look at
>
> https://svn.apache.org/repos/asf/qpid/proton/branches/jni-binding/proton-j/contrib
> .
> However, I understand there may be other projects already calling these
> constructors so accept we need to be polite to our users.
>
> We'd put @SuppressWarnings("deprecation") in EngineFactoryImpl so that its
> (valid) use of the constructors wouldn't cause compiler warnings.
>
> We would then make the constructors package-private in the followong
> release - Proton 0.5.
>
> Any objections?
>
> Phil
>
>
> On 28 January 2013 11:40, Rafael Schloming wrote:
>
> > Would it be better if we were to deprecate the constructors and remove
> them
> > in a future release?
> >
> > --Rafael
> >
> > On Fri, Jan 25, 2013 at 6:25 PM, Hiram Chirino > >wrote:
> >
> > > I was hoping I could upgrade to newer proton versions without having to
> > > change my client code, since I was not planning on using the JNI impl
> > > anyways.
> > >
> > >
> > > On Fri, Jan 25, 2013 at 4:24 PM, Rajith Attapattu > > >wrote:
> > >
> > > > This is also my impression about Hirams work.
> > > > So I'm not sure why there is resistance to the changes being proposed
> > > > as it's only going to benefit in the long run should the impl
> changes.
> > > > (I do understand that there will be some initial work in changing the
> > > > code to use the factories and interfaces).
> > > >
> > > > I also thought part of Phil's (and Rob's) work was to come up with a
> > > > set of interfaces for the API.
> > > > If I'm not mistaken this work is already sitting in a branch ? (I
> > > > stand to be corrected though).
> > > >
> > > > Rajith
> > > >
> > > > On Fri, Jan 25, 2013 at 3:44 PM, Rafael Schloming
> > > > wrote:
> > > > > FWIW, I don't think Hiram's usage fundamentally needs to depend on
> > the
> > > > pure
> > > > > Java impl. I may be out of date on this one, but I believe his
> access
> > > of
> > > > > the implementation was done for expediency. I know at least in a
> > number
> > > > of
> > > > > cases we discussed how the C implementation could accommodate his
> > > > > requirements, and we plan do to so at some point. Perhaps our
> efforts
> > > > here
> > > > > would be better spent in building out the interface so that he
> > doesn't
> > > > need
> > > > > direct access to the implementation.
> > > > >
> > > > > --Rafael
> > > > >
> > > > > On Fri, Jan 25, 2013 at 10:31 AM, Phil Harvey <
> > > p...@philharveyonline.com
> > > > >wrote:
> > > > >
> > > > >> This has implications for API versioning,
> > > > >>
> > > > >> I think developers of third party code can assume that the API of
> > > public
> > > > >> methods, including constructors, will remain stable across minor
> > > > revisions
> > > > >> of a library. If a constructor is public then we, the Proton
> > > > developers,
> > > > >> have an obligation to respect this assumption (or at least to add
> > "for
> > > > >> internal use only" to its Javadoc).
> > > > >>
> > > > >> On reflection, I'm coming round to the idea that keeping these
> > > > constructors
> > > > >> public will place unreasonable restrictions on our ability to
> evolve
> > > the
> > > > >> implementation whilst keeping the API stable.
> > > > >>
> > > > >> Phil
> > > > >>
> > > > >>
> > > > >> On 25 January 2013 14:51, Rob Godfrey
> > > wrote:
> > > > >>
> > > > >> > What's your need for the direct constructor?
> > > > >> >
> > > > >> >
> > > > >> > -- Rob
> > > > >> >
> > > > >> > On 25 January 2013 15:49, Hiram Chirino >
> > > > wrote:
> > > > >> > > Let me clarify, I have no problem with adding Factories and
> > using
> > > > them
> > > > >> > > everywhere possible. Just don't take my access away from
> direct
> > > > >> > > constructors.
> > > > >> > >
> > > > >> > >
> > > > >> > > On Fri, Jan 25, 2013 at 9:39 AM, Rob Godfrey <
> > > > rob.j.godf...@gmail.com
> > > > >> > >wrote:
> > > > >> > >
> > > > >> > >> In general dependency on implementation is bad, dependency on
> > > > >> interface
> > > > >> > is
> > > > >> > >> better. One of the problems we've had with Qpid historically
> > is
> > > it
> > > > >> > become
> > > > >> > >> hard to test as we have dependencies on implementation
> > > everywhere.
> > > > >> > >>
> > > > >> > >> From an end user perspective the difference is only replacing
> > > > >> > >>
> > > > >> > >> X x = new X();
> > > > >> > >>
> > > > >> > >> with
> > > > >> > >>
> > > > >> > >> X x = XFactory.newInstance();
Re: Reducing the visibility of proton-j constructors
Yeah, At least it will give me time to migrate over and report any issues I may run into. On Mon, Jan 28, 2013 at 6:40 AM, Rafael Schloming wrote: > Would it be better if we were to deprecate the constructors and remove them > in a future release? > > --Rafael > > On Fri, Jan 25, 2013 at 6:25 PM, Hiram Chirino >wrote: > > > I was hoping I could upgrade to newer proton versions without having to > > change my client code, since I was not planning on using the JNI impl > > anyways. > > > > > > On Fri, Jan 25, 2013 at 4:24 PM, Rajith Attapattu > >wrote: > > > > > This is also my impression about Hirams work. > > > So I'm not sure why there is resistance to the changes being proposed > > > as it's only going to benefit in the long run should the impl changes. > > > (I do understand that there will be some initial work in changing the > > > code to use the factories and interfaces). > > > > > > I also thought part of Phil's (and Rob's) work was to come up with a > > > set of interfaces for the API. > > > If I'm not mistaken this work is already sitting in a branch ? (I > > > stand to be corrected though). > > > > > > Rajith > > > > > > On Fri, Jan 25, 2013 at 3:44 PM, Rafael Schloming > > > wrote: > > > > FWIW, I don't think Hiram's usage fundamentally needs to depend on > the > > > pure > > > > Java impl. I may be out of date on this one, but I believe his access > > of > > > > the implementation was done for expediency. I know at least in a > number > > > of > > > > cases we discussed how the C implementation could accommodate his > > > > requirements, and we plan do to so at some point. Perhaps our efforts > > > here > > > > would be better spent in building out the interface so that he > doesn't > > > need > > > > direct access to the implementation. > > > > > > > > --Rafael > > > > > > > > On Fri, Jan 25, 2013 at 10:31 AM, Phil Harvey < > > p...@philharveyonline.com > > > >wrote: > > > > > > > >> This has implications for API versioning, > > > >> > > > >> I think developers of third party code can assume that the API of > > public > > > >> methods, including constructors, will remain stable across minor > > > revisions > > > >> of a library. If a constructor is public then we, the Proton > > > developers, > > > >> have an obligation to respect this assumption (or at least to add > "for > > > >> internal use only" to its Javadoc). > > > >> > > > >> On reflection, I'm coming round to the idea that keeping these > > > constructors > > > >> public will place unreasonable restrictions on our ability to evolve > > the > > > >> implementation whilst keeping the API stable. > > > >> > > > >> Phil > > > >> > > > >> > > > >> On 25 January 2013 14:51, Rob Godfrey > > wrote: > > > >> > > > >> > What's your need for the direct constructor? > > > >> > > > > >> > > > > >> > -- Rob > > > >> > > > > >> > On 25 January 2013 15:49, Hiram Chirino > > > wrote: > > > >> > > Let me clarify, I have no problem with adding Factories and > using > > > them > > > >> > > everywhere possible. Just don't take my access away from direct > > > >> > > constructors. > > > >> > > > > > >> > > > > > >> > > On Fri, Jan 25, 2013 at 9:39 AM, Rob Godfrey < > > > rob.j.godf...@gmail.com > > > >> > >wrote: > > > >> > > > > > >> > >> In general dependency on implementation is bad, dependency on > > > >> interface > > > >> > is > > > >> > >> better. One of the problems we've had with Qpid historically > is > > it > > > >> > become > > > >> > >> hard to test as we have dependencies on implementation > > everywhere. > > > >> > >> > > > >> > >> From an end user perspective the difference is only replacing > > > >> > >> > > > >> > >> X x = new X(); > > > >> > >> > > > >> > >> with > > > >> > >> > > > >> > >> X x = XFactory.newInstance(); > > > >> > >> > > > >> > >> But it makes it a lot easier to properly describe the > > functionality > > > >> > being > > > >> > >> returned. For implementation reasons, the concrete class may > have > > > >> public > > > >> > >> methods that are not intended to be exposed to the application > > > >> > programmer > > > >> > >> but only to other cooperating classes. To avoid confusion, and > > to > > > >> make > > > >> > it > > > >> > >> clear to us the delta between the "shared" API and the API > > > extensions > > > >> > that > > > >> > >> we are supporting for the pure Java implementation the > interfaces > > > seem > > > >> > like > > > >> > >> the right way to go for me. > > > >> > >> > > > >> > >> The idea is that those who need the extension features will > still > > > >> have a > > > >> > >> very clear way to get the implementation that provides these, > > > without > > > >> > ever > > > >> > >> having to cast. > > > >> > >> > > > >> > >> -- Rob > > > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> On 24 January 2013 20:03, Rafael Schloming > > > wrote: > > > >> > >> > > > >> > >> > On Thu, Jan 24, 2013 at 5:06 AM, Rob Godfrey < > > > >> rob.j.godf...@gmail.com > > > >>
Re: Reducing the visibility of proton-j constructors
Yeah, I don't have a problem with doing this for Proton 0.4 if people think
the API change caused by our constructor visibility reduction is too
abrupt.
I don't think this is strictly necessary for Hiram's code to continue
working, since Keith and I are modifying it to use factories. This is
already done on the JNI branch - take a look at
https://svn.apache.org/repos/asf/qpid/proton/branches/jni-binding/proton-j/contrib.
However, I understand there may be other projects already calling these
constructors so accept we need to be polite to our users.
We'd put @SuppressWarnings("deprecation") in EngineFactoryImpl so that its
(valid) use of the constructors wouldn't cause compiler warnings.
We would then make the constructors package-private in the followong
release - Proton 0.5.
Any objections?
Phil
On 28 January 2013 11:40, Rafael Schloming wrote:
> Would it be better if we were to deprecate the constructors and remove them
> in a future release?
>
> --Rafael
>
> On Fri, Jan 25, 2013 at 6:25 PM, Hiram Chirino >wrote:
>
> > I was hoping I could upgrade to newer proton versions without having to
> > change my client code, since I was not planning on using the JNI impl
> > anyways.
> >
> >
> > On Fri, Jan 25, 2013 at 4:24 PM, Rajith Attapattu > >wrote:
> >
> > > This is also my impression about Hirams work.
> > > So I'm not sure why there is resistance to the changes being proposed
> > > as it's only going to benefit in the long run should the impl changes.
> > > (I do understand that there will be some initial work in changing the
> > > code to use the factories and interfaces).
> > >
> > > I also thought part of Phil's (and Rob's) work was to come up with a
> > > set of interfaces for the API.
> > > If I'm not mistaken this work is already sitting in a branch ? (I
> > > stand to be corrected though).
> > >
> > > Rajith
> > >
> > > On Fri, Jan 25, 2013 at 3:44 PM, Rafael Schloming
> > > wrote:
> > > > FWIW, I don't think Hiram's usage fundamentally needs to depend on
> the
> > > pure
> > > > Java impl. I may be out of date on this one, but I believe his access
> > of
> > > > the implementation was done for expediency. I know at least in a
> number
> > > of
> > > > cases we discussed how the C implementation could accommodate his
> > > > requirements, and we plan do to so at some point. Perhaps our efforts
> > > here
> > > > would be better spent in building out the interface so that he
> doesn't
> > > need
> > > > direct access to the implementation.
> > > >
> > > > --Rafael
> > > >
> > > > On Fri, Jan 25, 2013 at 10:31 AM, Phil Harvey <
> > p...@philharveyonline.com
> > > >wrote:
> > > >
> > > >> This has implications for API versioning,
> > > >>
> > > >> I think developers of third party code can assume that the API of
> > public
> > > >> methods, including constructors, will remain stable across minor
> > > revisions
> > > >> of a library. If a constructor is public then we, the Proton
> > > developers,
> > > >> have an obligation to respect this assumption (or at least to add
> "for
> > > >> internal use only" to its Javadoc).
> > > >>
> > > >> On reflection, I'm coming round to the idea that keeping these
> > > constructors
> > > >> public will place unreasonable restrictions on our ability to evolve
> > the
> > > >> implementation whilst keeping the API stable.
> > > >>
> > > >> Phil
> > > >>
> > > >>
> > > >> On 25 January 2013 14:51, Rob Godfrey
> > wrote:
> > > >>
> > > >> > What's your need for the direct constructor?
> > > >> >
> > > >> >
> > > >> > -- Rob
> > > >> >
> > > >> > On 25 January 2013 15:49, Hiram Chirino
> > > wrote:
> > > >> > > Let me clarify, I have no problem with adding Factories and
> using
> > > them
> > > >> > > everywhere possible. Just don't take my access away from direct
> > > >> > > constructors.
> > > >> > >
> > > >> > >
> > > >> > > On Fri, Jan 25, 2013 at 9:39 AM, Rob Godfrey <
> > > rob.j.godf...@gmail.com
> > > >> > >wrote:
> > > >> > >
> > > >> > >> In general dependency on implementation is bad, dependency on
> > > >> interface
> > > >> > is
> > > >> > >> better. One of the problems we've had with Qpid historically
> is
> > it
> > > >> > become
> > > >> > >> hard to test as we have dependencies on implementation
> > everywhere.
> > > >> > >>
> > > >> > >> From an end user perspective the difference is only replacing
> > > >> > >>
> > > >> > >> X x = new X();
> > > >> > >>
> > > >> > >> with
> > > >> > >>
> > > >> > >> X x = XFactory.newInstance();
> > > >> > >>
> > > >> > >> But it makes it a lot easier to properly describe the
> > functionality
> > > >> > being
> > > >> > >> returned. For implementation reasons, the concrete class may
> have
> > > >> public
> > > >> > >> methods that are not intended to be exposed to the application
> > > >> > programmer
> > > >> > >> but only to other cooperating classes. To avoid confusion, and
> > to
> > > >> make
> > > >> > it
> > > >> > >> clear to us the delta between the "shared" API and the API
> > > exte
Re: Reducing the visibility of proton-j constructors
Would it be better if we were to deprecate the constructors and remove them in a future release? --Rafael On Fri, Jan 25, 2013 at 6:25 PM, Hiram Chirino wrote: > I was hoping I could upgrade to newer proton versions without having to > change my client code, since I was not planning on using the JNI impl > anyways. > > > On Fri, Jan 25, 2013 at 4:24 PM, Rajith Attapattu >wrote: > > > This is also my impression about Hirams work. > > So I'm not sure why there is resistance to the changes being proposed > > as it's only going to benefit in the long run should the impl changes. > > (I do understand that there will be some initial work in changing the > > code to use the factories and interfaces). > > > > I also thought part of Phil's (and Rob's) work was to come up with a > > set of interfaces for the API. > > If I'm not mistaken this work is already sitting in a branch ? (I > > stand to be corrected though). > > > > Rajith > > > > On Fri, Jan 25, 2013 at 3:44 PM, Rafael Schloming > > wrote: > > > FWIW, I don't think Hiram's usage fundamentally needs to depend on the > > pure > > > Java impl. I may be out of date on this one, but I believe his access > of > > > the implementation was done for expediency. I know at least in a number > > of > > > cases we discussed how the C implementation could accommodate his > > > requirements, and we plan do to so at some point. Perhaps our efforts > > here > > > would be better spent in building out the interface so that he doesn't > > need > > > direct access to the implementation. > > > > > > --Rafael > > > > > > On Fri, Jan 25, 2013 at 10:31 AM, Phil Harvey < > p...@philharveyonline.com > > >wrote: > > > > > >> This has implications for API versioning, > > >> > > >> I think developers of third party code can assume that the API of > public > > >> methods, including constructors, will remain stable across minor > > revisions > > >> of a library. If a constructor is public then we, the Proton > > developers, > > >> have an obligation to respect this assumption (or at least to add "for > > >> internal use only" to its Javadoc). > > >> > > >> On reflection, I'm coming round to the idea that keeping these > > constructors > > >> public will place unreasonable restrictions on our ability to evolve > the > > >> implementation whilst keeping the API stable. > > >> > > >> Phil > > >> > > >> > > >> On 25 January 2013 14:51, Rob Godfrey > wrote: > > >> > > >> > What's your need for the direct constructor? > > >> > > > >> > > > >> > -- Rob > > >> > > > >> > On 25 January 2013 15:49, Hiram Chirino > > wrote: > > >> > > Let me clarify, I have no problem with adding Factories and using > > them > > >> > > everywhere possible. Just don't take my access away from direct > > >> > > constructors. > > >> > > > > >> > > > > >> > > On Fri, Jan 25, 2013 at 9:39 AM, Rob Godfrey < > > rob.j.godf...@gmail.com > > >> > >wrote: > > >> > > > > >> > >> In general dependency on implementation is bad, dependency on > > >> interface > > >> > is > > >> > >> better. One of the problems we've had with Qpid historically is > it > > >> > become > > >> > >> hard to test as we have dependencies on implementation > everywhere. > > >> > >> > > >> > >> From an end user perspective the difference is only replacing > > >> > >> > > >> > >> X x = new X(); > > >> > >> > > >> > >> with > > >> > >> > > >> > >> X x = XFactory.newInstance(); > > >> > >> > > >> > >> But it makes it a lot easier to properly describe the > functionality > > >> > being > > >> > >> returned. For implementation reasons, the concrete class may have > > >> public > > >> > >> methods that are not intended to be exposed to the application > > >> > programmer > > >> > >> but only to other cooperating classes. To avoid confusion, and > to > > >> make > > >> > it > > >> > >> clear to us the delta between the "shared" API and the API > > extensions > > >> > that > > >> > >> we are supporting for the pure Java implementation the interfaces > > seem > > >> > like > > >> > >> the right way to go for me. > > >> > >> > > >> > >> The idea is that those who need the extension features will still > > >> have a > > >> > >> very clear way to get the implementation that provides these, > > without > > >> > ever > > >> > >> having to cast. > > >> > >> > > >> > >> -- Rob > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> On 24 January 2013 20:03, Rafael Schloming > > wrote: > > >> > >> > > >> > >> > On Thu, Jan 24, 2013 at 5:06 AM, Rob Godfrey < > > >> rob.j.godf...@gmail.com > > >> > >> > >wrote: > > >> > >> > > > >> > >> > > On 23 January 2013 17:36, Phil Harvey < > > p...@philharveyonline.com> > > >> > >> wrote: > > >> > >> > > > > > >> > >> > > > As part of the Proton JNI work, I would like to remove all > > calls > > >> > to > > >> > >> > > > proton-j implementation constructors from "client code". I > > >> intend > > >> > >> that > > >> > >> > > > factories will be used instead [1], thereby abstracting > away > > >> > wheth
Re: Sending messages with the Messenger API
On Fri, Jan 25, 2013 at 9:53 PM, Paul O'Fallon wrote: > Hello! I'm new to proton (and AMQP), and have some questions about using > the Messenger API in the C library to send messages to Windows Azure. I've > noticed that it takes three steps before a message is actually sent (i.e. > before it is fetched when running the 'recv' command line example). I call > pn_messenger_put(), pn_messenger_send(), and then pn_messenger_stop(). My > question is about the third call -- to pn_messenger_stop(). If I omit that > and just call the first two, the message is not actually sent. > > My concern is whether calling stop() after every send will be a problem in > the case where I want to use the same instance of messenger to call recv() > in a separate thread. The API docs state "A messenger cannot send or recv > messages when it is stopped.". > > So, two questions: > > (1) Is the need to call stop() after each send() expected behavior? > I wouldn't expect that you need to call stop() after each send(), however you should call it before exiting the program. Do you have a code fragment you could post that reproduces the behaviour you're seeing? It sounds like it could be a bug, if it is what I suspect you could try working around it by setting a positive outgoing window. > (2) Will repeatedly calling stop() affect the recv() running in the > separate thread? > Are you sharing a single messenger between the two threads? --Rafael
