Re: 0.6 Release/0.7 Planning
On 23. 10. 13 13:10, Rafael Schloming wrote: Hi Everyone, There have been a bunch of good fixes and improvements on trunk since 0.5, and we now have a dwindling number of JIRAs slated for 0.6, so it's probably time to start thinking about another release. I believe right now there are 7 outstanding 0.6 JIRAs. (Please give a shout if there are any JIRAs you believe should be included in 0.6 that are not currently on the list.) I'd like to see PROTON-428 and PROTON-290 in 0.6 Bozzo
[jira] [Updated] (PROTON-428) proton-hawtdispatch drops data when more than 512 bytes are read from the socket
[ https://issues.apache.org/jira/browse/PROTON-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-428: --- Fix Version/s: 0.6 proton-hawtdispatch drops data when more than 512 bytes are read from the socket Key: PROTON-428 URL: https://issues.apache.org/jira/browse/PROTON-428 Project: Qpid Proton Issue Type: Bug Reporter: Bozo Dragojevic Fix For: 0.6 Attachments: 0001-PROTON-428-proton-hawtdispatch-drops-data-when-more-.patch hawtdispatch AmqpTransport calls protons Transport.input() just once and assumes all data was consumed -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: 0.6 Release/0.7 Planning
They look pretty straightforward, I don't see why we can't get them into 0.6. --Rafael On Thu, Oct 24, 2013 at 7:26 AM, Bozo Dragojevic bo...@digiverse.si wrote: On 23. 10. 13 13:10, Rafael Schloming wrote: Hi Everyone, There have been a bunch of good fixes and improvements on trunk since 0.5, and we now have a dwindling number of JIRAs slated for 0.6, so it's probably time to start thinking about another release. I believe right now there are 7 outstanding 0.6 JIRAs. (Please give a shout if there are any JIRAs you believe should be included in 0.6 that are not currently on the list.) I'd like to see PROTON-428 and PROTON-290 in 0.6 Bozzo
Re: 0.6 Release/0.7 Planning
Thanks! Bozzo On 24. 10. 13 17:06, Rafael Schloming wrote: They look pretty straightforward, I don't see why we can't get them into 0.6. --Rafael On Thu, Oct 24, 2013 at 7:26 AM, Bozo Dragojevicbo...@digiverse.si wrote: On 23. 10. 13 13:10, Rafael Schloming wrote: Hi Everyone, There have been a bunch of good fixes and improvements on trunk since 0.5, and we now have a dwindling number of JIRAs slated for 0.6, so it's probably time to start thinking about another release. I believe right now there are 7 outstanding 0.6 JIRAs. (Please give a shout if there are any JIRAs you believe should be included in 0.6 that are not currently on the list.) I'd like to see PROTON-428 and PROTON-290 in 0.6 Bozzo
messenger store and links
Hi!
Chasing down a weird behavior...
looking at messengers pni_pump_out() and how it's used from
pn_messenger_endpoints()
link = pn_link_head(conn, PN_LOCAL_ACTIVE | PN_REMOTE_ACTIVE);
while (link) {
if (pn_link_is_sender(link)) {
pni_pump_out(messenger,
pn_terminus_get_address(pn_link_target(link)), link);
is it really fair to assume that target address is always expected to be
non NULL?
I've added a bit of debug code to pn_messenger_endpoints() so it reads:
link = pn_link_head(conn, PN_LOCAL_ACTIVE | PN_REMOTE_ACTIVE);
while (link) {
if (pn_link_is_sender(link)) {
static int addrnull, addrok;
const char *address = pn_terminus_get_address(pn_link_target(link));
if (!address) {
addrnull++;
} else {
addrok++;
}
fprintf(stderr, links with null address: %d links with ok
address %d\n,
addrnull, addrok);
pni_pump_out(messenger, address, link);
and I never see 'addrok' change from 0
when pni_pump_out is called with address==NULL:
int pni_pump_out(pn_messenger_t *messenger, const char *address,
pn_link_t *sender)
{
pni_entry_t *entry = pni_store_get(messenger-outgoing, address);
if (!entry) return 0;
pni_store_get cheerfuly returns first message on the list
end effect is that random clients start receiving messages not directed
at them.
For some inexplicable reason is mostly works out while there are just
two clients
connected to the messenger and we're not pushing it really hard. Still
trying to come
up with a simple test-case.
Can anyone shed some light how the addressing on the link level is
supposed to work in mesenger?
Bozzo
[jira] [Commented] (PROTON-393) messenger needs a way to reset the error
[ https://issues.apache.org/jira/browse/PROTON-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13804395#comment-13804395 ] ASF subversion and git services commented on PROTON-393: Commit 1535439 from r...@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1535439 ] PROTON-393: applied (modified) patch from Bozo messenger needs a way to reset the error Key: PROTON-393 URL: https://issues.apache.org/jira/browse/PROTON-393 Project: Qpid Proton Issue Type: Bug Reporter: Bozo Dragojevic Assignee: Rafael H. Schloming Fix For: 0.5 m = Messenger() m.recv(-1) # error no active sources m.subscribe(valid_address) # fails because messenger is in error state -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (PROTON-290) Allow querying of unsent messages by tracker
[ https://issues.apache.org/jira/browse/PROTON-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-290. Resolution: Fixed Assignee: Rafael H. Schloming Allow querying of unsent messages by tracker Key: PROTON-290 URL: https://issues.apache.org/jira/browse/PROTON-290 Project: Qpid Proton Issue Type: New Feature Reporter: Bozo Dragojevic Assignee: Rafael H. Schloming Fix For: 0.6 Attachments: 0001-PROTON-393-check-if-delivery-is-still-buffered-by-pr.patch messenger.status(tracker) returns PENDING until the message is either accepted or rejected by the recipient. Allow distinguishing between buffered locally and transmitted messages. -- This message was sent by Atlassian JIRA (v6.1#6144)
proposed Python API doc changes -- will check in on All Hallow's Eve
Dear Proton Proponents --
Here is my proposed text for Python Messenger API documentation.
If you'd like to comment, please do so within the next week.
I will incorporate feedback and check in the resulting
changes to the codebase at the stroke of midnight, on
All Hallows Eve. ( Samhain. )
I have given you the current text for each method and property,
and then my changes. My changes are either proposed replacements
( NEW_TEXT ) or proposed additions ( ADD_TEXT ).
Mostly, this is highly similar to the C API text, but with
minor changes for Pythonification.
-- Mick .
Class Comments
{
CURRENT_TEXT
{
The Messenger class defines a high level interface for
sending and receiving Messages. Every Messenger contains
a single logical queue of incoming messages and a single
logical queue of outgoing messages. These messages in these
queues may be destined for, or originate from, a variety of
addresses.
}
ADD_TEXT
{
The messenger interface is single-threaded. All methods
except one ( interrupt ) are intended to be used from within
the messenger thread.
}
}
Sending Receiving Messages
{
CURRENT_TEXT
{
The L{Messenger} class works in conjuction with the L{Message}
class. The L{Message} class is a mutable holder of message content.
The L{put} method will encode the content in a given L{Message}
object into the outgoing message queue leaving that L{Message}
object free to be modified or discarded without having any impact on
the content in the outgoing queue.
Similarly, the L{get} method will decode the content in the incoming
message queue into the supplied L{Message} object.
}
NEW_TEXT
{
The Messenger class works in conjuction with the Message class. The
Message class is a mutable holder of message content.
The put method copies its message to the outgoing queue, and may
send queued messages if it can do so without blocking. The send
method blocks until it has sent the requested number of messages,
or until a timeout interrupts the attempt.
Similarly, the recv() method receives messages into the incoming
queue, and may block until it has received the requested number of
messages, or until timeout is reached. The get method pops the
eldest message off the incoming queue and copies it into the message
object that you supply. It will not block.
}
NOTE
{
I thought it would be better in this comment to only emphasize
the blocking and non-blocking differences between get/put and
recv/send. Details about how the arg message is handled are moved
to the comments for specific methods.
}
}
Method Details
{
__init__
{
CURRENT_TEXT
{
Construct a new L{Messenger} with the given name. The name has
global scope. If a NULL name is supplied, a L{uuid.UUID} based
name will be chosen.
}
NEW_TEXT
{
// no change
}
}
__del__
{
CURRENT_TEXT
{
// none
}
NEW_TEXT
{
Destroy the messenger. This will close all connections that
are managed by the messenger. Call the stop method before
destroying the messenger.
}
}
start
{
CURRENT_TEXT
{
Transitions the L{Messenger} to an active state. A L{Messenger} is
initially created in an inactive state. When inactive a
L{Messenger} will not send or receive messages from its internal
queues. A L{Messenger} must be started before calling L{send} or
L{recv}.
}
NEW_TEXT
{
Currently a no-op placeholder.
For future compatibility, do not send or receive messages
before starting the messenger.
}
}
stop
{
CURRENT_TEXT
{
Transitions the L{Messenger} to an inactive state. An inactive
L{Messenger} will not send or receive messages from its internal
queues. A L{Messenger} should be stopped before being discarded to
ensure a clean shutdown handshake occurs on any internally managed
connections.
}
NEW_TEXT
{
// no change
}
}
subscribe
{
CURRENT_TEXT
{
Subscribes the L{Messenger} to messages originating from the
specified source. The source is an address as specified in the
L{Messenger} introduction with the following addition. If the
domain portion of the address begins with the '~'
[jira] [Commented] (PROTON-290) Allow querying of unsent messages by tracker
[
https://issues.apache.org/jira/browse/PROTON-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13804488#comment-13804488
]
Bozo Dragojevic commented on PROTON-290:
I think I just spotted a thinko in my logic. Buffered should return true if we
do not have a delivery yet or if delivery is still buffered:
{code}
-return d pn_delivery_buffered(d);
+return !d || pn_delivery_buffered(d);
{code}
Allow querying of unsent messages by tracker
Key: PROTON-290
URL: https://issues.apache.org/jira/browse/PROTON-290
Project: Qpid Proton
Issue Type: New Feature
Reporter: Bozo Dragojevic
Assignee: Rafael H. Schloming
Fix For: 0.6
Attachments:
0001-PROTON-393-check-if-delivery-is-still-buffered-by-pr.patch
messenger.status(tracker) returns PENDING until the message is either
accepted or rejected by the recipient.
Allow distinguishing between buffered locally and transmitted messages.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Reopened] (PROTON-290) Allow querying of unsent messages by tracker
[ https://issues.apache.org/jira/browse/PROTON-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bozo Dragojevic reopened PROTON-290: Allow querying of unsent messages by tracker Key: PROTON-290 URL: https://issues.apache.org/jira/browse/PROTON-290 Project: Qpid Proton Issue Type: New Feature Reporter: Bozo Dragojevic Assignee: Rafael H. Schloming Fix For: 0.6 Attachments: 0001-PROTON-393-check-if-delivery-is-still-buffered-by-pr.patch messenger.status(tracker) returns PENDING until the message is either accepted or rejected by the recipient. Allow distinguishing between buffered locally and transmitted messages. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: messenger store and links
Can you post the exact addresses and routing configuration you're using and
which direction messages are flowing? I'd like to try to simulate this
using the example send/recv scripts.
My guess is that the issue may not be so much related to whether the
addresses are NULL or not but whether there are multiple receivers
competing for the same messages.
--Rafael
On Thu, Oct 24, 2013 at 11:52 AM, Bozo Dragojevic bo...@digiverse.siwrote:
Hi!
Chasing down a weird behavior...
looking at messengers pni_pump_out() and how it's used from
pn_messenger_endpoints()
link = pn_link_head(conn, PN_LOCAL_ACTIVE | PN_REMOTE_ACTIVE);
while (link) {
if (pn_link_is_sender(link)) {
pni_pump_out(messenger,
pn_terminus_get_address(pn_**link_target(link)),
link);
is it really fair to assume that target address is always expected to be
non NULL?
I've added a bit of debug code to pn_messenger_endpoints() so it reads:
link = pn_link_head(conn, PN_LOCAL_ACTIVE | PN_REMOTE_ACTIVE);
while (link) {
if (pn_link_is_sender(link)) {
static int addrnull, addrok;
const char *address = pn_terminus_get_address(pn_**
link_target(link));
if (!address) {
addrnull++;
} else {
addrok++;
}
fprintf(stderr, links with null address: %d links with ok address
%d\n,
addrnull, addrok);
pni_pump_out(messenger, address, link);
and I never see 'addrok' change from 0
when pni_pump_out is called with address==NULL:
int pni_pump_out(pn_messenger_t *messenger, const char *address, pn_link_t
*sender)
{
pni_entry_t *entry = pni_store_get(messenger-**outgoing, address);
if (!entry) return 0;
pni_store_get cheerfuly returns first message on the list
end effect is that random clients start receiving messages not directed at
them.
For some inexplicable reason is mostly works out while there are just two
clients
connected to the messenger and we're not pushing it really hard. Still
trying to come
up with a simple test-case.
Can anyone shed some light how the addressing on the link level is
supposed to work in mesenger?
Bozzo
Re: proposed Python API doc changes -- will check in on All Hallow's Eve
Thanks for the update. I've put some specific comments in line, but overall
this should be a big improvement.
--Rafael
On Thu, Oct 24, 2013 at 1:33 PM, Michael Goulish mgoul...@redhat.comwrote:
Dear Proton Proponents --
Here is my proposed text for Python Messenger API documentation.
If you'd like to comment, please do so within the next week.
I will incorporate feedback and check in the resulting
changes to the codebase at the stroke of midnight, on
All Hallows Eve. ( Samhain. )
I have given you the current text for each method and property,
and then my changes. My changes are either proposed replacements
( NEW_TEXT ) or proposed additions ( ADD_TEXT ).
Mostly, this is highly similar to the C API text, but with
minor changes for Pythonification.
-- Mick .
Class Comments
{
CURRENT_TEXT
{
The Messenger class defines a high level interface for
sending and receiving Messages. Every Messenger contains
a single logical queue of incoming messages and a single
logical queue of outgoing messages. These messages in these
queues may be destined for, or originate from, a variety of
addresses.
}
ADD_TEXT
{
The messenger interface is single-threaded. All methods
except one ( interrupt ) are intended to be used from within
the messenger thread.
}
}
Sending Receiving Messages
{
CURRENT_TEXT
{
The L{Messenger} class works in conjuction with the L{Message}
class. The L{Message} class is a mutable holder of message content.
The L{put} method will encode the content in a given L{Message}
object into the outgoing message queue leaving that L{Message}
object free to be modified or discarded without having any impact
on
the content in the outgoing queue.
Similarly, the L{get} method will decode the content in the
incoming
message queue into the supplied L{Message} object.
}
NEW_TEXT
{
The Messenger class works in conjuction with the Message class. The
Message class is a mutable holder of message content.
The put method copies its message to the outgoing queue, and may
send queued messages if it can do so without blocking. The send
method blocks until it has sent the requested number of messages,
or until a timeout interrupts the attempt.
Similarly, the recv() method receives messages into the incoming
queue, and may block until it has received the requested number of
messages, or until timeout is reached. The get method pops the
eldest message off the incoming queue and copies it into the
message
object that you supply. It will not block.
}
The blocking behavior of recv is actually slightly different than what you
state. It will block until it recvs *up to* N messages.
It's also probably worth noting somewhere that the blocking flag turns off
blocking entirely for the whole API with the exception
Messenger.work()/pn_messenger_work(). With blocking turned off calls like
send/recv will do what work they can without blocking and then return. You
can then use interrogatives like checking the number if incoming/outgoing
messages to see what outstanding work still remains.
NOTE
{
I thought it would be better in this comment to only emphasize
the blocking and non-blocking differences between get/put and
recv/send. Details about how the arg message is handled are moved
to the comments for specific methods.
}
}
Method Details
{
__init__
{
CURRENT_TEXT
{
Construct a new L{Messenger} with the given name. The name has
global scope. If a NULL name is supplied, a L{uuid.UUID} based
name will be chosen.
}
NEW_TEXT
{
// no change
}
}
__del__
{
CURRENT_TEXT
{
// none
}
NEW_TEXT
{
Destroy the messenger. This will close all connections that
are managed by the messenger. Call the stop method before
destroying the messenger.
}
}
start
{
CURRENT_TEXT
{
Transitions the L{Messenger} to an active state. A L{Messenger}
is
initially created in an inactive state. When inactive a
L{Messenger} will not send or receive messages from its internal
queues. A L{Messenger} must be started before calling L{send} or
L{recv}.
}
NEW_TEXT
{
Currently a no-op placeholder.
For future compatibility, do not send or receive messages
Re: messenger store and links
If this is with trunk I'm guessing you might be noticing a change in
reply-to behaviour from a recent fix:
https://issues.apache.org/jira/browse/PROTON-278
As you mention, previously an unset reply-to would get automatically filled
in with the messenger's name. This is no longer the case. That behaviour
was unintentional as there are times when you legitimately want the
reply-to to be left unset. The intended behaviour was to expand ~ at the
beginning of an address to the messenger's name. That is now how trunk
behaves, so if you set your reply-to's to ~ then your problem might go
away, although your question is still an interesting one as I believe if
you wished you could intentionally set up competing receivers using
explicit non-uuid addresses that collide.
--Rafael
On Thu, Oct 24, 2013 at 2:49 PM, Bozo Dragojevic bo...@digiverse.si wrote:
All messengers are created with default constructor (uuid-based names).
The 'broker' messenger does a pn_messenger_subscribe(amqp:/**/~
0.0.0.0:8194)
All messages are constructed with address amqp://127.0.0.1:8194 and leave
reply_to unset (so it's set to amqp://$uuid)
Broker does application-level routing of messages
a publisher sends a special 'register' message
replies are constructed using stored 'reply_to' address from incoming
message
forwarded messages are constructed using stored 'reply_to' address from
incoming 'registration' messages
Messenger routing facility is not used in any way.
All Messengers are running in async mode (broker and client library share
the same 'event loop code').
We're using outgoing trackers, mostly for the 'buffered' check
All incoming messages are accepted as soon as they are processed.
All outgoing messages are settled as soon as they are not buffered anymore
maybe it'd be possible to simulate the situation by commenting out the
pni_pump_out() in pn_messenger_put(), that, or at least checking if sender
link address really has anything to do with
the address calculated in pn_messenger_put()
Bozzo
On 24. 10. 13 20:25, Rafael Schloming wrote:
Can you post the exact addresses and routing configuration you're using
and
which direction messages are flowing? I'd like to try to simulate this
using the example send/recv scripts.
My guess is that the issue may not be so much related to whether the
addresses are NULL or not but whether there are multiple receivers
competing for the same messages.
--Rafael
On Thu, Oct 24, 2013 at 11:52 AM, Bozo Dragojevicbo...@digiverse.si**
wrote:
Hi!
Chasing down a weird behavior...
looking at messengers pni_pump_out() and how it's used from
pn_messenger_endpoints()
link = pn_link_head(conn, PN_LOCAL_ACTIVE | PN_REMOTE_ACTIVE);
while (link) {
if (pn_link_is_sender(link)) {
pni_pump_out(messenger, pn_terminus_get_address(pn_
link_target(link)),
link);
is it really fair to assume that target address is always expected to be
non NULL?
I've added a bit of debug code to pn_messenger_endpoints() so it reads:
link = pn_link_head(conn, PN_LOCAL_ACTIVE | PN_REMOTE_ACTIVE);
while (link) {
if (pn_link_is_sender(link)) {
static int addrnull, addrok;
const char *address = pn_terminus_get_address(pn_**
link_target(link));
if (!address) {
addrnull++;
} else {
addrok++;
}
fprintf(stderr, links with null address: %d links with ok address
%d\n,
addrnull, addrok);
pni_pump_out(messenger, address, link);
and I never see 'addrok' change from 0
when pni_pump_out is called with address==NULL:
int pni_pump_out(pn_messenger_t *messenger, const char *address,
pn_link_t
*sender)
{
pni_entry_t *entry = pni_store_get(messenger-outgoing, address);
if (!entry) return 0;
pni_store_get cheerfuly returns first message on the list
end effect is that random clients start receiving messages not directed
at
them.
For some inexplicable reason is mostly works out while there are just two
clients
connected to the messenger and we're not pushing it really hard. Still
trying to come
up with a simple test-case.
Can anyone shed some light how the addressing on the link level is
supposed to work in mesenger?
Bozzo
Re: messenger store and links
we don't have that commit yet. last merge from trunk was PROTON-440: fix from hiram git-svn-id: https://svn.apache.org/repos/asf/qpid/proton/trunk@1531508 13f79535-47bb-0310-9956-ffa450edef68 maybe this trace of an unsuspecting client (recv) connecting to a broker in 'hosed' state can illustrate. what happened before is this: broker was started. a publisher and a slow subscriber are started, they publish approx 2000 messages. when publisher is done it disconnects gracefully and the slow subscriber (living in a daemon thread) just dies. Broker is left alone with approx 800 messages inside messenger's store. broker is unaware the messages exist, thinks all is well (until keepalive timeout kicks in). $ PN_TRACE_FRM=1 ./recv amqp://127.0.0.1:8194 21 | head -200 Connected to 127.0.0.1:8194 - SASL [0x7fd051814600:0] - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b] - SASL [0x7fd051814600:0] - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]] [0x7fd051814600:0] - @sasl-outcome(68) [code=0] - AMQP [0x7fd05180e600:0] - @open(16) [container-id=8FC1DAF7-1783-41D7-A892-9CDC45BCAEA7] - AMQP [0x7fd05180e600:0] - @open(16) [container-id=CEF14E1A-4D53-44AE-A513-F82C489AEB63, hostname=127.0.0.1] [0x7fd05180e600:0] - @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0] [0x7fd05180e600:0] - @attach(18) [name=receiver-xxx, handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0] [0x7fd05180e600:0] - @flow(19) [incoming-window=2147483647, next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0, link-credit=1024, drain=false] [0x7fd05180e600:0] - @begin(17) [remote-channel=0, next-outgoing-id=0, incoming-window=2147483647, outgoing-window=1] [0x7fd05180e600:0] - @attach(18) [name=receiver-xxx, handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, initial-delivery-count=0] [0x7fd05180e600:0] - @transfer(20) [handle=0, delivery-id=0, delivery-tag=bw\x00\x00\x00\x00\x00\x00\x00, message-format=0, settled=true, more=false] (551) \x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00z\x00\x00\x00\x0d@@\xa1+amqp://d80a10f2-5e82-4fa4-a3d1-03ff188bbffa@\xa1+amqp://8FC1DAF7-1783-41D7-A892-9CDC45BCAEA7@@@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Sw\xd0\x00\x00\x01\x8a\x00\x00\x00\x06q\x00\x00\x00\x04q\x00\x00\x00\x08`\x00\x01\xa1\x0d... (truncated) [0x7fd05180e600:0] - @transfer(20) [handle=0, delivery-id=1, delivery-tag=bx\x00\x00\x00\x00\x00\x00\x00, message-format=0, settled=true, more=false] (551) \x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00z\x00\x00\x00\x0d@@\xa1+amqp://d80a10f2-5e82-4fa4-a3d1-03ff188bbffa@\xa1+amqp://8FC1DAF7-1783-41D7-A892-9CDC45BCAEA7@@@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Sw\xd0\x00\x00\x01\x8a\x00\x00\x00\x06q\x00\x00\x00\x04q\x00\x00\x00\x08`\x00\x01\xa1\x0d... (truncated) [0x7fd05180e600:0] - @transfer(20) [handle=0, delivery-id=2, delivery-tag=by\x00\x00\x00\x00\x00\x00\x00, message-format=0, settled=true, more=false] (551) \x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00z\x00\x00\x00\x0d@@\xa1+amqp://d80a10f2-5e82-4fa4-a3d1-03ff188bbffa@\xa1+amqp://8FC1DAF7-1783-41D7-A892-9CDC45BCAEA7@@@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Sw\xd0\x00\x00\x01\x8a\x00\x00\x00\x06q\x00\x00\x00\x04q\x00\x00\x00\x08`\x00\x01\xa1\x0d... (truncated) ... lots more Note the two addresses in the transfer frames. The 'to' address is lowercase and distinct from either container-id in the open frames. This is the address of the already gone slow subscriber. The 'reply_to' address is set and is from the broker, which is consistent with not having the change from PROTON-278 Below is the slice of the broker trace of the same thing. There is the extra printf from pn_messenger_endpoints before it calls pni_pump_out Accepted from localhost:53480 - SASL [0x7fbbc9846200:0] - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b] [0x7fbbc9846200:0] - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]] [0x7fbbc9846200:0] - @sasl-outcome(68) [code=0] - SASL - AMQP [0x7fbbc9840c00:0] - @open(16) [container-id=8FC1DAF7-1783-41D7-A892-9CDC45BCAEA7] - AMQP [0x7fbbc9840c00:0] - @open(16) [container-id=CEF14E1A-4D53-44AE-A513-F82C489AEB63, hostname=127.0.0.1] [0x7fbbc9840c00:0] - @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0] [0x7fbbc9840c00:0] - @attach(18) [name=receiver-xxx, handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0] [0x7fbbc9840c00:0]
[jira] [Updated] (PROTON-290) Allow querying of unsent messages by tracker
[ https://issues.apache.org/jira/browse/PROTON-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bozo Dragojevic updated PROTON-290: --- Attachment: 0001-PROTON-290-add-a-test-and-more-explicit-logic.patch Here is a test for buffered() plus python binding update and a fixed implementation You'll need to remove all the prints I left in the patch. reason is this: I find it odd that all 100 messages immediately get a delivery! Is this really intended behavior? if this is going to remain the case, either old or new logic had the same result Allow querying of unsent messages by tracker Key: PROTON-290 URL: https://issues.apache.org/jira/browse/PROTON-290 Project: Qpid Proton Issue Type: New Feature Reporter: Bozo Dragojevic Assignee: Rafael H. Schloming Fix For: 0.6 Attachments: 0001-PROTON-290-add-a-test-and-more-explicit-logic.patch, 0001-PROTON-393-check-if-delivery-is-still-buffered-by-pr.patch messenger.status(tracker) returns PENDING until the message is either accepted or rejected by the recipient. Allow distinguishing between buffered locally and transmitted messages. -- This message was sent by Atlassian JIRA (v6.1#6144)
