Re: AMQP 1.0 session outgoing-window usage / meaning
IIRC, the definition of the outgoing-window was largely motivated by the need to express to receivers certain conditions under which they may be required to settle deliveries in order to receive more. For example if an implementation uses a fixed sized array to store deliveries, and this array is keyed by the offset of the delivery-id from the smallest unsettled delivery, then although the sender may have sufficient credit to send more transfers, it may not actually be capable of doing this because the next delivery-id would land outside the range of deliveries that are currently represented within its fixed size array. This could happen for example if the receiver issues N credits (where N is the size of the sender's fixed array) and settles deliveries 2 through N. The sender is then stuck with an unsettled delivery in the first slot of its fixed sized array and cannot send another delivery until that first delivery is settled. Given this, it's certainly true an outgoing-window of 0 is kind of strange and useless. It's probably also true that it is never super useful for the incoming window of the receiver to be larger than the outgoing window of the sender (or vice versa) since one can't ever exceed the other, so I'd say your largest-possible-int default and max-frame-like treatment are fairly appropriate. --Rafael On Fri, Jul 3, 2015 at 8:57 AM, Robbie Gemmell robbie.gemm...@gmail.com wrote: Rob, Rafi, as authors of the spec and the related code in proton, do you have any thoughts to add here? Barring any discussion otherwise I will be looking to change proton to at least optionally allow controlling the outgoing window along the lines I mentioned near the end of my original mail. Robbie On 2 July 2015 at 00:15, Robbie Gemmell robbie.gemm...@gmail.com wrote: Thanks James. Some expansion which may be useful to add. When comparing the older JMS client, proton-c via the Messenger API, and the new JMS client using proton-j, its important to note that they aren't all doing the same thing even where their underlying implementations do seem to share the same behaviour in the cases of proton-c and proton-j. The older JMS client initializes its outgoing window to a fixed number in the session Begin frame and then doesnt seem to ever change it for subsequent Flow frames, and simply manages whether its session can later send transfer frames based on the current value of the remote incoming window. Proton-J and Proton-C similarly only base their session level decision to send transfers on the remote incoming window and not their own outgoing window (which as noted below means they violate their advertised outgoing window, which is often going to be 0). Proton-C and Proton-J both currently look to set the outgoing window at any given time to a calculated value based on either the number of buffered messages or the buffered bytes divided by frame size. If there are no buffered messages at the point the Begin and Flow frames are generated, then the outgoing-window will be set to 0. This appears to function the same for both proton-c and proton-j. A key point though is that I think much of the historic usage of proton-c against Service Bus has been via the Messenger API, which works somewhat differently than many others in that it looks to create a session and a sender and sends the messages in one pipelined sequence of transport output, which means that by the point the Begin frame actually gets generated there are indeed buffered messages to send which means the outgoing-window is initialised to a value greater than zero. Other APIs which create the session as a distinct step thus wont ever have buffered messages when the Begin frame gets created and so the outgoing-window is initialised to 0, which is the behaviour observed with the new JMS client using proton-j and also what I saw when trying proton-c via the Qpid Messaging C++ client (against qpidd). Robbie On 1 July 2015 at 20:54, James Birdsall jb...@microsoft.com wrote: FYI, I have forwarded this and important bits of the preceding discussion to our AMQP stack dev within the ServiceBus team. Both the Qpid JMS AMQP 1.0 legacy client and Proton-C have been working fine with Azure SB for years now. Proton-J, however, is not something we have explored previously, and obviously there is something different about its behavior compared to the other clients. The Qpid JMS client is our recommended JMS client for interop with ServiceBus, and we would like to keep up with the times and not have to direct customers to the legacy client, so we are very interested in figuring out the correct resolution to this issue. -Original Message- From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] Sent: Wednesday, July 1, 2015 7:48 AM To: us...@qpid.apache.org; proton@qpid.apache.org Subject: AMQP 1.0 session outgoing-window usage / meaning Hi
[jira] [Commented] (PROTON-881) Proton-j reactor implementation
[ https://issues.apache.org/jira/browse/PROTON-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14616378#comment-14616378 ] ASF GitHub Bot commented on PROTON-881: --- Github user prestona commented on the pull request: https://github.com/apache/qpid-proton/pull/40#issuecomment-119125236 Closing as merged. Proton-j reactor implementation --- Key: PROTON-881 URL: https://issues.apache.org/jira/browse/PROTON-881 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor To keep the proton-j codebase consistent with proton-c - there should be a native Java port of the reactor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: PROTON-881: Make connect a non-blocking ...
Github user prestona commented on the pull request: https://github.com/apache/qpid-proton/pull/40#issuecomment-119125236 Closing as merged. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-881) Proton-j reactor implementation
[ https://issues.apache.org/jira/browse/PROTON-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14616379#comment-14616379 ] ASF GitHub Bot commented on PROTON-881: --- Github user prestona closed the pull request at: https://github.com/apache/qpid-proton/pull/40 Proton-j reactor implementation --- Key: PROTON-881 URL: https://issues.apache.org/jira/browse/PROTON-881 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor To keep the proton-j codebase consistent with proton-c - there should be a native Java port of the reactor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: PROTON-881: Make connect a non-blocking ...
Github user prestona closed the pull request at: https://github.com/apache/qpid-proton/pull/40 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] qpid-proton pull request: Fix 2 Code Analysis warnings and a reall...
Github user dcristoloveanu closed the pull request at: https://github.com/apache/qpid-proton/pull/39 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-928) Cancellable tasks
[ https://issues.apache.org/jira/browse/PROTON-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14617258#comment-14617258 ] ASF subversion and git services commented on PROTON-928: Commit d4d22ee396163babcac19c48845b1f10ca3b5a48 in qpid-proton's branch refs/heads/master from [~bozzo] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=d4d22ee ] PROTON-928: cancellable tasks A scheduled task can be cancelled. A cancelled task does not prevent reactor from stopping running Cancellable tasks - Key: PROTON-928 URL: https://issues.apache.org/jira/browse/PROTON-928 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j, python-binding Reporter: Bozo Dragojevic Assignee: Bozo Dragojevic Allow scheduled tasks to be cancelled. A cancelled task does not keep reactor from stoping running -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-937) LinkImpl.localOpen() does not initialize source and target
[ https://issues.apache.org/jira/browse/PROTON-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14617261#comment-14617261 ] Bozo Dragojevic commented on PROTON-937: I've commited the fix, but i still owe a proper testcase, will leave this issue open LinkImpl.localOpen() does not initialize source and target -- Key: PROTON-937 URL: https://issues.apache.org/jira/browse/PROTON-937 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.9.1 Reporter: Bozo Dragojevic Assignee: Bozo Dragojevic -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-937) LinkImpl.localOpen() does not initialize source and target
[ https://issues.apache.org/jira/browse/PROTON-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14617259#comment-14617259 ] ASF subversion and git services commented on PROTON-937: Commit f6d74a47d1f3f4ee3f4f3a444e239a209276f928 in qpid-proton's branch refs/heads/master from [~bozzo] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f6d74a4 ] PROTON-937: LinkImpl.localOpen() does not initialize source and target LinkImpl.localOpen() does not initialize source and target -- Key: PROTON-937 URL: https://issues.apache.org/jira/browse/PROTON-937 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.9.1 Reporter: Bozo Dragojevic Assignee: Bozo Dragojevic -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-937) LinkImpl.localOpen() does not initialize source and target
Bozo Dragojevic created PROTON-937: -- Summary: LinkImpl.localOpen() does not initialize source and target Key: PROTON-937 URL: https://issues.apache.org/jira/browse/PROTON-937 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.9.1 Reporter: Bozo Dragojevic Assignee: Bozo Dragojevic -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-928) Cancellable tasks
[ https://issues.apache.org/jira/browse/PROTON-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bozo Dragojevic resolved PROTON-928. Resolution: Fixed Cancellable tasks - Key: PROTON-928 URL: https://issues.apache.org/jira/browse/PROTON-928 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j, python-binding Reporter: Bozo Dragojevic Assignee: Bozo Dragojevic Allow scheduled tasks to be cancelled. A cancelled task does not keep reactor from stoping running -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-938) Have APIs to know address of temporary queue created by Proton-J program
yanfeng liu created PROTON-938:
--
Summary: Have APIs to know address of temporary queue created by
Proton-J program
Key: PROTON-938
URL: https://issues.apache.org/jira/browse/PROTON-938
Project: Qpid Proton
Issue Type: Wish
Components: proton-j
Affects Versions: 0.9.1
Environment: Ubuntu Linux
Reporter: yanfeng liu
It seems that Proton-J lacks the method to retrieve the address of a temporary
queue created by Proton-J client application. The corresponding method exists
in Proton-C like:
pn_subscription_t * sub = NULL;
if ((sub = pn_messenger_subscribe(messenger, amqps://10.69.3.1/#)) == NULL)
{
printf(!!!queue %s does not exists\n,address);
}
printf(a subscribed address:%s\n,pn_subscription_address(sub));
However, in Proton-J, the Subscribe() method is defined as void.
Regards,
yf
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] qpid-proton pull request: -Fix 2 Code Analysis warnings and a real...
GitHub user dcristoloveanu opened a pull request: https://github.com/apache/qpid-proton/pull/43 -Fix 2 Code Analysis warnings and a realloc failure -Fix 2 Code Analysis warnings in iocp.c -Fix one realloc leak and the fact that the realloc result was not checked. This rippled through codec.c as more functions needed to have error checking. Also, more fixes regarding return values being checked need to be done throughout message.c, transport.c, etc., but the amount of changes is significant, so it needs to be done in several chunks. You can merge this pull request into a Git repository by running: $ git pull https://github.com/dcristoloveanu/qpid-proton FixCodeAnalysis Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/43.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #43 commit a41bcbd6b48bc9a4507a844d4aa9ec1a37cec189 Author: dcristoloveanu dcri...@microsoft.com Date: 2015-07-08T00:18:05Z -Fix 2 Code Analysis warnings in iocp.c -Fix one realloc leak and the fact that the realloc result was not checked. This rippled through codec.c as more functions needed to have error checking. Also, more fixes regarding return values being checked need to be done throughout message.c, transport.c, etc., but the amount of changes is significant, so it needs to be done in several chunks. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: 0.10 alpha1
I just took 826 -- I think I can still re-create the test that found it. Let me see if I can repro... - Original Message - Yay Rafi! Thanks! A simple query of currently outstanding blocker JIRAs affecting 0.9+ shows only three: https://issues.apache.org/jira/browse/PROTON-826 (unassigned) https://issues.apache.org/jira/browse/PROTON-923 (asticher) https://issues.apache.org/jira/browse/PROTON-934 (rschloming) The remaining open bugs affecting 0.9+ are: https://issues.apache.org/jira/browse/PROTON-826?jql=project%20%3D%20PROTON%20AND%20status%20in%20%28Open%2C%20%22In%20Progress%22%2C%20Reopened%29%20AND%20affectedVersion%20in%20%280.9%2C%200.9.1%2C%200.10%29%20ORDER%20BY%20priority%20DESC - Original Message - From: Rafael Schloming r...@alum.mit.edu To: proton@qpid.apache.org Sent: Tuesday, July 7, 2015 1:28:17 AM Subject: 0.10 alpha1 As promised, here is the first alpha for 0.10. It's posted in the usual places: Source code is here: http://people.apache.org/~rhs/qpid-proton-0.10-alpha1/ Java binaries are here: https://repository.apache.org/content/repositories/orgapacheqpid-1036 Please check it out and follow up with any issues. --Rafael -- -K - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: 0.10 alpha1
Yay Rafi! Thanks! A simple query of currently outstanding blocker JIRAs affecting 0.9+ shows only three: https://issues.apache.org/jira/browse/PROTON-826 (unassigned) https://issues.apache.org/jira/browse/PROTON-923 (asticher) https://issues.apache.org/jira/browse/PROTON-934 (rschloming) The remaining open bugs affecting 0.9+ are: https://issues.apache.org/jira/browse/PROTON-826?jql=project%20%3D%20PROTON%20AND%20status%20in%20%28Open%2C%20%22In%20Progress%22%2C%20Reopened%29%20AND%20affectedVersion%20in%20%280.9%2C%200.9.1%2C%200.10%29%20ORDER%20BY%20priority%20DESC - Original Message - From: Rafael Schloming r...@alum.mit.edu To: proton@qpid.apache.org Sent: Tuesday, July 7, 2015 1:28:17 AM Subject: 0.10 alpha1 As promised, here is the first alpha for 0.10. It's posted in the usual places: Source code is here: http://people.apache.org/~rhs/qpid-proton-0.10-alpha1/ Java binaries are here: https://repository.apache.org/content/repositories/orgapacheqpid-1036 Please check it out and follow up with any issues. --Rafael -- -K
[jira] [Assigned] (PROTON-826) recent checkin causes frequent double-free or corruption crash
[
https://issues.apache.org/jira/browse/PROTON-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
michael goulish reassigned PROTON-826:
--
Assignee: michael goulish
recent checkin causes frequent double-free or corruption crash
--
Key: PROTON-826
URL: https://issues.apache.org/jira/browse/PROTON-826
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Reporter: michael goulish
Assignee: michael goulish
Priority: Blocker
In my dispatch testing I am seeing frequent crashes in proton library that
began with proton checkin 01cb00c on 2015-02-15 report read and write
errors through the transport
The output at crash-time says this:
---
*** Error in `/home/mick/dispatch/install/sbin/qdrouterd': double free or
corruption (fasttop): 0x020ee880 ***
=== Backtrace: =
/lib64/libc.so.6[0x3e3d875a4f]
/lib64/libc.so.6[0x3e3d87cd78]
/lib64/libqpid-proton.so.2(pn_error_clear+0x18)[0x7f4f4f4e1f18]
/lib64/libqpid-proton.so.2(pn_error_set+0x11)[0x7f4f4f4e1f41]
/lib64/libqpid-proton.so.2(pn_error_vformat+0x3e)[0x7f4f4f4e1f9e]
/lib64/libqpid-proton.so.2(pn_error_format+0x82)[0x7f4f4f4e2032]
/lib64/libqpid-proton.so.2(pn_i_error_from_errno+0x67)[0x7f4f4f4fd737]
/lib64/libqpid-proton.so.2(pn_recv+0x5a)[0x7f4f4f4fd16a]
/home/mick/dispatch/install/lib64/libqpid-dispatch.so.0(qdpn_connector_process+0xd7)[0x7f4f4f759430]
The backtrace from the core file looks like this:
#0 0x003e3d835877 in raise () from /lib64/libc.so.6
#1 0x003e3d836f68 in abort () from /lib64/libc.so.6
#2 0x003e3d875a54 in __libc_message () from /lib64/libc.so.6
#3 0x003e3d87cd78 in _int_free () from /lib64/libc.so.6
#4 0x7fbf8a59b2e8 in pn_error_clear (error=error@entry=0x1501140)
at /home/mick/rh-qpid-proton/proton-c/src/error.c:56
#5 0x7fbf8a59b311 in pn_error_set (error=error@entry=0x1501140,
code=code@entry=-2,
text=text@entry=0x7fbf801a69c0 recv: Resource temporarily unavailable)
at /home/mick/rh-qpid-proton/proton-c/src/error.c:65
#6 0x7fbf8a59b36e in pn_error_vformat (error=0x1501140, code=-2,
fmt=optimized out,
ap=ap@entry=0x7fbf801a6de8) at
/home/mick/rh-qpid-proton/proton-c/src/error.c:81
#7 0x7fbf8a59b402 in pn_error_format (error=error@entry=0x1501140,
code=optimized out,
fmt=fmt@entry=0x7fbf8a5bb21e %s: %s) at
/home/mick/rh-qpid-proton/proton-c/src/error.c:89
#8 0x7fbf8a5b6797 in pn_i_error_from_errno (error=0x1501140,
msg=msg@entry=0x7fbf8a5bbe1a recv)
at /home/mick/rh-qpid-proton/proton-c/src/platform.c:119
#9 0x7fbf8a5b61ca in pn_recv (io=0x14e77b0, socket=optimized out,
buf=optimized out,
size=optimized out) at
/home/mick/rh-qpid-proton/proton-c/src/posix/io.c:271
#10 0x7fbf8a812430 in qdpn_connector_process (c=0x7fbf7801c7f0)
-
And I can prevent the crash from happening, apparently forever, by commenting
out this line:
free(error-text);
in the function pn_error_clear
in the file proton-c/src/error.c
The error text that is being freed which causes the crash looks like this:
$2 = {text = 0x7f66e8104e30 recv: Resource temporarily unavailable, root
= 0x0, code = -2}
My dispatch test creates a router network and then repeatedly kills and
restarts a randomly-selected router. After this proton checkin it almost
never gets through 5 iterations without this crash. After I commented out
that line, it got through more than 500 iterations before I stopped it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: AMQP 1.0 session outgoing-window usage / meaning
On 07/07/2015 07:22 AM, Rafael Schloming wrote: IIRC, the definition of the outgoing-window was largely motivated by the need to express to receivers certain conditions under which they may be required to settle deliveries in order to receive more. For example if an implementation uses a fixed sized array to store deliveries, and this array is keyed by the offset of the delivery-id from the smallest unsettled delivery, then although the sender may have sufficient credit to send more transfers, it may not actually be capable of doing this because the next delivery-id would land outside the range of deliveries that are currently represented within its fixed size array. The outgoing-window is measured in transfers, right? So in this case each slot in the array would be a *transfer* with a single delivery possibly spanning multiple slots. This could happen for example if the receiver issues N credits (where N is the size of the sender's fixed array) and settles deliveries 2 through N. The sender is then stuck with an unsettled delivery in the first slot of its fixed sized array and cannot send another delivery until that first delivery is settled. Given this, it's certainly true an outgoing-window of 0 is kind of strange and useless. Isn't that exactly the mechanism by which a sender, such as the one in your description above, would indicate its inability to send further transfers? It's probably also true that it is never super useful for the incoming window of the receiver to be larger than the outgoing window of the sender (or vice versa) since one can't ever exceed the other, so I'd say your largest-possible-int default and max-frame-like treatment are fairly appropriate.
Re: AMQP 1.0 session outgoing-window usage / meaning
On Tue, Jul 7, 2015 at 4:29 AM, Gordon Sim g...@redhat.com wrote: On 07/07/2015 07:22 AM, Rafael Schloming wrote: IIRC, the definition of the outgoing-window was largely motivated by the need to express to receivers certain conditions under which they may be required to settle deliveries in order to receive more. For example if an implementation uses a fixed sized array to store deliveries, and this array is keyed by the offset of the delivery-id from the smallest unsettled delivery, then although the sender may have sufficient credit to send more transfers, it may not actually be capable of doing this because the next delivery-id would land outside the range of deliveries that are currently represented within its fixed size array. The outgoing-window is measured in transfers, right? So in this case each slot in the array would be a *transfer* with a single delivery possibly spanning multiple slots. Yes, good point. This could happen for example if the receiver issues N credits (where N is the size of the sender's fixed array) and settles deliveries 2 through N. The sender is then stuck with an unsettled delivery in the first slot of its fixed sized array and cannot send another delivery until that first delivery is settled. Given this, it's certainly true an outgoing-window of 0 is kind of strange and useless. Isn't that exactly the mechanism by which a sender, such as the one in your description above, would indicate its inability to send further transfers? Gah, sorry, jet lag... you are right. I was thinking of the window measured from the oldest unsettled transfers, however it is actually measured from the next-outgoing-id, and so as you say a value of zero is actually what signals that the receiver needs to take some action here, and arguably an initial value of zero is correct since it is signaling that the receiver needs to take action (in this case issue credit). --Rafael
[jira] [Commented] (PROTON-826) recent checkin causes frequent double-free or corruption crash
[
https://issues.apache.org/jira/browse/PROTON-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14616749#comment-14616749
]
michael goulish commented on PROTON-826:
I see why I didn't follow this up earlier.
Current dispatch will not compile against latest proton because of some SASL
issues.
But I need to test against latest proton.
SO ... now attempting to hack up dispatch so that it doesn't have SASL but will
still build and run against latest proton
recent checkin causes frequent double-free or corruption crash
--
Key: PROTON-826
URL: https://issues.apache.org/jira/browse/PROTON-826
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Reporter: michael goulish
Assignee: michael goulish
Priority: Blocker
In my dispatch testing I am seeing frequent crashes in proton library that
began with proton checkin 01cb00c on 2015-02-15 report read and write
errors through the transport
The output at crash-time says this:
---
*** Error in `/home/mick/dispatch/install/sbin/qdrouterd': double free or
corruption (fasttop): 0x020ee880 ***
=== Backtrace: =
/lib64/libc.so.6[0x3e3d875a4f]
/lib64/libc.so.6[0x3e3d87cd78]
/lib64/libqpid-proton.so.2(pn_error_clear+0x18)[0x7f4f4f4e1f18]
/lib64/libqpid-proton.so.2(pn_error_set+0x11)[0x7f4f4f4e1f41]
/lib64/libqpid-proton.so.2(pn_error_vformat+0x3e)[0x7f4f4f4e1f9e]
/lib64/libqpid-proton.so.2(pn_error_format+0x82)[0x7f4f4f4e2032]
/lib64/libqpid-proton.so.2(pn_i_error_from_errno+0x67)[0x7f4f4f4fd737]
/lib64/libqpid-proton.so.2(pn_recv+0x5a)[0x7f4f4f4fd16a]
/home/mick/dispatch/install/lib64/libqpid-dispatch.so.0(qdpn_connector_process+0xd7)[0x7f4f4f759430]
The backtrace from the core file looks like this:
#0 0x003e3d835877 in raise () from /lib64/libc.so.6
#1 0x003e3d836f68 in abort () from /lib64/libc.so.6
#2 0x003e3d875a54 in __libc_message () from /lib64/libc.so.6
#3 0x003e3d87cd78 in _int_free () from /lib64/libc.so.6
#4 0x7fbf8a59b2e8 in pn_error_clear (error=error@entry=0x1501140)
at /home/mick/rh-qpid-proton/proton-c/src/error.c:56
#5 0x7fbf8a59b311 in pn_error_set (error=error@entry=0x1501140,
code=code@entry=-2,
text=text@entry=0x7fbf801a69c0 recv: Resource temporarily unavailable)
at /home/mick/rh-qpid-proton/proton-c/src/error.c:65
#6 0x7fbf8a59b36e in pn_error_vformat (error=0x1501140, code=-2,
fmt=optimized out,
ap=ap@entry=0x7fbf801a6de8) at
/home/mick/rh-qpid-proton/proton-c/src/error.c:81
#7 0x7fbf8a59b402 in pn_error_format (error=error@entry=0x1501140,
code=optimized out,
fmt=fmt@entry=0x7fbf8a5bb21e %s: %s) at
/home/mick/rh-qpid-proton/proton-c/src/error.c:89
#8 0x7fbf8a5b6797 in pn_i_error_from_errno (error=0x1501140,
msg=msg@entry=0x7fbf8a5bbe1a recv)
at /home/mick/rh-qpid-proton/proton-c/src/platform.c:119
#9 0x7fbf8a5b61ca in pn_recv (io=0x14e77b0, socket=optimized out,
buf=optimized out,
size=optimized out) at
/home/mick/rh-qpid-proton/proton-c/src/posix/io.c:271
#10 0x7fbf8a812430 in qdpn_connector_process (c=0x7fbf7801c7f0)
-
And I can prevent the crash from happening, apparently forever, by commenting
out this line:
free(error-text);
in the function pn_error_clear
in the file proton-c/src/error.c
The error text that is being freed which causes the crash looks like this:
$2 = {text = 0x7f66e8104e30 recv: Resource temporarily unavailable, root
= 0x0, code = -2}
My dispatch test creates a router network and then repeatedly kills and
restarts a randomly-selected router. After this proton checkin it almost
never gets through 5 iterations without this crash. After I commented out
that line, it got through more than 500 iterations before I stopped it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] qpid-proton pull request: PROTON-936 session outgoing window handl...
GitHub user gemmellr opened a pull request: https://github.com/apache/qpid-proton/pull/42 PROTON-936 session outgoing window handling As discussed on the mailing lists [1], proton currently sets the outgoing window to 0 in most cases (except when using Messenger), but then sends messages anyway if allowed by the current remote-outgoing-window. This means it is typically violating the advertised window. Additionally, Service Bus uses the outgoing window to initialise its incoming window, which means it is set to 0 and we can never send it any messages. This is an initial attempt at an update based on the discussions. It sets the outgoing window to a fixed default value of max int, and adds a setter to allow users of the engine to adjust it. Mainly looking for feedback on the approach and whether I have committed any atrocities on the C/python side, as I basically cut and paste all of those changes after grep'ing use of other fields/methods. There is a basic test that the default exists and the getter+setter work, but that is all as we dont actually use the [remote] outgoing window for anything in proton currently so seems to be no way to inspect things. [1] http://mail-archives.apache.org/mod_mbox/qpid-users/201507.mbox/%3CCAFitrpQoK8SFgd1xXPtc9PeNWwWcEqtJgN8ZN88RBj3u6fwdag%40mail.gmail.com%3E You can merge this pull request into a Git repository by running: $ git pull https://github.com/gemmellr/qpid-proton PROTON-936_session_window Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/42.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #42 commit d7499a11b0aa6b73f85517c03fe2af18a50b77cc Author: Robert Gemmell rob...@apache.org Date: 2015-07-07T10:17:58Z PROTON-936: make session outgoing window size configurable, default to max int commit 808e99c865df6d94b15d3b9e78223bd46cd95e04 Author: Robert Gemmell rob...@apache.org Date: 2015-07-07T11:00:14Z PROTON-936: initial cp attempt at adding configurable session outgoing window to proton-c commit 33d69fc6a14948fbfcd46e080ffc0bd878e44bc4 Author: Robert Gemmell rob...@apache.org Date: 2015-07-07T13:02:23Z PROTON-936: add a basic python test of the get/set methods --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: 0.10 alpha1
I added https://issues.apache.org/jira/browse/PROTON-935 as a blocker. We need to either drop Java 6 or fix compilation. I also added https://issues.apache.org/jira/browse/PROTON-936 for the session outgoing window stuff, with some initial changes for discussion on https://github.com/apache/qpid-proton/pull/42 Robbie On 7 July 2015 at 13:26, Ken Giusti kgiu...@redhat.com wrote: Yay Rafi! Thanks! A simple query of currently outstanding blocker JIRAs affecting 0.9+ shows only three: https://issues.apache.org/jira/browse/PROTON-826 (unassigned) https://issues.apache.org/jira/browse/PROTON-923 (asticher) https://issues.apache.org/jira/browse/PROTON-934 (rschloming) The remaining open bugs affecting 0.9+ are: https://issues.apache.org/jira/browse/PROTON-826?jql=project%20%3D%20PROTON%20AND%20status%20in%20%28Open%2C%20%22In%20Progress%22%2C%20Reopened%29%20AND%20affectedVersion%20in%20%280.9%2C%200.9.1%2C%200.10%29%20ORDER%20BY%20priority%20DESC - Original Message - From: Rafael Schloming r...@alum.mit.edu To: proton@qpid.apache.org Sent: Tuesday, July 7, 2015 1:28:17 AM Subject: 0.10 alpha1 As promised, here is the first alpha for 0.10. It's posted in the usual places: Source code is here: http://people.apache.org/~rhs/qpid-proton-0.10-alpha1/ Java binaries are here: https://repository.apache.org/content/repositories/orgapacheqpid-1036 Please check it out and follow up with any issues. --Rafael -- -K
[jira] [Created] (PROTON-935) proton-j compilation failure
Robbie Gemmell created PROTON-935:
-
Summary: proton-j compilation failure
Key: PROTON-935
URL: https://issues.apache.org/jira/browse/PROTON-935
Project: Qpid Proton
Issue Type: Bug
Components: proton-j
Affects Versions: 0.10
Reporter: Robbie Gemmell
Priority: Blocker
Fix For: 0.10
The build is currently failing in CI following recent changes for PROTON-881,
because it no longer compiles on Java 6 which is the current compiler
source/target for proton-j.
We need to either decide to drop Java 6 support at long last (Java 7 already
being EOL), or update it to actually compile.
{noformat}
[ERROR]
/home/jenkins/jenkins-slave/workspace/Qpid-proton-j/proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/AcceptorImpl.java:[95,11]
cannot find symbol
symbol : method bind(java.net.InetSocketAddress)
location: class java.nio.channels.ServerSocketChannel
[ERROR]
/home/jenkins/jenkins-slave/workspace/Qpid-proton-j/proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/AcceptorImpl.java:[125,38]
cannot find symbol
symbol : method getLocalAddress()
location: class java.nio.channels.ServerSocketChannel
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-881) Proton-j reactor implementation
[ https://issues.apache.org/jira/browse/PROTON-881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-881: -- Issue Type: New Feature (was: Improvement) Proton-j reactor implementation --- Key: PROTON-881 URL: https://issues.apache.org/jira/browse/PROTON-881 Project: Qpid Proton Issue Type: New Feature Components: proton-j Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor Fix For: 0.10 To keep the proton-j codebase consistent with proton-c - there should be a native Java port of the reactor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-936) update session outgoing window handling
[ https://issues.apache.org/jira/browse/PROTON-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14616762#comment-14616762 ] ASF GitHub Bot commented on PROTON-936: --- GitHub user gemmellr opened a pull request: https://github.com/apache/qpid-proton/pull/42 PROTON-936 session outgoing window handling As discussed on the mailing lists [1], proton currently sets the outgoing window to 0 in most cases (except when using Messenger), but then sends messages anyway if allowed by the current remote-outgoing-window. This means it is typically violating the advertised window. Additionally, Service Bus uses the outgoing window to initialise its incoming window, which means it is set to 0 and we can never send it any messages. This is an initial attempt at an update based on the discussions. It sets the outgoing window to a fixed default value of max int, and adds a setter to allow users of the engine to adjust it. Mainly looking for feedback on the approach and whether I have committed any atrocities on the C/python side, as I basically cut and paste all of those changes after grep'ing use of other fields/methods. There is a basic test that the default exists and the getter+setter work, but that is all as we dont actually use the [remote] outgoing window for anything in proton currently so seems to be no way to inspect things. [1] http://mail-archives.apache.org/mod_mbox/qpid-users/201507.mbox/%3CCAFitrpQoK8SFgd1xXPtc9PeNWwWcEqtJgN8ZN88RBj3u6fwdag%40mail.gmail.com%3E You can merge this pull request into a Git repository by running: $ git pull https://github.com/gemmellr/qpid-proton PROTON-936_session_window Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/42.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #42 commit d7499a11b0aa6b73f85517c03fe2af18a50b77cc Author: Robert Gemmell rob...@apache.org Date: 2015-07-07T10:17:58Z PROTON-936: make session outgoing window size configurable, default to max int commit 808e99c865df6d94b15d3b9e78223bd46cd95e04 Author: Robert Gemmell rob...@apache.org Date: 2015-07-07T11:00:14Z PROTON-936: initial cp attempt at adding configurable session outgoing window to proton-c commit 33d69fc6a14948fbfcd46e080ffc0bd878e44bc4 Author: Robert Gemmell rob...@apache.org Date: 2015-07-07T13:02:23Z PROTON-936: add a basic python test of the get/set methods update session outgoing window handling --- Key: PROTON-936 URL: https://issues.apache.org/jira/browse/PROTON-936 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.9.1 Reporter: Robbie Gemmell Priority: Critical Fix For: 0.10 As discussed on the mailing lists \[1\], proton currently sets the outgoing window to 0 in most cases (except when using Messenger), but then sends messages anyway if allowed by the current remote-outgoing-window. This means it is typically violating the advertised window. Additionall, Service Bus uses the outgoing window to initialise its incoming window, which means it is set to 0 and we can never send it any messages. We should update the outgoing window to address these issues. \[1\] http://mail-archives.apache.org/mod_mbox/qpid-users/201507.mbox/%3CCAFitrpQoK8SFgd1xXPtc9PeNWwWcEqtJgN8ZN88RBj3u6fwdag%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-881) Proton-j reactor implementation
[ https://issues.apache.org/jira/browse/PROTON-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14616697#comment-14616697 ] Robbie Gemmell commented on PROTON-881: --- Linking to PROTON-935 Proton-j reactor implementation --- Key: PROTON-881 URL: https://issues.apache.org/jira/browse/PROTON-881 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor Fix For: 0.10 To keep the proton-j codebase consistent with proton-c - there should be a native Java port of the reactor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-881) Proton-j reactor implementation
[ https://issues.apache.org/jira/browse/PROTON-881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-881: -- Fix Version/s: 0.10 Proton-j reactor implementation --- Key: PROTON-881 URL: https://issues.apache.org/jira/browse/PROTON-881 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor Fix For: 0.10 To keep the proton-j codebase consistent with proton-c - there should be a native Java port of the reactor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-936) update session outgoing window handling
Robbie Gemmell created PROTON-936: - Summary: update session outgoing window handling Key: PROTON-936 URL: https://issues.apache.org/jira/browse/PROTON-936 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.9.1, 0.9, 0.8, 0.7, 0.6, 0.5, 0.4, 0.3, 0.2, 0.1 Reporter: Robbie Gemmell Priority: Critical Fix For: 0.10 As discussed on the mailing lists \[1\], proton currently sets the outgoing window to 0 in most cases (except when using Messenger), but then sends messages anyway if allowed by the current remote-outgoing-window. This means it is typically violating the advertised window. Additionall, Service Bus uses the outgoing window to initialise its incoming window, which means it is set to 0 and we can never send it any messages. We should update the outgoing window to address these issues. \[1\] http://mail-archives.apache.org/mod_mbox/qpid-users/201507.mbox/%3CCAFitrpQoK8SFgd1xXPtc9PeNWwWcEqtJgN8ZN88RBj3u6fwdag%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: AMQP 1.0 session outgoing-window usage / meaning
On 7 July 2015 at 07:22, Rafael Schloming r...@alum.mit.edu wrote: IIRC, the definition of the outgoing-window was largely motivated by the need to express to receivers certain conditions under which they may be required to settle deliveries in order to receive more. For example if an implementation uses a fixed sized array to store deliveries, and this array is keyed by the offset of the delivery-id from the smallest unsettled delivery, then although the sender may have sufficient credit to send more transfers, it may not actually be capable of doing this because the next delivery-id would land outside the range of deliveries that are currently represented within its fixed size array. This could happen for example if the receiver issues N credits (where N is the size of the sender's fixed array) and settles deliveries 2 through N. The sender is then stuck with an unsettled delivery in the first slot of its fixed sized array and cannot send another delivery until that first delivery is settled. I see. I assume things above are slightly simplified by considering a session with a single sending link and, to Gordons point, only using messages with a single transfer frame given link credit and session window handling actually use different units (which actually seems like it might pose an issue in certain cases) Given this, it's certainly true an outgoing-window of 0 is kind of strange and useless. It's probably also true that it is never super useful for the incoming window of the receiver to be larger than the outgoing window of the sender (or vice versa) since one can't ever exceed the other, so I'd say your largest-possible-int default and max-frame-like treatment are fairly appropriate. --Rafael I added https://issues.apache.org/jira/browse/PROTON-936 for this, with some initial changes for discussion on https://github.com/apache/qpid-proton/pull/42 (The earlier change I suggested for proton-j which only changed the behviour if the new setter was used is still at https://github.com/gemmellr/qpid-proton/commit/b2b15a617b42bd36eacf9b51fb146223ba516496 though that might get garbase collected at some point as I rebased the repo and orphaned it) On Fri, Jul 3, 2015 at 8:57 AM, Robbie Gemmell robbie.gemm...@gmail.com wrote: Rob, Rafi, as authors of the spec and the related code in proton, do you have any thoughts to add here? Barring any discussion otherwise I will be looking to change proton to at least optionally allow controlling the outgoing window along the lines I mentioned near the end of my original mail. Robbie On 2 July 2015 at 00:15, Robbie Gemmell robbie.gemm...@gmail.com wrote: Thanks James. Some expansion which may be useful to add. When comparing the older JMS client, proton-c via the Messenger API, and the new JMS client using proton-j, its important to note that they aren't all doing the same thing even where their underlying implementations do seem to share the same behaviour in the cases of proton-c and proton-j. The older JMS client initializes its outgoing window to a fixed number in the session Begin frame and then doesnt seem to ever change it for subsequent Flow frames, and simply manages whether its session can later send transfer frames based on the current value of the remote incoming window. Proton-J and Proton-C similarly only base their session level decision to send transfers on the remote incoming window and not their own outgoing window (which as noted below means they violate their advertised outgoing window, which is often going to be 0). Proton-C and Proton-J both currently look to set the outgoing window at any given time to a calculated value based on either the number of buffered messages or the buffered bytes divided by frame size. If there are no buffered messages at the point the Begin and Flow frames are generated, then the outgoing-window will be set to 0. This appears to function the same for both proton-c and proton-j. A key point though is that I think much of the historic usage of proton-c against Service Bus has been via the Messenger API, which works somewhat differently than many others in that it looks to create a session and a sender and sends the messages in one pipelined sequence of transport output, which means that by the point the Begin frame actually gets generated there are indeed buffered messages to send which means the outgoing-window is initialised to a value greater than zero. Other APIs which create the session as a distinct step thus wont ever have buffered messages when the Begin frame gets created and so the outgoing-window is initialised to 0, which is the behaviour observed with the new JMS client using proton-j and also what I saw when trying proton-c via the Qpid Messaging C++ client (against qpidd). Robbie On 1 July 2015 at 20:54, James Birdsall jb...@microsoft.com wrote: FYI, I have forwarded this and important
[GitHub] qpid-proton pull request: Fix 2 Code Analysis warnings and a reall...
Github user astitcher commented on the pull request: https://github.com/apache/qpid-proton/pull/39#issuecomment-119227983 @dcristoloveanu - Sorry not to reply to your comments - for some reason I got no email to tell me you had commented. * If you change the PR I'll be happy to merge it. * I was peripherally aware that some coding standards require single return points. And if you'd pressed me I might have guessed the MISRA standard. I do agree with the rationale, however I think it is just guidance, and as professionals we are supposed to use our best judgement. In this and similar cases I think that the single return actually makes the code harder to read and therefore maintain. So even in coding to this standard I'd argue that in these cases early exit is better. * I think you may be misinterpreting the idea of exception like semantics. I'm not suggesting that the entire program abort (I'm not sure why exception would indicate that). In all the language that I'm familiar with exception indicates a non-local flow of control which avoids having to deal with bad consequences in a place that probably doesn't have the global knowledge to do this. Think of C++, Java, Python, C#, F#, etc. exceptions. However it is most likely true that if you run out of memory in the context of Proton then the current connection can not continue. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
