[jira] [Commented] (PROTON-126) Sender.send should return 0 once it has exceeded the credit window
[ https://issues.apache.org/jira/browse/PROTON-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495362#comment-13495362 ] Hiram Chirino commented on PROTON-126: -- Opened up PROTON-128 for that. Perhaps send should return void if it's always supposed to fully consume the full it's given. > Sender.send should return 0 once it has exceeded the credit window > -- > > Key: PROTON-126 > URL: https://issues.apache.org/jira/browse/PROTON-126 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Reporter: Hiram Chirino > > No flow control is in place. You can easily OOM a JVM since Sender.send > continues to accept more bytes even if the peer is not accepting anymore data. -- 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-128) Access the link's queued size in bytes to aid callers in implementing flow control
Hiram Chirino created PROTON-128: Summary: Access the link's queued size in bytes to aid callers in implementing flow control Key: PROTON-128 URL: https://issues.apache.org/jira/browse/PROTON-128 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Reporter: Hiram Chirino -- 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-128) Access the link's queued size in bytes to aid callers in implementing flow control
[ https://issues.apache.org/jira/browse/PROTON-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated PROTON-128: - Priority: Minor (was: Major) > Access the link's queued size in bytes to aid callers in implementing flow > control > -- > > Key: PROTON-128 > URL: https://issues.apache.org/jira/browse/PROTON-128 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, proton-j >Reporter: Hiram Chirino >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
[jira] [Updated] (PROTON-128) Access the link's queued size in bytes to aid callers in implementing flow control
[ https://issues.apache.org/jira/browse/PROTON-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated PROTON-128: - Issue Type: New Feature (was: Bug) > Access the link's queued size in bytes to aid callers in implementing flow > control > -- > > Key: PROTON-128 > URL: https://issues.apache.org/jira/browse/PROTON-128 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c, proton-j >Reporter: Hiram Chirino >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
[jira] [Resolved] (PROTON-125) Driver dies unnecessarily when poll returns error EINTR
[ https://issues.apache.org/jira/browse/PROTON-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved PROTON-125. - Resolution: Fixed Re-resolved. pn_driver_wait now returns an error rather than exiting the process. It is up to the application to take appropriate action for poll errors. > Driver dies unnecessarily when poll returns error EINTR > --- > > Key: PROTON-125 > URL: https://issues.apache.org/jira/browse/PROTON-125 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.2 >Reporter: Ted Ross >Assignee: Ted Ross > Fix For: 0.3 > > Attachments: PROTON-125.patch > > > If a program that uses proton-c receives a signal (SIGHUP, etc.), it will > intermittently exit with a "System Call Interrupted" (EINTR) error. > The DIE_IFE macro that wraps the call to "poll" in the driver needs to handle > this error to avoid unnecessary process exits. -- 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-126) Sender.send should return 0 once it has exceeded the credit window
[ https://issues.apache.org/jira/browse/PROTON-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495339#comment-13495339 ] Rafael H. Schloming commented on PROTON-126: That's a good point. Want me to change this to said RFE or should we file that separately? > Sender.send should return 0 once it has exceeded the credit window > -- > > Key: PROTON-126 > URL: https://issues.apache.org/jira/browse/PROTON-126 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Reporter: Hiram Chirino > > No flow control is in place. You can easily OOM a JVM since Sender.send > continues to accept more bytes even if the peer is not accepting anymore data. -- 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-127) Rename the org.apache.qpid.proton.type package for nicer Scala support
[ https://issues.apache.org/jira/browse/PROTON-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated PROTON-127: - Component/s: proton-j > Rename the org.apache.qpid.proton.type package for nicer Scala support > -- > > Key: PROTON-127 > URL: https://issues.apache.org/jira/browse/PROTON-127 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Reporter: Hiram Chirino >Priority: Minor > > 'type' is a reserved word in Scala. So when using proton from scala, you end > up doing imports like: > import org.apache.qpid.proton.`type`.messaging.Accepted > Which is kinda ugly. Would be nice if that package was renamed so something > else. -- 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-127) Rename the org.apache.qpid.proton.type package for nicer Scala support
Hiram Chirino created PROTON-127: Summary: Rename the org.apache.qpid.proton.type package for nicer Scala support Key: PROTON-127 URL: https://issues.apache.org/jira/browse/PROTON-127 Project: Qpid Proton Issue Type: Bug Reporter: Hiram Chirino Priority: Minor 'type' is a reserved word in Scala. So when using proton from scala, you end up doing imports like: import org.apache.qpid.proton.`type`.messaging.Accepted Which is kinda ugly. Would be nice if that package was renamed so something else. -- 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-126) Sender.send should return 0 once it has exceeded the credit window
[ https://issues.apache.org/jira/browse/PROTON-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495287#comment-13495287 ] Hiram Chirino commented on PROTON-126: -- Ok, makes sense. Would be nice to also get the queued size in bytes and not just messages. That way I can flow control myself after a couple queued message if they are large. > Sender.send should return 0 once it has exceeded the credit window > -- > > Key: PROTON-126 > URL: https://issues.apache.org/jira/browse/PROTON-126 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Reporter: Hiram Chirino > > No flow control is in place. You can easily OOM a JVM since Sender.send > continues to accept more bytes even if the peer is not accepting anymore data. -- 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: delivery vs tracker
On Wed, Oct 31, 2012 at 7:45 PM, Justin Ross wrote: > > > On Wed, 31 Oct 2012, Darryl L. Pierce wrote: > > On Tue, Oct 30, 2012 at 08:15:42AM -0400, Rafael Schloming wrote: >> >>> My inclination is to persue option 2 for the following reasons: >>> >>> - Option 1 introduces more burden since users need to explicitly >>> manage the lifecycle of the returned objects. While this burden >>> might be mitigated in a garbage collected language, it would quite >>> likely significantly impact performance to let the GC manage >>> retiring these delivery objects. (The engine underneath messenger >>> is quite capable of cycling through hundreds of thousands of >>> deliveries per second, and this would most likely put a >>> significant burden on any GC subsystem.) >>> >>> - Option 1 introduces additional action objects, the user model is >>> simpler if all the actions stay with messenger. >>> >>> - Option 1 requires coming up with a name for something that is like >>> a delivery but not quite. >>> >>> - Option 2 potentially offers more capabilities in terms of >>> persisting delivery state outside a messenger. >>> >>> - Option 2 maps pretty naturally to the protocol notion of >>> delivery-tag and lends itself to a pretty easy name/analogy. One >>> option is pn_tracking_id_t, however I prefer the slightly more >>> abstract pn_tracker_t as it suggests a bit less about how it >>> might be implemented under the covers. >>> >> >> +1 on option 2, since it appears to be much more flexible and, as you >> indicate, keeps the actions in Messenger. This is much more logical IMO. >> > > I personally prefer option 1. Forgetting for a moment the quite legit > concerns that Rafi mentions, it produces the better api, imo. > > I said before that I liked how users only had to engage delivery when they > were ready. From that standpoint, keeping #acknowledge() and #settle() on > delivery is better. That way, all the verbs on messenger act conceptually > on messages. For some people, that will be the furthest they need to go. > Then, only if you opt to handle deliveries do you discover the verbs to > handle delivery state. > This is a bit of a tangent, but I think conceptually all the verbs on messenger are actually acting on deliveries. I know it looks syntactically like put and get operate on a message, but that is really incidental as the message object is purely a mutable holder/authoring tool for message content. What put and get are really doing is creating/accessing a delivery (i.e. stuffing your letter into an envelope, or opening up the envelope and giving you the letter). That said, I buy the concern about lots of handle objects. For me, this > refocuses the question on how we might support such objects in at least > some of the bindings. I would argue that we want that option. It should be trivial to wrap the handle in an object that holds a reference to both the messenger and the tracker. That's not quite what I did in python (see my other post), however I think what I did has a similarly small footprint. I think which style makes more sense depends somewhat on the extent to which these things are used individually or in aggregate, i.e. if aggregate is the common case, then the tracker as an entity is less of a fit. As an aside, I would avoid thinking of an entity wrapping up a reference to the messenger and a handle as a Delivery, both because that is a distinct and formally defined concept, and because there are subtle but important differences. It's really a reference to a delivery that may no longer exist, and it also has the property of identifying a point in a sequence of deliveries allowing for identifying ranges of deliveries for aggregate operations. --Rafael
messenger acks
Hi Everyone,
I was a bit slammed leading up to the 0.2 release, and I didn't get a
chance to wrap up any of the ack threads, so I thought I'd post a summary
of what I actually ended up doing. Please check out the docs for more
details, but I'll describe briefly the interface changes in C first and
then how I mapped them into python. The following definitions were added to
messenger.h, starting with the pn_tracker_t handle:
typedef int64_t pn_tracker_t;
There is now a unique handle associated with every call to
pn_messenger_put/get. Note that the signatures of pn_messenger_put/get are
entirely unchanged. If you care about tracking the status of the delivery
associated with a given call you can use the newly added
pn_messenger_outgoing_tracker and pn_messenger_incoming_tracker calls to
access the handle associated with the last put/get calls respectively:
pn_tracker_t pn_messenger_outgoing_tracker(pn_messenger_t *messenger);
pn_tracker_t pn_messenger_incoming_tracker(pn_messenger_t *messenger);
There is now also an accept mode (defaulting to auto):
typedef enum {
PN_ACCEPT_MODE_AUTO,
PN_ACCEPT_MODE_MANUAL
} pn_accept_mode_t;
pn_accept_mode_t pn_messenger_get_accept_mode(pn_messenger_t *messenger);
int pn_messenger_set_accept_mode(pn_messenger_t *messenger,
pn_accept_mode_t mode);
If the accept mode is manual, then you have to use the following methods to
either accept or reject incoming messages. Note that you can do this either
individually or cumulatively, for example to accept all retrieved messages
you could do this: pn_messenger_accept(m, pn_messenger_incoming_tracker(m),
PN_CUMULATIVE). This is mapped somewhat more conveniently in the python
binding.
#define PN_CUMULATIVE (0x1)
int pn_messenger_accept(pn_messenger_t *messenger, pn_tracker_t tracker,
int flags);
int pn_messenger_reject(pn_messenger_t *messenger, pn_tracker_t tracker,
int flags);
Now to access the status of a given delivery, you can simply pass the
tracker into the new pn_messenger_status call:
pn_status_t pn_messenger_status(pn_messenger_t *messenger, pn_tracker_t
tracker);
typedef enum {
PN_STATUS_UNKNOWN = 0,
PN_STATUS_PENDING = 1,
PN_STATUS_ACCEPTED = 2,
PN_STATUS_REJECTED = 3
} pn_status_t;
This call works for both incoming and outgoing deliveries and returns the
last known remote status of the delivery associated with the given tracker.
Of course by default nothing is actually tracked, so it won't provide much
useful information until you turn on tracking. This is done by setting the
incoming and outgoing tracking windows via these new calls:
int pn_messenger_get_outgoing_window(pn_messenger_t *messenger);
int pn_messenger_set_outgoing_window(pn_messenger_t *messenger, int window);
int pn_messenger_get_incoming_window(pn_messenger_t *messenger);
int pn_messenger_set_incoming_window(pn_messenger_t *messenger, int window);
Setting the outgoing tracking window to a positive value will cause the
messenger to track the status of that many deliveries *after* calls to
send. Setting the incoming tracking window to a positive value will cause
the messenger to track the status of that many deliveries *after* calls to
accept.
You can use pn_messenger_settle to clear either window without waiting for
deliveries to roll off the end. This has identical signature to
accept/reject except it can work with both incoming and outgoing trackers.
int pn_messenger_settle(pn_messenger_t *messenger, pn_tracker_t tracker,
int flags); // incoming or outgoing
The python bindings for all this simplify it a little bit. The accept_mode,
and incoming/outgoing window map to properties of the messenger. Also,
unlike in C where we need the return value of put/get to carry the error
code, we have exceptions in python, so I simply returned the tracker
directly from put/get rather than having a separate accessor for the most
recent one. And of course accept/reject take no args and operate
cumulatively by default, however you can pass in an individual tracker if
you wish to operate non cumulatively. I've attached a diff that illustrates
the changes to the send.py/recv.py examples to get them to operate reliably.
--Rafael
[jira] [Commented] (PROTON-126) Sender.send should return 0 once it has exceeded the credit window
[ https://issues.apache.org/jira/browse/PROTON-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495224#comment-13495224 ] Rafael H. Schloming commented on PROTON-126: This behaviour is by design. The idea is that you can choose to have the engine buffer message data for you if you wish. This is very useful for certain kinds of implementations (e.g. clients). If you want to avoid this you can check the credit level before you call send or alternatively (for a slightly different effect) you could check how many queued messages the sender is holding and choose whether or not you want to queue more. > Sender.send should return 0 once it has exceeded the credit window > -- > > Key: PROTON-126 > URL: https://issues.apache.org/jira/browse/PROTON-126 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Reporter: Hiram Chirino > > No flow control is in place. You can easily OOM a JVM since Sender.send > continues to accept more bytes even if the peer is not accepting anymore data. -- 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-126) Sender.send should return 0 once it has exceeded the credit window
Hiram Chirino created PROTON-126: Summary: Sender.send should return 0 once it has exceeded the credit window Key: PROTON-126 URL: https://issues.apache.org/jira/browse/PROTON-126 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Hiram Chirino No flow control is in place. You can easily OOM a JVM since Sender.send continues to accept more bytes even if the peer is not accepting anymore data. -- 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
