[jira] [Assigned] (PROTON-225) Redesign Transport interface such that Transport owns the in/out buffers rather than its client
[ https://issues.apache.org/jira/browse/PROTON-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-225: - Assignee: Ken Giusti > Redesign Transport interface such that Transport owns the in/out buffers > rather than its client > --- > > Key: PROTON-225 > URL: https://issues.apache.org/jira/browse/PROTON-225 > Project: Qpid Proton > Issue Type: Improvement >Affects Versions: 0.3 >Reporter: Philip Harvey >Assignee: Ken Giusti > Fix For: 0.5 > > > This issue is intended to cover the Transport API redesign proposed on the > mailing list > (http://qpid.2158936.n2.nabble.com/transport-interface-changes-td7588099.html) > as part of discussions around PROTON-222. The redesign is being tracked > under this new because we probably want to implement it on a different > timescale to the PROTON-222 bug fix. -- 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] [Assigned] (PROTON-223) Need system-level and soak tests to exercise Proton.
[ https://issues.apache.org/jira/browse/PROTON-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-223: - Assignee: Ken Giusti > Need system-level and soak tests to exercise Proton. > > > Key: PROTON-223 > URL: https://issues.apache.org/jira/browse/PROTON-223 > Project: Qpid Proton > Issue Type: Test > Components: proton-c, proton-j >Reporter: Ken Giusti >Assignee: Ken Giusti > Labels: performance, system-tests,, testing, > Attachments: proton-test.txt > > > The existing system tests for QPID are, naturally, tests of a > broker-centric model. Since AMQP 1.0 allows for messaging models that > go beyond the simple broker-based approach, we need a system test bed > that can do the same. This would include support for testing > peer-to-peer patterns, as well as testing distributed messaging > systems yet to be defined. -- 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] [Assigned] (PROTON-109) Proton should handle inbound max-frame size violations.
[ https://issues.apache.org/jira/browse/PROTON-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-109: - Assignee: Ken Giusti > Proton should handle inbound max-frame size violations. > --- > > Key: PROTON-109 > URL: https://issues.apache.org/jira/browse/PROTON-109 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, proton-j >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.5 > > > According to the spec, if the local proton-c client has configured a maximum > frame size, and the remote attempts to send a frame that violates that size: > A peer that receives an oversized frame MUST close the Connection with the > framing-error error-code. > Need to verify this behavior is handled. -- 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-222) pn_messenger_send returns before message data has been written to the wire
[
https://issues.apache.org/jira/browse/PROTON-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13576893#comment-13576893
]
michael goulish commented on PROTON-222:
I am able to get my example working the way I want to by using a tracker, with
window size 1, on the sender, and calling pn_messenger_status() after every
message sent.
new code:
sender
=
#include "proton/message.h"
#include "proton/messenger.h"
#include
#include
#include
int
main(int argc, char** argv)
{
int c;
opterr = 0;
char addr [ 1000 ];
char content [ 1000 ];
char subject [ 1000 ];
sprintf ( addr, "amqp://0.0.0.0:%s", argv[1] );
pn_message_t * message;
pn_messenger_t * messenger;
message = pn_message();
messenger = pn_messenger(NULL);
pn_messenger_set_outgoing_window ( messenger, 1 );
pn_messenger_start(messenger);
int n_messages = 10;
int sent_count;
/*--
Put and send a message every 1 second.
--*/
for ( sent_count = 0 ; sent_count < n_messages; ++ sent_count )
{
sleep ( 1 );
sprintf ( subject, "This is message %d.", sent_count + 1 );
pn_message_set_address ( message, addr );
pn_message_set_subject ( message, subject );
pn_data_t *body = pn_message_body(message);
sprintf ( content, "Hello, Proton!" );
pn_data_put_string(body, pn_bytes(strlen(content), content));
pn_messenger_put(messenger, message);
pn_tracker_t tracker;
tracker = pn_messenger_outgoing_tracker ( messenger );
pn_messenger_send(messenger);
pn_messenger_status ( messenger, tracker );
fprintf ( stderr, "sent %d messages.\n", sent_count + 1 );
}
// Countdown to stop, to give me time to see it
fprintf ( stderr, "Calling stop in ...\n" );
for ( int i = 5; i > 0; -- i )
{
fprintf ( stderr, "%d\n", i );
sleep ( 1 );
}
fprintf ( stderr, "stop.\n");
pn_messenger_stop(messenger);
pn_messenger_free(messenger);
pn_message_free(message);
return 0;
}
= receiver
=
#include "proton/message.h"
#include "proton/messenger.h"
#include
#include
#include
#define BUFSIZE 1024
void
consume_messages ( pn_messenger_t * messenger, int n, pn_message_t * message )
{
for ( int consume_count = 0; consume_count < n; ++ consume_count )
{
pn_messenger_get ( messenger, message );
size_t bufsize = BUFSIZE;
char buffer [ bufsize ];
pn_data_t * body = pn_message_body ( message );
pn_data_format ( body, buffer, & bufsize );
printf ( "\n\nMessage \n");
printf ( "Address: %s\n", pn_message_get_address ( message ) );
char const * subject = pn_message_get_subject(message);
printf ( "Subject: %s\n", subject ? subject : "(no subject)" );
printf("Content: %s\n\n", buffer);
}
}
int
main(int argc, char** argv)
{
char addr [ 1000 ];
sprintf ( addr, "amqp://~0.0.0.0:%s", argv[1] );
pn_message_t * message;
pn_messenger_t * messenger;
message = pn_message();
messenger = pn_messenger ( NULL );
pn_messenger_start(messenger);
pn_messenger_subscribe ( messenger, addr );
int messages_wanted= 10;
int total_received = 0;
int received_this_time;
pn_messenger_set_timeout ( messenger, 700 );
int tries = 0;
while ( total_received < messages_wanted )
{
++ tries;
pn_messenger_recv ( messenger, BUFSIZE );
received_this_time = pn_messenger_incoming ( messenger );
fprintf ( stderr,
"try: %d received: %d total: %d\n",
tries,
received_this_time,
total_received
);
consume_messages ( messenger, received_this_time, message );
total_received += received_this_time;
}
pn_messenger_stop(messenger);
pn_messenger_free(messenger);
return 0;
}
> pn_messenger_send returns before message data has been written to the wire
> --
>
> Key: PROTON-222
> URL: https://issues.apache.org/jira/browse/PROTON-222
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, proton-j
>Affects Versions: 0.3
>Reporter: Rafael H. Schloming
>Assignee: Ken Giusti
> Fix For: 0.4
>
> Attachments: transport.patch
>
>
> Currently, pn_messender_send will block until the engine reports there are no
> queued messages being held. The problem arises because the queued message
> count only reports message data that is being held by the engine due to
> insufficient credit to send the messages. Messages may also be sitting in the
> transport's encoded frame buf
[jira] [Commented] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13576842#comment-13576842 ] Mary hinton commented on PROTON-236: Not sure if the getopt should be included in the proton executable project or in the Visual Studio qpid-proton dll. I made a few changes in the getopt code for Visual Studio. > Porting Issue -- Visual Studio does not provide a getopt() function > --- > > Key: PROTON-236 > URL: https://issues.apache.org/jira/browse/PROTON-236 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Fix For: 0.4 > > Attachments: getopt.c, getopt.h > > > Since Visual Studio 2010 does not provide a getopt(), I used the getopt() > function found in the GNU library getopt.h and getopt.c. I made a few minor > changes and will attach these files to this JIRA. > Besides the proton.c file, the proton project workspace for Visual Studio > would need to include getopt() files. -- 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-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mary hinton updated PROTON-236: --- Attachment: getopt.h > Porting Issue -- Visual Studio does not provide a getopt() function > --- > > Key: PROTON-236 > URL: https://issues.apache.org/jira/browse/PROTON-236 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Fix For: 0.4 > > Attachments: getopt.c, getopt.h > > > Since Visual Studio 2010 does not provide a getopt(), I used the getopt() > function found in the GNU library getopt.h and getopt.c. I made a few minor > changes and will attach these files to this JIRA. > Besides the proton.c file, the proton project workspace for Visual Studio > would need to include getopt() files. -- 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-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mary hinton updated PROTON-236: --- Attachment: getopt.c > Porting Issue -- Visual Studio does not provide a getopt() function > --- > > Key: PROTON-236 > URL: https://issues.apache.org/jira/browse/PROTON-236 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Fix For: 0.4 > > Attachments: getopt.c > > > Since Visual Studio 2010 does not provide a getopt(), I used the getopt() > function found in the GNU library getopt.h and getopt.c. I made a few minor > changes and will attach these files to this JIRA. > Besides the proton.c file, the proton project workspace for Visual Studio > would need to include getopt() files. -- 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-222) pn_messenger_send returns before message data has been written to the wire
[
https://issues.apache.org/jira/browse/PROTON-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13576830#comment-13576830
]
michael goulish commented on PROTON-222:
Here is some sample code that demonstrates this bug, and possibly clarifies how
it can show up.
Running the receiver and sender in separate windows, I can see that the
receiver does not get anything after ten calls (on the sender) to send().
It is only when the sender finally calls stop() that the receiver gets all ten
messages at once.
= sender
===
#include "proton/message.h"
#include "proton/messenger.h"
#include
#include
#include
int
main(int argc, char** argv)
{
int c;
opterr = 0;
char addr [ 1000 ];
char content [ 1000 ];
char subject [ 1000 ];
sprintf ( addr, "amqp://0.0.0.0:%s", argv[1] );
pn_message_t * message;
pn_messenger_t * messenger;
message = pn_message();
messenger = pn_messenger(NULL);
pn_messenger_start(messenger);
int n_messages = 10;
int sent_count;
/*--
Put and send a message every 1 second.
--*/
for ( sent_count = 0 ; sent_count < n_messages; ++ sent_count )
{
sleep ( 1 );
sprintf ( subject, "This is message %d.", sent_count + 1 );
pn_message_set_address ( message, addr );
pn_message_set_subject ( message, subject );
pn_data_t *body = pn_message_body(message);
sprintf ( content, "Hello, Proton!" );
pn_data_put_string(body, pn_bytes(strlen(content), content));
pn_messenger_put(messenger, message);
pn_messenger_send(messenger);
fprintf ( stderr, "sent %d messages.\n", sent_count + 1 );
}
// Countdown to stop, to give me time to see it
fprintf ( stderr, "Calling stop in ...\n" );
for ( int i = 5; i > 0; -- i )
{
fprintf ( stderr, "%d\n", i );
sleep ( 1 );
}
pn_messenger_stop(messenger);
pn_messenger_free(messenger);
pn_message_free(message);
return 0;
}
== receiver
===
#include "proton/message.h"
#include "proton/messenger.h"
#include
#include
#include
#define BUFSIZE 1024
int
main(int argc, char** argv)
{
char addr [ 1000 ];
sprintf ( addr, "amqp://~0.0.0.0:%s", argv[1] );
pn_message_t * message;
pn_messenger_t * messenger;
message = pn_message();
messenger = pn_messenger ( NULL );
pn_messenger_start(messenger);
pn_messenger_subscribe ( messenger, addr );
int messages_wanted= 10;
int total_received = 0;
int received_this_time;
pn_messenger_set_timeout ( messenger, 700 );
int tries = 0;
while ( total_received < messages_wanted )
{
++ tries;
pn_messenger_recv ( messenger, BUFSIZE );
received_this_time = pn_messenger_incoming ( messenger );
fprintf ( stderr,
"try: %d received: %d total: %d\n",
tries,
received_this_time,
total_received
);
total_received += received_this_time;
}
int total_consumed = 0;
for ( ; total_consumed < total_received; ++ total_consumed )
{
pn_messenger_get ( messenger, message );
size_t bufsize = BUFSIZE;
char buffer [ bufsize ];
pn_data_t * body = pn_message_body ( message );
pn_data_format ( body, buffer, & bufsize );
printf ( "\n\nMessage %d \n", total_consumed +
1 );
printf ( "Address: %s\n", pn_message_get_address ( message ) );
char const * subject = pn_message_get_subject(message);
printf ( "Subject: %s\n", subject ? subject : "(no subject)" );
printf("Content: %s\n", buffer);
}
printf ( "\n\n" );
pn_messenger_stop(messenger);
pn_messenger_free(messenger);
return 0;
}
> pn_messenger_send returns before message data has been written to the wire
> --
>
> Key: PROTON-222
> URL: https://issues.apache.org/jira/browse/PROTON-222
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, proton-j
>Affects Versions: 0.3
>Reporter: Rafael H. Schloming
>Assignee: Ken Giusti
> Fix For: 0.4
>
> Attachments: transport.patch
>
>
> Currently, pn_messender_send will block until the engine reports there are no
> queued messages being held. The problem arises because the queued message
> count only reports message data that is being held by the engine due to
> insufficient credit to send the messages. Messages may also be sitting in the
> transport's encoded frame buffer waiting to be written to the wire, and
> messages may also be held by the driver itself. This latter possibly is
> problematic given th
[jira] [Created] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
Mary hinton created PROTON-236: -- Summary: Porting Issue -- Visual Studio does not provide a getopt() function Key: PROTON-236 URL: https://issues.apache.org/jira/browse/PROTON-236 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Fix For: 0.4 Since Visual Studio 2010 does not provide a getopt(), I used the getopt() function found in the GNU library getopt.h and getopt.c. I made a few minor changes and will attach these files to this JIRA. Besides the proton.c file, the proton project workspace for Visual Studio would need to include getopt() files. -- 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-235) SASL layer can "replicate" inbound SASL frames under some circumstances.
[
https://issues.apache.org/jira/browse/PROTON-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming updated PROTON-235:
---
Fix Version/s: 0.4
> SASL layer can "replicate" inbound SASL frames under some circumstances.
>
>
> Key: PROTON-235
> URL: https://issues.apache.org/jira/browse/PROTON-235
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.3
>Reporter: Ken Giusti
>Assignee: Ken Giusti
> Fix For: 0.4
>
>
> If an inbound SASL frame is fragmented, then the SASL layer incorrectly
> re-reads the same frame data. This causes the engine to fail.
> Reproducer:
> def testFracturedSASL(self):
> self.s1.mechanisms("ANONYMOUS")
> self.s1.client()
> self.t1.trace(Transport.TRACE_FRM)
> out = self.t1.output(1024)
> print("out=%s" % str(out))
> self.t1.input("AMQP\x03\x01\x00\x00")
> out = self.t1.output(1024)
> print("out=%s" % str(out))
> self.t1.input("\x00\x00\x00")
> out = self.t1.output(1024)
> print("out=%s" % str(out))
>
> self.t1.input("A\x02\x01\x00\x00\x00S@\xc04\x01\xe01\x06\xa3\x06GSSAPI\x05PLAIN\x0aDIGEST-MD5\x08AMQPLAIN\x08CRAM-MD5\x04NTLM")
> out = self.t1.output(1024)
> print("out=%s" % str(out))
> self.t1.input("\x00\x00\x00\x10\x02\x01\x00\x00\x00SD\xc0\x03\x01P\x00")
> out = self.t1.output(1024)
> while out:
> print("out=%s" % str(out))
> out = self.t1.output(1024)
> When tracing is turned on, SASL will report the following frames as received:
> <- SASL
> [0x200f0e0:0] <- SASL-MECHANISMS @64 [@PN_SYMBOL[:GSSAPI, :PLAIN,
> :"DIGEST-MD5", :AMQPLAIN, :"CRAM-MD5", :NTLM]]
> [0x200f0e0:0] <- SASL-MECHANISMS @64 [@PN_SYMBOL[:GSSAPI, :PLAIN,
> :"DIGEST-MD5", :AMQPLAIN, :"CRAM-MD5", :NTLM]]
> Notice the MECHANISM frame is reported as received twice by the SASL layer,
> but it was only read once from the network.
--
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-235) SASL layer can "replicate" inbound SASL frames under some circumstances.
Ken Giusti created PROTON-235:
-
Summary: SASL layer can "replicate" inbound SASL frames under some
circumstances.
Key: PROTON-235
URL: https://issues.apache.org/jira/browse/PROTON-235
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.3
Reporter: Ken Giusti
Assignee: Ken Giusti
If an inbound SASL frame is fragmented, then the SASL layer incorrectly
re-reads the same frame data. This causes the engine to fail.
Reproducer:
def testFracturedSASL(self):
self.s1.mechanisms("ANONYMOUS")
self.s1.client()
self.t1.trace(Transport.TRACE_FRM)
out = self.t1.output(1024)
print("out=%s" % str(out))
self.t1.input("AMQP\x03\x01\x00\x00")
out = self.t1.output(1024)
print("out=%s" % str(out))
self.t1.input("\x00\x00\x00")
out = self.t1.output(1024)
print("out=%s" % str(out))
self.t1.input("A\x02\x01\x00\x00\x00S@\xc04\x01\xe01\x06\xa3\x06GSSAPI\x05PLAIN\x0aDIGEST-MD5\x08AMQPLAIN\x08CRAM-MD5\x04NTLM")
out = self.t1.output(1024)
print("out=%s" % str(out))
self.t1.input("\x00\x00\x00\x10\x02\x01\x00\x00\x00SD\xc0\x03\x01P\x00")
out = self.t1.output(1024)
while out:
print("out=%s" % str(out))
out = self.t1.output(1024)
When tracing is turned on, SASL will report the following frames as received:
<- SASL
[0x200f0e0:0] <- SASL-MECHANISMS @64 [@PN_SYMBOL[:GSSAPI, :PLAIN,
:"DIGEST-MD5", :AMQPLAIN, :"CRAM-MD5", :NTLM]]
[0x200f0e0:0] <- SASL-MECHANISMS @64 [@PN_SYMBOL[:GSSAPI, :PLAIN,
:"DIGEST-MD5", :AMQPLAIN, :"CRAM-MD5", :NTLM]]
Notice the MECHANISM frame is reported as received twice by the SASL layer, but
it was only read once from the network.
--
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] [Comment Edited] (PROTON-234) Add lots of logging to better understand inner working of proton
[ https://issues.apache.org/jira/browse/PROTON-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13576611#comment-13576611 ] Bozo Dragojevic edited comment on PROTON-234 at 2/12/13 2:33 PM: - There is also a kind of followup set of patches that merge in all the other submitted fixes and improvements (PROTON-200, PROTON-230, PROTON-231, PROTON-233, PROTON-234) and adds logging to those places, too. https://github.com/ttlj/qpid-proton/commits/upstream-all was (Author: bozzo): There is also a kind of followup set of patches that merge in all the other submitted fixes and improvements and adds logging to those places, too. https://github.com/ttlj/qpid-proton/commits/upstream-all > Add lots of logging to better understand inner working of proton > > > Key: PROTON-234 > URL: https://issues.apache.org/jira/browse/PROTON-234 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Bozo Dragojevic > > Add lots of logging to proton to ease understnding of it's inner workings > Introduce object naming facility as some layers are coupled really loosely > for now the logging route will just dump everything out to stderr, as it was > before > This is currently one giant commit off 0.3: > https://github.com/ttlj/qpid-proton/commits/upstream-logging > It doesn't merge quite cleanly to trunk. If this is interesting thing to have > I'd be willing to merge or rebase whichever is preferred. -- 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-234) Add lots of logging to better understand inner working of proton
Bozo Dragojevic created PROTON-234: -- Summary: Add lots of logging to better understand inner working of proton Key: PROTON-234 URL: https://issues.apache.org/jira/browse/PROTON-234 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Bozo Dragojevic Add lots of logging to proton to ease understnding of it's inner workings Introduce object naming facility as some layers are coupled really loosely for now the logging route will just dump everything out to stderr, as it was before This is currently one giant commit off 0.3: https://github.com/ttlj/qpid-proton/commits/upstream-logging It doesn't merge quite cleanly to trunk. If this is interesting thing to have I'd be willing to merge or rebase whichever is preferred. -- 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-234) Add lots of logging to better understand inner working of proton
[ https://issues.apache.org/jira/browse/PROTON-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13576611#comment-13576611 ] Bozo Dragojevic commented on PROTON-234: There is also a kind of followup set of patches that merge in all the other submitted fixes and improvements and adds logging to those places, too. https://github.com/ttlj/qpid-proton/commits/upstream-all > Add lots of logging to better understand inner working of proton > > > Key: PROTON-234 > URL: https://issues.apache.org/jira/browse/PROTON-234 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Bozo Dragojevic > > Add lots of logging to proton to ease understnding of it's inner workings > Introduce object naming facility as some layers are coupled really loosely > for now the logging route will just dump everything out to stderr, as it was > before > This is currently one giant commit off 0.3: > https://github.com/ttlj/qpid-proton/commits/upstream-logging > It doesn't merge quite cleanly to trunk. If this is interesting thing to have > I'd be willing to merge or rebase whichever is preferred. -- 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-233) Nonblocking connect must be handled explicitly in pn_driver_wait
[ https://issues.apache.org/jira/browse/PROTON-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13576594#comment-13576594 ] Bozo Dragojevic commented on PROTON-233: I think this is related to PROTON-134 > Nonblocking connect must be handled explicitly in pn_driver_wait > > > Key: PROTON-233 > URL: https://issues.apache.org/jira/browse/PROTON-233 > Project: Qpid Proton > Issue Type: Improvement >Reporter: Bozo Dragojevic > > Connecting to a non-existing address is not detected properly by the driver > fix: https://github.com/ttlj/qpid-proton/commits/upstream-connect -- 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-233) Nonblocking connect must be handled explicitly in pn_driver_wait
Bozo Dragojevic created PROTON-233: -- Summary: Nonblocking connect must be handled explicitly in pn_driver_wait Key: PROTON-233 URL: https://issues.apache.org/jira/browse/PROTON-233 Project: Qpid Proton Issue Type: Improvement Reporter: Bozo Dragojevic Connecting to a non-existing address is not detected properly by the driver fix: https://github.com/ttlj/qpid-proton/commits/upstream-connect -- 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-232) described arrays seem to force the descriptor to be of the same type as the array
Rafael H. Schloming created PROTON-232: -- Summary: described arrays seem to force the descriptor to be of the same type as the array Key: PROTON-232 URL: https://issues.apache.org/jira/browse/PROTON-232 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming -- 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-200) [Proton-c] Credit distribution by messenger is not balanced across all links
[ https://issues.apache.org/jira/browse/PROTON-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-200: --- Fix Version/s: (was: 0.5) 0.4 > [Proton-c] Credit distribution by messenger is not balanced across all links > > > Key: PROTON-200 > URL: https://issues.apache.org/jira/browse/PROTON-200 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.3 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.4 > > > The method used to distribute credit to receiving links may lead to > starvation when the number of receiving links is > the available credit. > The distribution algorithm always starts with the same link - see > messenger.c::pn_messenger_flow() -- 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-231) Allow messenger to be used inside an event loop
Bozo Dragojevic created PROTON-231: -- Summary: Allow messenger to be used inside an event loop Key: PROTON-231 URL: https://issues.apache.org/jira/browse/PROTON-231 Project: Qpid Proton Issue Type: Improvement Reporter: Bozo Dragojevic We use proton in multithreaded application. Network part is run by a separate threadpool (currently singlethreaded) but it needfs it's own event loop. The code below allows us to use messenger api in this context, before we can invest the time to switch to using the engine directly. https://github.com/ttlj/qpid-proton/commits/upstream-wakeup -- 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-230) pn_data_appendn is not exiting the node tree correctly
Bozo Dragojevic created PROTON-230: -- Summary: pn_data_appendn is not exiting the node tree correctly Key: PROTON-230 URL: https://issues.apache.org/jira/browse/PROTON-230 Project: Qpid Proton Issue Type: Bug Reporter: Bozo Dragojevic When a pn_data node is the last node on several consecutive levels pn_data_appendn exits just one level. testcase and fix: https://github.com/ttlj/qpid-proton/tree/upstream-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] [Commented] (PROTON-200) [Proton-c] Credit distribution by messenger is not balanced across all links
[ https://issues.apache.org/jira/browse/PROTON-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13576473#comment-13576473 ] Bozo Dragojevic commented on PROTON-200: My observation was that messenger was willing to hand out all of it's credit to the first link. So when the second client connects, say few seconds later, messenger has no credit left to hand out. This is my attempt at mitigating the issue. https://github.com/ttlj/qpid-proton/tree/upstream-credit > [Proton-c] Credit distribution by messenger is not balanced across all links > > > Key: PROTON-200 > URL: https://issues.apache.org/jira/browse/PROTON-200 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.3 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.5 > > > The method used to distribute credit to receiving links may lead to > starvation when the number of receiving links is > the available credit. > The distribution algorithm always starts with the same link - see > messenger.c::pn_messenger_flow() -- 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
