Re: [jira] [Commented] (PROTON-640) IO completion port Windows IO for Proton
Hi Bozzo, Please take a look at PROTON-668 and confirm none of the assumptions are counter to your usage, especially whether you fit scenario 3 and do not have problems with the proposed restriction to pn_pipe. If this is OK for you, I think I am close to a fix that will work for you. Cliff On Wed, Sep 10, 2014 at 4:51 AM, Bozo Dragojevic bo...@digiverse.si wrote: Hi Cliff, I agree that the current extra API call is kludgy if not downright ugly. I noticed today you already added a new API call pn_io_selector(), which has separate windows and posix implementations. For short term 'fix', I'd propose to hide my hack inthere -- make calling pn_io_selector() turn on the iocp on windows. Bozzo This would not impact the API and would restore the On 9. 09. 14 07:02, Cliff Jansen wrote: Ho Bozo, Thank you for comments and the suggested patch. I would prefer a solution that did not have a special Windows-only-sometimes call pn_io_no_iocp(). It seems to me anyway that there is another class of sockets that are pulled into an IOCP context too early, so that a separate solution is required that should fix your problem too. Basically, a more lazy enlistment strategy should leave you outside IOCP and fix the other issue too. Based on your problem and how Dispatch strives for multithreaded performance, I think I have a better handle on what Proton should be providing for small to medium-large scalability. I am going to try to define what is a sensible intersection of Windows and Posix capabilities to be supported by the proton io/selector/selectable classes in a separate documentation JIRA and try to get a fix for you ASAP, probably in yet another JIRA. Cliff
[jira] [Resolved] (PROTON-666) TransactionalState applied to indicate the txn-id before sending has no effect on the outgoing transfer frames
[ https://issues.apache.org/jira/browse/PROTON-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-666. --- Resolution: Fixed TransactionalState applied to indicate the txn-id before sending has no effect on the outgoing transfer frames -- Key: PROTON-666 URL: https://issues.apache.org/jira/browse/PROTON-666 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.7 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.8 In order to publish messages in a transaction, it is necessary to apply state to the outgoing transfer frames. Proton-J does allow applying a disposition change to the delivery with the relevant TransactionalState (which contains the required txn-id), however this has no impact on the transfer frames which then get emitted from the transport, resulting in the message transfers being considered non-transactional. The transport implementation should be updated to apply existing local delivery state to the outgoing transfer frames. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-571) proton-c: Messenger outputs errors to stderr rather than setting messenger-error
[ https://issues.apache.org/jira/browse/PROTON-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-571: - Attachment: (was: 03_set_pn_error_when_printing_connection_errors.patch) proton-c: Messenger outputs errors to stderr rather than setting messenger-error - Key: PROTON-571 URL: https://issues.apache.org/jira/browse/PROTON-571 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans For various errors, such as aborted connections, messenger simply outputs them to stderr rather then setting messenger-error. This makes it harder to drive from wrappering applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-574) proton-c: Messenger doesn't indicate when connection is aborted for a SASL negotation failure
[ https://issues.apache.org/jira/browse/PROTON-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-574: - Attachment: (was: 08_return_sasl_auth_errors_transport.h.patch) proton-c: Messenger doesn't indicate when connection is aborted for a SASL negotation failure - Key: PROTON-574 URL: https://issues.apache.org/jira/browse/PROTON-574 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Andrew Stitcher Attachments: 05_return_sasl_auth_errors_messenger.c.patch, 05_return_sasl_auth_errors_transport.c.patch, 05_return_sasl_auth_errors_transport.h.patch Currently if a Messenger's connection is aborted at the remote end, there's no differentiation between the connection just being dropped and a failure to negotiate SASL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-574) proton-c: Messenger doesn't indicate when connection is aborted for a SASL negotation failure
[ https://issues.apache.org/jira/browse/PROTON-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-574: - Attachment: (was: 08_return_sasl_auth_errors_messenger.c.patch) proton-c: Messenger doesn't indicate when connection is aborted for a SASL negotation failure - Key: PROTON-574 URL: https://issues.apache.org/jira/browse/PROTON-574 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Andrew Stitcher Attachments: 05_return_sasl_auth_errors_messenger.c.patch, 05_return_sasl_auth_errors_transport.c.patch, 05_return_sasl_auth_errors_transport.h.patch Currently if a Messenger's connection is aborted at the remote end, there's no differentiation between the connection just being dropped and a failure to negotiate SASL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-574) proton-c: Messenger doesn't indicate when connection is aborted for a SASL negotation failure
[ https://issues.apache.org/jira/browse/PROTON-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-574: - Attachment: (was: 08_return_sasl_auth_errors_transport.c.patch) proton-c: Messenger doesn't indicate when connection is aborted for a SASL negotation failure - Key: PROTON-574 URL: https://issues.apache.org/jira/browse/PROTON-574 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Andrew Stitcher Attachments: 05_return_sasl_auth_errors_messenger.c.patch, 05_return_sasl_auth_errors_transport.c.patch, 05_return_sasl_auth_errors_transport.h.patch Currently if a Messenger's connection is aborted at the remote end, there's no differentiation between the connection just being dropped and a failure to negotiate SASL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-669) proton-c: Messenger abstracts away connections, but it would be useful to fail fast for auth errors etc.
Dominic Evans created PROTON-669: Summary: proton-c: Messenger abstracts away connections, but it would be useful to fail fast for auth errors etc. Key: PROTON-669 URL: https://issues.apache.org/jira/browse/PROTON-669 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans As previously discussed on the mailing list under [Using the messenger API to connect to a server without sending or subscribing|http://qpid.2158936.n2.nabble.com/Using-the-messenger-API-to-connect-to-a-server-without-sending-or-subscribing-td7607184.html]; Messenger doesn't provide a way of requesting a connection. Messenger has been designed to abstract away the notion of establishing connections from the user, but we would like to fail fast in those situations and return authentication errors (e.g.,) to the user. Rafa suggested that we could add an option to messenger to enable the checking of routes at startup, which is what the attached patch intends to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-548) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)
[ https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-548: - Attachment: (was: 14_fix_ipv6_windows.patch) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6) - Key: PROTON-548 URL: https://issues.apache.org/jira/browse/PROTON-548 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.6 Reporter: Ted Ross Attachments: 08_fix_ipv6_windows.patch The proton-c driver hard-codes its sockets to AF_INET, rather than using the address family associated with a particular address. On systems that enable IPv6, the address localhost cannot be used because it resolves to ::1 rather than 127.0.0.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-548) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)
[ https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-548: - Attachment: 08_fix_ipv6_windows.patch Proton-C driver and URL Parsers don't support AF_INET6 (IPv6) - Key: PROTON-548 URL: https://issues.apache.org/jira/browse/PROTON-548 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.6 Reporter: Ted Ross Attachments: 08_fix_ipv6_windows.patch The proton-c driver hard-codes its sockets to AF_INET, rather than using the address family associated with a particular address. On systems that enable IPv6, the address localhost cannot be used because it resolves to ::1 rather than 127.0.0.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-669) proton-c: Messenger abstracts away connections, but it would be useful to fail fast for auth errors etc.
[ https://issues.apache.org/jira/browse/PROTON-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-669: - Attachment: 07_add_messenger_route_check_on_start_transform.h.patch 07_add_messenger_route_check_on_start_transform.c.patch proton-c: Messenger abstracts away connections, but it would be useful to fail fast for auth errors etc. Key: PROTON-669 URL: https://issues.apache.org/jira/browse/PROTON-669 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 07_add_messenger_route_check_on_start.patch, 07_add_messenger_route_check_on_start_header.patch, 07_add_messenger_route_check_on_start_transform.c.patch, 07_add_messenger_route_check_on_start_transform.h.patch As previously discussed on the mailing list under [Using the messenger API to connect to a server without sending or subscribing|http://qpid.2158936.n2.nabble.com/Using-the-messenger-API-to-connect-to-a-server-without-sending-or-subscribing-td7607184.html]; Messenger doesn't provide a way of requesting a connection. Messenger has been designed to abstract away the notion of establishing connections from the user, but we would like to fail fast in those situations and return authentication errors (e.g.,) to the user. Rafa suggested that we could add an option to messenger to enable the checking of routes at startup, which is what the attached patch intends to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-578) proton-c: windows/io.c prints Unknown error for all winsock errors
[ https://issues.apache.org/jira/browse/PROTON-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-578: - Attachment: 10_fix_winsock_error_code_printing.patch proton-c: windows/io.c prints Unknown error for all winsock errors Key: PROTON-578 URL: https://issues.apache.org/jira/browse/PROTON-578 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Cliff Jansen Attachments: 10_fix_winsock_error_code_printing.patch The code in windows/io.c is attempting to call strerror on Winsock WSA error codes returned by WSAGetLastError(). However, these codes don't map to Unix errno codes, so will always output an Unknown error msg. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-578) proton-c: windows/io.c prints Unknown error for all winsock errors
[ https://issues.apache.org/jira/browse/PROTON-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-578: - Attachment: (was: 17_fix_winsock_error_code_printing.patch) proton-c: windows/io.c prints Unknown error for all winsock errors Key: PROTON-578 URL: https://issues.apache.org/jira/browse/PROTON-578 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Cliff Jansen Attachments: 10_fix_winsock_error_code_printing.patch The code in windows/io.c is attempting to call strerror on Winsock WSA error codes returned by WSAGetLastError(). However, these codes don't map to Unix errno codes, so will always output an Unknown error msg. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-571) proton-c: Messenger outputs errors to stderr rather than setting messenger-error
[ https://issues.apache.org/jira/browse/PROTON-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-571: - Attachment: 02_set_pn_error_when_printing_connection_errors.patch 02_replace_perror_printing_with_error_setting_posix_driver.patch proton-c: Messenger outputs errors to stderr rather than setting messenger-error - Key: PROTON-571 URL: https://issues.apache.org/jira/browse/PROTON-571 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 02_replace_perror_printing_with_error_setting_posix_driver.patch, 02_set_pn_error_when_printing_connection_errors.patch For various errors, such as aborted connections, messenger simply outputs them to stderr rather then setting messenger-error. This makes it harder to drive from wrappering applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-571) proton-c: Messenger outputs errors to stderr rather than setting messenger-error
[ https://issues.apache.org/jira/browse/PROTON-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-571: - Attachment: (was: 02_set_pn_error_when_printing_connection_errors.patch) proton-c: Messenger outputs errors to stderr rather than setting messenger-error - Key: PROTON-571 URL: https://issues.apache.org/jira/browse/PROTON-571 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 02_replace_perror_printing_with_error_setting_posix_driver.patch, 02_set_pn_error_when_printing_connection_errors.patch For various errors, such as aborted connections, messenger simply outputs them to stderr rather then setting messenger-error. This makes it harder to drive from wrappering applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-670) proton-c: Messenger doesn't provide accessors for the links it is using
Dominic Evans created PROTON-670: Summary: proton-c: Messenger doesn't provide accessors for the links it is using Key: PROTON-670 URL: https://issues.apache.org/jira/browse/PROTON-670 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Messenger doesn't provide accessors for the links it uses. As a consuming application that is using the Messenger API, it would be helpful to have access to this information so that you can determine which subscription address a given message was received upon. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-670) proton-c: Messenger doesn't provide accessors for the links it is using
[ https://issues.apache.org/jira/browse/PROTON-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-670: - Attachment: 12_get_link_from_tracker_messenger.h.patch 12_get_link_from_tracker_messenger.c.patch proton-c: Messenger doesn't provide accessors for the links it is using --- Key: PROTON-670 URL: https://issues.apache.org/jira/browse/PROTON-670 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 12_get_link_from_tracker_messenger.c.patch, 12_get_link_from_tracker_messenger.h.patch Messenger doesn't provide accessors for the links it uses. As a consuming application that is using the Messenger API, it would be helpful to have access to this information so that you can determine which subscription address a given message was received upon. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-670) proton-c: Messenger doesn't provide accessors for the links it is using
[ https://issues.apache.org/jira/browse/PROTON-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129860#comment-14129860 ] Dominic Evans commented on PROTON-670: -- patches attached to allow user to determine the link associated with a particular message by tracker entry proton-c: Messenger doesn't provide accessors for the links it is using --- Key: PROTON-670 URL: https://issues.apache.org/jira/browse/PROTON-670 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 12_get_link_from_tracker_messenger.c.patch, 12_get_link_from_tracker_messenger.h.patch Messenger doesn't provide accessors for the links it uses. As a consuming application that is using the Messenger API, it would be helpful to have access to this information so that you can determine which subscription address a given message was received upon. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-671) proton-c: Messenger doesn't provide a way to set the link settlement modes it uses
[ https://issues.apache.org/jira/browse/PROTON-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-671: - Attachment: (was: 13_add_pn_messenger_set_settle_mode_functions_to_header.patch) proton-c: Messenger doesn't provide a way to set the link settlement modes it uses --- Key: PROTON-671 URL: https://issues.apache.org/jira/browse/PROTON-671 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 13_add_pn_messenger_set_settle_mode_functions.patch Messenger doesn't provide a way to set link settlement modes. Messenger defaults to PN_SND_SETTLED and PN_RCV_FIRST and doesn't provide a way to override that behaviour. Patches attached to allow these to be configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-671) proton-c: Messenger doesn't provide a way to set the link settlement modes it uses
[ https://issues.apache.org/jira/browse/PROTON-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-671: - Attachment: 13_add_pn_messenger_set_settle_mode_functions_to_header.patch 13_add_pn_messenger_set_settle_mode_functions.patch proton-c: Messenger doesn't provide a way to set the link settlement modes it uses --- Key: PROTON-671 URL: https://issues.apache.org/jira/browse/PROTON-671 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 13_add_pn_messenger_set_settle_mode_functions.patch Messenger doesn't provide a way to set link settlement modes. Messenger defaults to PN_SND_SETTLED and PN_RCV_FIRST and doesn't provide a way to override that behaviour. Patches attached to allow these to be configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-671) proton-c: Messenger doesn't provide a way to set the link settlement modes it uses
[ https://issues.apache.org/jira/browse/PROTON-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-671: - Attachment: (was: 13_add_pn_messenger_set_settle_mode_functions.patch) proton-c: Messenger doesn't provide a way to set the link settlement modes it uses --- Key: PROTON-671 URL: https://issues.apache.org/jira/browse/PROTON-671 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 13_add_pn_messenger_set_settle_mode_functions.patch, 13_add_pn_messenger_set_settle_mode_functions_to_header.patch Messenger doesn't provide a way to set link settlement modes. Messenger defaults to PN_SND_SETTLED and PN_RCV_FIRST and doesn't provide a way to override that behaviour. Patches attached to allow these to be configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-671) proton-c: Messenger doesn't provide a way to set the link settlement modes it uses
[ https://issues.apache.org/jira/browse/PROTON-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-671: - Attachment: 13_add_pn_messenger_set_settle_mode_functions_to_header.patch 13_add_pn_messenger_set_settle_mode_functions.patch proton-c: Messenger doesn't provide a way to set the link settlement modes it uses --- Key: PROTON-671 URL: https://issues.apache.org/jira/browse/PROTON-671 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 13_add_pn_messenger_set_settle_mode_functions.patch, 13_add_pn_messenger_set_settle_mode_functions_to_header.patch Messenger doesn't provide a way to set link settlement modes. Messenger defaults to PN_SND_SETTLED and PN_RCV_FIRST and doesn't provide a way to override that behaviour. Patches attached to allow these to be configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-672) proton-c: Messenger doesn't support setting the transport tracer
Dominic Evans created PROTON-672: Summary: proton-c: Messenger doesn't support setting the transport tracer Key: PROTON-672 URL: https://issues.apache.org/jira/browse/PROTON-672 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Messenger doesn't support setting the transport tracer. Messenger ought to provide a way to allow the transport tracer function to be overriden so that tracing can be captured by the consuming application. Patches attached to implement this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-672) proton-c: Messenger doesn't support setting the transport tracer
[ https://issues.apache.org/jira/browse/PROTON-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-672: - Attachment: 14_add_tracer_to_messenger.h.patch 14_add_tracer_to_messenger.c.patch proton-c: Messenger doesn't support setting the transport tracer Key: PROTON-672 URL: https://issues.apache.org/jira/browse/PROTON-672 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 14_add_tracer_to_messenger.c.patch, 14_add_tracer_to_messenger.h.patch Messenger doesn't support setting the transport tracer. Messenger ought to provide a way to allow the transport tracer function to be overriden so that tracing can be captured by the consuming application. Patches attached to implement this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-672) proton-c: Messenger doesn't support setting the transport tracer
[ https://issues.apache.org/jira/browse/PROTON-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-672: - Attachment: 15_get_connection_from_transport.h.patch 15_get_connection_from_transport.c.patch proton-c: Messenger doesn't support setting the transport tracer Key: PROTON-672 URL: https://issues.apache.org/jira/browse/PROTON-672 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 14_add_tracer_to_messenger.c.patch, 14_add_tracer_to_messenger.h.patch, 15_get_connection_from_transport.c.patch, 15_get_connection_from_transport.h.patch Messenger doesn't support setting the transport tracer. Messenger ought to provide a way to allow the transport tracer function to be overriden so that tracing can be captured by the consuming application. Patches attached to implement this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-673) proton-c: Messenger doesn't provide a way to obtain the remote idle timeout
[ https://issues.apache.org/jira/browse/PROTON-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-673: - Attachment: 19_add_get_remote_idle_timeout_to_messenger.h.patch 19_add_get_remote_idle_timeout_to_messenger.c.patch proton-c: Messenger doesn't provide a way to obtain the remote idle timeout --- Key: PROTON-673 URL: https://issues.apache.org/jira/browse/PROTON-673 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 19_add_get_remote_idle_timeout_to_messenger.c.patch, 19_add_get_remote_idle_timeout_to_messenger.h.patch Messenger doesn't provide a way to obtain the remote idle timeout which is required to ensure the client application can maintain the keep alive heartbeat, i.e. by calling pn_messenger_work at a sufficiently regular rate. Patch attached to implement this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-673) proton-c: Messenger doesn't provide a way to obtain the remote idle timeout
Dominic Evans created PROTON-673: Summary: proton-c: Messenger doesn't provide a way to obtain the remote idle timeout Key: PROTON-673 URL: https://issues.apache.org/jira/browse/PROTON-673 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 19_add_get_remote_idle_timeout_to_messenger.c.patch, 19_add_get_remote_idle_timeout_to_messenger.h.patch Messenger doesn't provide a way to obtain the remote idle timeout which is required to ensure the client application can maintain the keep alive heartbeat, i.e. by calling pn_messenger_work at a sufficiently regular rate. Patch attached to implement this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-571) proton-c: Messenger outputs errors to stderr rather than setting messenger-error
[ https://issues.apache.org/jira/browse/PROTON-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-571: - Attachment: 21_improve_perror_printing_windows_io.c.patch 21_improve_perror_printing_posix_io.c.patch 21_improve_perror_printing_messenger.c.patch 21_improve_perror_printing_io.h.patch proton-c: Messenger outputs errors to stderr rather than setting messenger-error - Key: PROTON-571 URL: https://issues.apache.org/jira/browse/PROTON-571 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 02_replace_perror_printing_with_error_setting_posix_driver.patch, 02_set_pn_error_when_printing_connection_errors.patch, 21_improve_perror_printing_io.h.patch, 21_improve_perror_printing_messenger.c.patch, 21_improve_perror_printing_posix_io.c.patch, 21_improve_perror_printing_windows_io.c.patch For various errors, such as aborted connections, messenger simply outputs them to stderr rather then setting messenger-error. This makes it harder to drive from wrappering applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-571) proton-c: Messenger outputs errors to stderr rather than setting messenger-error
[ https://issues.apache.org/jira/browse/PROTON-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129889#comment-14129889 ] Dominic Evans commented on PROTON-571: -- Additional patchset to fix Windows socket errors. proton-c: Messenger outputs errors to stderr rather than setting messenger-error - Key: PROTON-571 URL: https://issues.apache.org/jira/browse/PROTON-571 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 02_replace_perror_printing_with_error_setting_posix_driver.patch, 02_set_pn_error_when_printing_connection_errors.patch, 21_improve_perror_printing_io.h.patch, 21_improve_perror_printing_messenger.c.patch, 21_improve_perror_printing_posix_io.c.patch, 21_improve_perror_printing_windows_io.c.patch For various errors, such as aborted connections, messenger simply outputs them to stderr rather then setting messenger-error. This makes it harder to drive from wrappering applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-674) proton-c: Messenger doesn't provide a way of setting the TTL on a subscription
Dominic Evans created PROTON-674: Summary: proton-c: Messenger doesn't provide a way of setting the TTL on a subscription Key: PROTON-674 URL: https://issues.apache.org/jira/browse/PROTON-674 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Messenger doesn't provide a way of setting ttl on a subscription. We want to be able to specify the timeout of a given subscription link when we open it. Patches attached to add pn_messenger_subscribe_ttl call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-674) proton-c: Messenger doesn't provide a way of setting the TTL on a subscription
[ https://issues.apache.org/jira/browse/PROTON-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-674: - Attachment: 22_add_messenger_subscribe_ttl_method_messenger.h.patch 22_add_messenger_subscribe_ttl_method_messenger.c.patch proton-c: Messenger doesn't provide a way of setting the TTL on a subscription -- Key: PROTON-674 URL: https://issues.apache.org/jira/browse/PROTON-674 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 22_add_messenger_subscribe_ttl_method_messenger.c.patch, 22_add_messenger_subscribe_ttl_method_messenger.h.patch Messenger doesn't provide a way of setting ttl on a subscription. We want to be able to specify the timeout of a given subscription link when we open it. Patches attached to add pn_messenger_subscribe_ttl call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-675) proton-c: Messenger doesn't provide a way of setting the SSL peer authentication mode
Dominic Evans created PROTON-675: Summary: proton-c: Messenger doesn't provide a way of setting the SSL peer authentication mode Key: PROTON-675 URL: https://issues.apache.org/jira/browse/PROTON-675 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Messenger doesn't provide a way of setting the SSL peer authentication mode when a trust certificate is being used (it is hardcoded to: PN_SSL_VERIFY_PEER_NAME). We want the option to be able to optionally specify PN_SSL_VERIFY_PEER instead. Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-675) proton-c: Messenger doesn't provide a way of setting the SSL peer authentication mode
[ https://issues.apache.org/jira/browse/PROTON-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-675: - Attachment: 23_add_messenger_set_ssl_peer_authentication_mode_method_messenger.h.patch 23_add_messenger_set_ssl_peer_authentication_mode_method_messenger.c.patch proton-c: Messenger doesn't provide a way of setting the SSL peer authentication mode - Key: PROTON-675 URL: https://issues.apache.org/jira/browse/PROTON-675 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 23_add_messenger_set_ssl_peer_authentication_mode_method_messenger.c.patch, 23_add_messenger_set_ssl_peer_authentication_mode_method_messenger.h.patch Messenger doesn't provide a way of setting the SSL peer authentication mode when a trust certificate is being used (it is hardcoded to: PN_SSL_VERIFY_PEER_NAME). We want the option to be able to optionally specify PN_SSL_VERIFY_PEER instead. Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-676) proton-c: transport layer SSL failures not propagated back to Messenger in pni_connection_readable
Dominic Evans created PROTON-676: Summary: proton-c: transport layer SSL failures not propagated back to Messenger in pni_connection_readable Key: PROTON-676 URL: https://issues.apache.org/jira/browse/PROTON-676 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 24_ssl_transport_failure_fix_messenger.c.patch When an ssl failure occurs during connection at the transport layer the error is not propagated back to messenger (it is ignored). Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-660) Fix openssl.c build on windows
[ https://issues.apache.org/jira/browse/PROTON-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-660: - Attachment: 25_openssl_fix_for_windows_platform.h.patch 25_openssl_fix_for_windows_data.h.patch 25_openssl_fix_for_windows_CMakeLists.patch We happend to have similarly hit this issue, but fixed it in a slightly different way, so I'm attaching our patches for reference as well. These include a patch to CMakeLists.txt to allow a OPENSSL_INCLUDE_DIR param to be supplied at build time. Fix openssl.c build on windows -- Key: PROTON-660 URL: https://issues.apache.org/jira/browse/PROTON-660 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Environment: Windows 7, VS2013 Reporter: Bozo Dragojevic Attachments: 0001-PROTON-660-Fix-openssl.c-build-on-windows.patch, 25_openssl_fix_for_windows_CMakeLists.patch, 25_openssl_fix_for_windows_data.h.patch, 25_openssl_fix_for_windows_platform.h.patch Compiled openssl-1.0.1i from source Proton finds it, but openssl.c does not compile without small adjustments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-677) proton-c: transport incorrectly detaches all links with closed=true by default
[ https://issues.apache.org/jira/browse/PROTON-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-677: - Attachment: 26_stop_link_detach_closed_if_sub_ttl_transport.c.patch proton-c: transport incorrectly detaches all links with closed=true by default -- Key: PROTON-677 URL: https://issues.apache.org/jira/browse/PROTON-677 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 26_stop_link_detach_closed_if_sub_ttl_transport.c.patch qpid-proton detaches all links with closed=true by default. If a subscription has a time-to-live and is not expected to be destroyed on detach then we shouldn't be setting closed=true on the detach call. Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-678) proton-c: (Win 32-bit) pn_post_frame misinterprets variable argument data when ERROR is used
Dominic Evans created PROTON-678: Summary: proton-c: (Win 32-bit) pn_post_frame misinterprets variable argument data when ERROR is used Key: PROTON-678 URL: https://issues.apache.org/jira/browse/PROTON-678 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: Windows x86-32 Reporter: Dominic Evans For Windows 32bit ERROR is not a uint64_t type, which causes pn_post_frame to misinterpret the passed variable argument data when ERROR is used patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-678) proton-c: (Win 32-bit) pn_post_frame misinterprets variable argument data when ERROR is used
[ https://issues.apache.org/jira/browse/PROTON-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-678: - Attachment: 27_32bit_windows_fix_transport.c.patch proton-c: (Win 32-bit) pn_post_frame misinterprets variable argument data when ERROR is used Key: PROTON-678 URL: https://issues.apache.org/jira/browse/PROTON-678 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: Windows x86-32 Reporter: Dominic Evans Attachments: 27_32bit_windows_fix_transport.c.patch For Windows 32bit ERROR is not a uint64_t type, which causes pn_post_frame to misinterpret the passed variable argument data when ERROR is used patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-680) proton-c: Messenger doesn't provide a way of obtaining link or delivery information
[ https://issues.apache.org/jira/browse/PROTON-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-680: - Attachment: 31_access_messenger_deliveries_messenger.h.patch 30_access_messenger_deliveries_messenger.c.patch 29_access_messenger_links_messenger.h.patch 29_access_messenger_links_messenger.c.patch proton-c: Messenger doesn't provide a way of obtaining link or delivery information --- Key: PROTON-680 URL: https://issues.apache.org/jira/browse/PROTON-680 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 29_access_messenger_links_messenger.c.patch, 29_access_messenger_links_messenger.h.patch, 30_access_messenger_deliveries_messenger.c.patch, 31_access_messenger_deliveries_messenger.h.patch This would be useful for determining why a delivery was rejected by the server (for example). Patches attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-571) proton-c: Messenger outputs errors to stderr rather than setting messenger-error
[ https://issues.apache.org/jira/browse/PROTON-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-571: - Attachment: 02_set_pn_error_when_printing_connection_errors.patch proton-c: Messenger outputs errors to stderr rather than setting messenger-error - Key: PROTON-571 URL: https://issues.apache.org/jira/browse/PROTON-571 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 02_replace_perror_printing_with_error_setting_posix_driver.patch, 02_set_pn_error_when_printing_connection_errors.patch, 21_improve_perror_printing_io.h.patch, 21_improve_perror_printing_messenger.c.patch, 21_improve_perror_printing_posix_io.c.patch, 21_improve_perror_printing_windows_io.c.patch For various errors, such as aborted connections, messenger simply outputs them to stderr rather then setting messenger-error. This makes it harder to drive from wrappering applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-571) proton-c: Messenger outputs errors to stderr rather than setting messenger-error
[ https://issues.apache.org/jira/browse/PROTON-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-571: - Attachment: (was: 02_set_pn_error_when_printing_connection_errors.patch) proton-c: Messenger outputs errors to stderr rather than setting messenger-error - Key: PROTON-571 URL: https://issues.apache.org/jira/browse/PROTON-571 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 02_replace_perror_printing_with_error_setting_posix_driver.patch, 02_set_pn_error_when_printing_connection_errors.patch, 21_improve_perror_printing_io.h.patch, 21_improve_perror_printing_messenger.c.patch, 21_improve_perror_printing_posix_io.c.patch, 21_improve_perror_printing_windows_io.c.patch For various errors, such as aborted connections, messenger simply outputs them to stderr rather then setting messenger-error. This makes it harder to drive from wrappering applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-625) prevert looping when map-load_factor exactly equals load
[ https://issues.apache.org/jira/browse/PROTON-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-625: -- Summary: prevert looping when map-load_factor exactly equals load (was: Biggest Backtrace Ever!) prevert looping when map-load_factor exactly equals load - Key: PROTON-625 URL: https://issues.apache.org/jira/browse/PROTON-625 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: michael goulish Fix For: 0.8 I am saving all my stuff so I can repro on demand. It doesn't happen every time, but it's about 50%. -- On one box, I have a dispatch router. On the other box, I have 10 clients: 5 Messenger-based receivers, and 5 qpid-messaging-based senders. Each client will handle 100 addresses, of the form mick/0 ... mick/1 ... c. 100 messages will be sent to each address. I start the 5 receivers first. They start OK. Dispatch router happy stable. Wait a few seconds. I start the 5 senders, from a bash script. The first sender is already sending when the 2nd, 3rd, 4th start. After a few of them start,but before all have finished starting, a few seconds into the script, the crash occurs. ( If they all start up successfully, no crash. ) The crash occurs in the dispatch router. Here is the biggest backtrace ever: #0 0x003cf9879ad1 in _int_malloc (av=0x7f101c20, bytes=16384) at malloc.c:4383 #1 0x003cf987a911 in __libc_malloc (bytes=16384) at malloc.c:3664 #2 0x0039c6c1650a in pni_map_allocate () from /usr/lib64/libqpid-proton.so.2 #3 0x0039c6c16a3a in pni_map_ensure () from /usr/lib64/libqpid-proton.so.2 #4 0x0039c6c16c45 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #5 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #6 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #7 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #8 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #9 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #10 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #11 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #12 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #13 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #14 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 . . . . #93549 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93550 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93551 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93552 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93553 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93554 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93555 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93556 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93557 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93558 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93559 0x0039c6c16dc0 in pn_map_put () from /usr/lib64/libqpid-proton.so.2 #93560 0x0039c6c17226 in pn_hash_put () from /usr/lib64/libqpid-proton.so.2 #93561 0x0039c6c2a643 in pn_delivery_map_push () from /usr/lib64/libqpid-proton.so.2 #93562 0x0039c6c2c44b in pn_do_transfer () from /usr/lib64/libqpid-proton.so.2 #93563 0x0039c6c24385 in pn_dispatch_frame () from /usr/lib64/libqpid-proton.so.2 #93564 0x0039c6c2448f in pn_dispatcher_input () from /usr/lib64/libqpid-proton.so.2 #93565 0x0039c6c2d68b in pn_input_read_amqp () from /usr/lib64/libqpid-proton.so.2 #93566 0x0039c6c3011a in pn_io_layer_input_passthru () from /usr/lib64/libqpid-proton.so.2 #93567 0x0039c6c3011a in pn_io_layer_input_passthru () from /usr/lib64/libqpid-proton.so.2 #93568 0x0039c6c2d275 in transport_consume () from /usr/lib64/libqpid-proton.so.2 #93569 0x0039c6c304cd in pn_transport_process () from /usr/lib64/libqpid-proton.so.2 #93570 0x0039c6c3e40c in pn_connector_process () from /usr/lib64/libqpid-proton.so.2 #93571 0x7f1060c60460 in process_connector () from /home/mick/dispatch/build/libqpid-dispatch.so.0 #93572 0x7f1060c61017 in thread_run () from /home/mick/dispatch/build/libqpid-dispatch.so.0 #93573 0x003cf9c07851 in start_thread
[jira] [Updated] (PROTON-625) prevert looping when map-load_factor exactly equals load
[ https://issues.apache.org/jira/browse/PROTON-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-625: -- Fix Version/s: 0.8 prevert looping when map-load_factor exactly equals load - Key: PROTON-625 URL: https://issues.apache.org/jira/browse/PROTON-625 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: michael goulish Fix For: 0.8 I am saving all my stuff so I can repro on demand. It doesn't happen every time, but it's about 50%. -- On one box, I have a dispatch router. On the other box, I have 10 clients: 5 Messenger-based receivers, and 5 qpid-messaging-based senders. Each client will handle 100 addresses, of the form mick/0 ... mick/1 ... c. 100 messages will be sent to each address. I start the 5 receivers first. They start OK. Dispatch router happy stable. Wait a few seconds. I start the 5 senders, from a bash script. The first sender is already sending when the 2nd, 3rd, 4th start. After a few of them start,but before all have finished starting, a few seconds into the script, the crash occurs. ( If they all start up successfully, no crash. ) The crash occurs in the dispatch router. Here is the biggest backtrace ever: #0 0x003cf9879ad1 in _int_malloc (av=0x7f101c20, bytes=16384) at malloc.c:4383 #1 0x003cf987a911 in __libc_malloc (bytes=16384) at malloc.c:3664 #2 0x0039c6c1650a in pni_map_allocate () from /usr/lib64/libqpid-proton.so.2 #3 0x0039c6c16a3a in pni_map_ensure () from /usr/lib64/libqpid-proton.so.2 #4 0x0039c6c16c45 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #5 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #6 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #7 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #8 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #9 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #10 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #11 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #12 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #13 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #14 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 . . . . #93549 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93550 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93551 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93552 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93553 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93554 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93555 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93556 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93557 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93558 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93559 0x0039c6c16dc0 in pn_map_put () from /usr/lib64/libqpid-proton.so.2 #93560 0x0039c6c17226 in pn_hash_put () from /usr/lib64/libqpid-proton.so.2 #93561 0x0039c6c2a643 in pn_delivery_map_push () from /usr/lib64/libqpid-proton.so.2 #93562 0x0039c6c2c44b in pn_do_transfer () from /usr/lib64/libqpid-proton.so.2 #93563 0x0039c6c24385 in pn_dispatch_frame () from /usr/lib64/libqpid-proton.so.2 #93564 0x0039c6c2448f in pn_dispatcher_input () from /usr/lib64/libqpid-proton.so.2 #93565 0x0039c6c2d68b in pn_input_read_amqp () from /usr/lib64/libqpid-proton.so.2 #93566 0x0039c6c3011a in pn_io_layer_input_passthru () from /usr/lib64/libqpid-proton.so.2 #93567 0x0039c6c3011a in pn_io_layer_input_passthru () from /usr/lib64/libqpid-proton.so.2 #93568 0x0039c6c2d275 in transport_consume () from /usr/lib64/libqpid-proton.so.2 #93569 0x0039c6c304cd in pn_transport_process () from /usr/lib64/libqpid-proton.so.2 #93570 0x0039c6c3e40c in pn_connector_process () from /usr/lib64/libqpid-proton.so.2 #93571 0x7f1060c60460 in process_connector () from /home/mick/dispatch/build/libqpid-dispatch.so.0 #93572 0x7f1060c61017 in thread_run () from /home/mick/dispatch/build/libqpid-dispatch.so.0 #93573 0x003cf9c07851 in start_thread (arg=0x7f1052bfd700) at pthread_create.c:301 #93574 0x003cf98e890d in clone () at
[jira] [Updated] (PROTON-548) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)
[ https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated PROTON-548: Assignee: Cliff Jansen Proton-C driver and URL Parsers don't support AF_INET6 (IPv6) - Key: PROTON-548 URL: https://issues.apache.org/jira/browse/PROTON-548 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.6 Reporter: Ted Ross Assignee: Cliff Jansen Attachments: 08_fix_ipv6_windows.patch The proton-c driver hard-codes its sockets to AF_INET, rather than using the address family associated with a particular address. On systems that enable IPv6, the address localhost cannot be used because it resolves to ::1 rather than 127.0.0.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-681) proton-c: pni_map_ensure infinite loop if `load = map-load_factor`
[ https://issues.apache.org/jira/browse/PROTON-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129960#comment-14129960 ] Dominic Evans commented on PROTON-681: -- [~gemmellr] yep you're correct, looks like this is a dupe. I didn't spot that when I searched to see if the issue was already reported. Will close this one off as fixed. proton-c: pni_map_ensure infinite loop if `load = map-load_factor` --- Key: PROTON-681 URL: https://issues.apache.org/jira/browse/PROTON-681 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 33_pni_map_ensure_bug_fix_object.c.patch Fix to a bug in pni_map_ensure, where it does not account for the case were load = map-load_factor, results in an infinite loop. Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-681) proton-c: pni_map_ensure infinite loop if `load = map-load_factor`
[ https://issues.apache.org/jira/browse/PROTON-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans resolved PROTON-681. -- Resolution: Duplicate Closing as dupe. proton-c: pni_map_ensure infinite loop if `load = map-load_factor` --- Key: PROTON-681 URL: https://issues.apache.org/jira/browse/PROTON-681 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 33_pni_map_ensure_bug_fix_object.c.patch Fix to a bug in pni_map_ensure, where it does not account for the case were load = map-load_factor, results in an infinite loop. Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-611) [proton-c] transport buffer increased to peer's max frame size if initial output_size is not enough
[ https://issues.apache.org/jira/browse/PROTON-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans closed PROTON-611. [proton-c] transport buffer increased to peer's max frame size if initial output_size is not enough --- Key: PROTON-611 URL: https://issues.apache.org/jira/browse/PROTON-611 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Andrew Stitcher Fix For: 0.8 Attachments: 20_fix_bad_malloc_in_transport_produce.patch transport_produce attempts to allocate a negatively sized buffer As soon as remote_max_frame is set, the code in transport_produce attempts to increase its buffer immediately up to that size when its initial size isn't enough. This causes a huge malloc to occur if the remote max frame size is large and also potentially overflows MAX_INT -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-573) proton-c: Messenger appears to have hard-coded address limits of 1024
[ https://issues.apache.org/jira/browse/PROTON-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans closed PROTON-573. proton-c: Messenger appears to have hard-coded address limits of 1024 - Key: PROTON-573 URL: https://issues.apache.org/jira/browse/PROTON-573 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Rafael H. Schloming Attachments: 06_arbitrary_length_addresses_in_store.patch, 07_arbitrary_length_addresses_in_messenger.patch The AMQP 1.0 spec permits pretty much arbitrary length link names, but Messenger hard-codes some 1K limits in various places. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-682) proton-c: a call to pn_messenger_stop can get into an infinite loop if the remote connection is severed
Dominic Evans created PROTON-682: Summary: proton-c: a call to pn_messenger_stop can get into an infinite loop if the remote connection is severed Key: PROTON-682 URL: https://issues.apache.org/jira/browse/PROTON-682 Project: Qpid Proton Issue Type: Bug Reporter: Dominic Evans The problem is that the transport layer is not being closed down properly if output is pending when the connection is severed and a messenger stop is requested. pn_messenger_stop needs to send out an AMQP close message any will only do this when there is an event to say that it can write (i.e pn_messenger_process gets a PN_WRITABLE event from pn_selector_next, which examines the pollfd and sets PN_WRITABLE event if POLLOUT is set in revents). Because this event is never generated it seems to loop forever. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jira] [Created] (PROTON-668) Document Proton-c IO restrictions for 0.8 release
Hi Cliff, comments inline On 11. 09. 14 09:32, Cliff Jansen (JIRA) wrote: Proton is designed to provide an efficient IO layer that functions without imposing a threading model on the application. Applications may (1) roll their own IO and just use the Proton engine, (2) use all Proton primitives, (3) use some Proton primitives augmented by an external event loop. Case (1) is unrelated to this JIRA. The others may be restated: Scenario 2: Proton event loop: a proton selector manages socket events for all sockets placed in the selector, all associated sockets use pn_io_xxx() calls. Sockets outside the selector are unmanaged and passed through to the OS socket function unchanged. Scenario 3: Third party event loop (no proton selector involved), all sockets are treated as for unmanaged in scenario 2. yay, looks like my use-case :) Scenario 4, 5...: Others to support? The problem: The Proton Posix pattern for efficient IO is: tell me when your (OS) buffer is ready for io transfer (in or out) Whereas the normal Windows pattern is somewhat reversed (IO completion ports): tell me when you are done transferring data (to or from) my (user space) buffer The current Windows IOCP implementation (PROTON-640) tries to make the latter look like the former with some constraints. There should be documentation specifying reasonable limits on Proton usage that may be falsely implied by the API but do not translate efficiently to Windows. Assuming that future Windows implementations may adopt more aggressive performance strategies (especially on the read side), I would propose something along the lines of: a socket may only ever be used with a single pn_io_t in its lifetime exception: a socket from pn_accept() is not yet associated with any pn_io_t and its first use can be with any pn_io_t (or never with a pn_io_t at all) I'm not sure if it's implied, but pn_connect() and pn_listen() also need to support 'third party event loop'. Specifically, pn_connect() has to remain non-blocking (we get to know about the connect error later in the external event loop) send/recv/close may not be intermixed with similar non-Proton OS calls (otherwise: out of order or lost data) a socket can move once from an external loop to a proton loop, but never the other way pn_pipe() values can only be used with pn_read and pn_write and pn_selector_select, they cannot participate in an external event loop. External event loops should have their own mechanism how to signal non-socket events into the loop. Furthermore, there is no thread safety except: threads may do concurrent pn_io_xxx() calls as long as no two are simultaneous on the same socket (where xxx is send/recv/read/write) This will break pn_io_error() and pn_io_wouldblock() as they are defined now. pn_selector_select() is thread safe against pn_read/pn_write/pn_send/pn_recv, but the outcome of the select is indeterminate. pn_selector_select() must be interrupted and restarted at any time when other simultaneous IO may affect the outcome. When you say 'interrupted' is there a simpler way than a pn_write() to writeable pn_socket_t of pn_pipe() that has it's readable pn_socket_t associated with a pn_selectable_t that is added to said pn_selector_t ? ;) I have a feeling you don't really want/need to expose the pn_pipe(), but add a pn_selector_interrupt() and a mechanism of querying that for the caller of pn_selector_select() especially as you want to implement it completely differently on windows. calls on different pn_io_t objects do not interact and are thread safe. If it is desirable for a socket to be used in an external loop after being used in a Proton loop, we would need some sort of blocking calls along the lines of: pn_io_flush() pn_io_drain() which would be no-ops on Posix but would unwind outstanding completions on Windows. this part sounds ok, if it is needed Thanks, Bozzo
Re: proton javascript binding problem/question
fadams wrote What do you think of the approach that I've taken? My rationale for compiling proton-c to JavaScript and using a thin (ish) binding layer rather than doing a ground-up native JavaScript rewrite was primarily about support. I figured that there was a lot of effort being put into maintaining proton-c and that was what might be considered the canonical or reference implementation, so tracking improvements would end up being a pain with a separate code-base, whereas the binding to a compiled library just needs to cover the public API and ultimately I should pick up improvements to the core code transparently. If you look at what I've done you'll hopefully see a startling similarity with the SWIG bindings particularly the Python one. Hi Fraser, For the first version of our Node.js client, we ended up writing our light C++ module to access the bits of proton-c that we needed and bridge to Javascript. At the time I wasn't aware of your javascript branch, else we would have looked at using that first. However, I did recently also notice that SWIG-3.0.1 has now added a Javascript module for generating Node.js and Javascript bindings in the same way as is currently done for Python, Ruby etc. I wonder how that would compare to your emscripten approach? http://www.swig.org/Release/RELEASENOTES Cheers, Dom -- View this message in context: http://qpid.2158936.n2.nabble.com/proton-javascript-binding-problem-question-tp7612394p7613505.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
Re: proton javascript binding problem/question
On 11/09/14 15:25, Dominic Evans wrote: fadams wrote What do you think of the approach that I've taken? My rationale for compiling proton-c to JavaScript and using a thin (ish) binding layer rather than doing a ground-up native JavaScript rewrite was primarily about support. I figured that there was a lot of effort being put into maintaining proton-c and that was what might be considered the canonical or reference implementation, so tracking improvements would end up being a pain with a separate code-base, whereas the binding to a compiled library just needs to cover the public API and ultimately I should pick up improvements to the core code transparently. If you look at what I've done you'll hopefully see a startling similarity with the SWIG bindings particularly the Python one. Hi Fraser, For the first version of our Node.js client, we ended up writing our light C++ module to access the bits of proton-c that we needed and bridge to Javascript. At the time I wasn't aware of your javascript branch, else we would have looked at using that first. However, I did recently also notice that SWIG-3.0.1 has now added a Javascript module for generating Node.js and Javascript bindings in the same way as is currently done for Python, Ruby etc. I wonder how that would compare to your emscripten approach? http://www.swig.org/Release/RELEASENOTES Cheers, Dom Hi Dominic, Yeah I noticed the SWIG thing too recently, though can't recall where - ISTR it was done as part of Google Summer of Code or something. I can't say for sure, but my guess is that the approach is a bit different. At a guess (and I've not really looked at it yet much less played) the SWIG bindings are about being able to integrate/bind with native C/C++ to JavaScript - pretty much analogous to how similar things work with say Python/Perl etc. I suspect that the result is that the JavaScript will only be functional from a node.js environment and not a browser. With the emscripten based approach I'm essentially cross-compiling (or transpiling or whatever you might want to call it) to pure JavaScript, in practice to a subset of JavaScript called asm.js that is optimised for ahead of time compilation in the execution engine (recent versions of Firefox and I think V8 have optimisations for asm.js). There are relative pros and cons to each. I think using SWIG will be closer to the approach that you've already taken - though it's not free and it'll need a wrapper somewhat similar to what I've done in order to make it friendly JavaScript. The advantages are 1 - it'll *probably* perform better because it's a thin wrapper to native code, though by how much I couldn't say yet, with the most recent JavaScript engines the margin likely erodes but I'd suspect it'd perform better whatever. 2 - you are wrapping the C library and you'll be using TCP sockets (The emscripten version is pure JavaScript and uses WebSockets by default, though on my TODO list is to look at configurably using the node net library to use native TCP sockets). Conversely The emscripten based approach is pure JavaScript so runs happily in a browser or node.js. It supports WebSockets and WebRTC (though I've not tried the latter yet) though not (currently) TCP Sockets (though I've written a simple WS-TCP proxy that works pretty well). I've still got a bit of tinkering and tidying up of the emscripten based JavaScript binding, but I'd quite like to get it moved to proton trunk before too long. Once it's settled then I'll move on to my TODO list. FWIW I'm not averse to looking at the SWIG binding too, as I say unless my interpretation is wrong there are relative pros and cons to each and I suspect that they are complementary and not competing approaches. As I say I suspect that the SWIG approach would need Binding code similar to what I've done with emscripten in order to be any fun to use and if a complementary SWIG based binding was contemplated I'd really want to be using the same patterns/API as for the emscripten based one. I'd hope that this wouldn't end up being a whole duplicate as that would be a bit tedious, so I'd expect some relatively non-trivial refactoring to try and have as much shared as possible (take a look at the binding.js, none of it's necessarily rocket science but there was a lot of effort in the proton.Data part to try and make things as nicely idiomatically JavaScript as possible). What I discovered was that compiling the C to JavaScript using emscripten was easy and took me a few weekends of hacking, doing all the binding stuff has taken the best part of a year of spare time (OK not solid effort, but you get the picture) Does that answer your question? Are you the same Dominic Evans who's just filled up my in-box with Jira messages? I got home from work and opened my emails and OMG :-D Cheers, and thanks for taking an interest in the JavaScript bindings. Frase
[jira] [Created] (PROTON-683) Register Proton for Coverity scans
Justin Ross created PROTON-683: -- Summary: Register Proton for Coverity scans Key: PROTON-683 URL: https://issues.apache.org/jira/browse/PROTON-683 Project: Qpid Proton Issue Type: Task Components: proton-c, proton-j Reporter: Justin Ross For reference, the Qpid C++ and Java projects at Coverity: https://scan.coverity.com/projects/6 https://scan.coverity.com/projects/572 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
