[jira] [Updated] (PROTON-1939) NullPointerException while handing remote session.begin in TransportImpl
[
https://issues.apache.org/jira/browse/PROTON-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sreeram Garlapati updated PROTON-1939:
--
Description:
Our library (Microsoft Azure EventHubs java sdk) take a dependency on proton-j
library for AMQP implementation.
Many of Our customers are reporting this issue and would highly appreciate your
response.
We are basically hitting this TODO in the TransportImpl.java - which results in
reactor teardown:
[https://github.com/apache/qpid-proton-j/blob/master/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/TransportImpl.java#L1160]
Here's the Exception stack trace:
{color:#24292e}com.microsoft.azure.eventhubs.impl.MessagingFactory$RunReactor.run:487
messagingFactory[MessagingFactoryab1d8d],
hostName[NNN.servicebus.windows.net], error[UnHandled exception while
processing events in reactor:{color}
{color:#24292e} java.lang.NullPointerException: uncorrelated channel: 3{color}
{color:#24292e}
org.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:112){color}
{color:#24292e}
org.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:324){color}
{color:#24292e}
org.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:292){color}
{color:#24292e}
com.microsoft.azure.eventhubs.impl.MessagingFactory$RunReactor.run(MessagingFactory.java:462){color}
here's how to reproduce this error:
* configure the listener - to delay respond to session.begins for ex: by 5 secs
* then client (or another peer) sends session.begin
* client doesn't receive any response even after 1 sec
* then the client decides to close the session
* then, after few sec's service(listener) responds back with session.begin
Please contact us at [sreer...@microsoft.com|mailto:sreer...@microsoft.com]
[sjk...@microsoft.com|mailto:sjk...@microsoft.com] - if you need more data on
this or need a resource to contribute to this. Truly appreciate your help.
was:
Our library (Microsoft Azure EventHubs java sdk) take a dependency on proton-j
library for AMQP implementation.
Many of Our customers are reporting this issue and would highly appreciate your
response.
We are basically hitting this TODO in the TransportImpl.java - which results in
reactor teardown:
[https://github.com/apache/qpid-proton-j/blob/master/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/TransportImpl.java#L1160]
Here's the Exception stack trace:
{color:#24292e}com.microsoft.azure.eventhubs.impl.MessagingFactory$RunReactor.run:487
messagingFactory[MessagingFactoryab1d8d],
hostName[NNN.servicebus.windows.net], error[UnHandled exception while
processing events in reactor:{color}
{color:#24292e} java.lang.NullPointerException: uncorrelated channel: 3{color}
{color:#24292e}
org.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:112){color}
{color:#24292e}
org.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:324){color}
{color:#24292e}
org.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:292){color}
{color:#24292e}
com.microsoft.azure.eventhubs.impl.MessagingFactory$RunReactor.run(MessagingFactory.java:462){color}
here's how to reproduce this error:
* configure the listener - to delay respond to session.begins for ex: by 5 secs
* then client (or another peer) sends session.begin
* client doesn't receive any response even after 1 sec
* then the client decides to close the session
* then, after few sec's service(listener) responds back with session.begin
> NullPointerException while handing remote session.begin in TransportImpl
>
>
> Key: PROTON-1939
> URL: https://issues.apache.org/jira/browse/PROTON-1939
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Affects Versions: proton-j-0.29.0
> Environment: Any environment
>Reporter: Sreeram Garlapati
>Priority: Major
> Fix For: proton-j-0.30.0
>
>
> Our library (Microsoft Azure EventHubs java sdk) take a dependency on
> proton-j library for AMQP implementation.
> Many of Our customers are reporting this issue and would highly appreciate
> your response.
>
> We are basically hitting this TODO in the TransportImpl.java - which results
> in reactor teardown:
> [https://github.com/apache/qpid-proton-j/blob/master/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/TransportImpl.java#L1160]
>
> Here's the Exception stack trace:
>
> {color:#24292e}com.microsoft.azure.eventhubs.impl.MessagingFactory$RunReactor.run:487
> messagingFactory[MessagingFactoryab1d8d],
> hostName[NNN.servicebus.windows.net], error[UnHandled exception while
> processing events in reactor:{color}
> {color:#24292e} java.lang.NullPointerExcep
[jira] [Created] (PROTON-1939) NullPointerException while handing remote session.begin in TransportImpl
Sreeram Garlapati created PROTON-1939:
-
Summary: NullPointerException while handing remote session.begin
in TransportImpl
Key: PROTON-1939
URL: https://issues.apache.org/jira/browse/PROTON-1939
Project: Qpid Proton
Issue Type: Bug
Components: proton-j
Affects Versions: proton-j-0.29.0
Environment: Any environment
Reporter: Sreeram Garlapati
Fix For: proton-j-0.30.0
Our library (Microsoft Azure EventHubs java sdk) take a dependency on proton-j
library for AMQP implementation.
Many of Our customers are reporting this issue and would highly appreciate your
response.
We are basically hitting this TODO in the TransportImpl.java - which results in
reactor teardown:
[https://github.com/apache/qpid-proton-j/blob/master/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/TransportImpl.java#L1160]
Here's the Exception stack trace:
{color:#24292e}com.microsoft.azure.eventhubs.impl.MessagingFactory$RunReactor.run:487
messagingFactory[MessagingFactoryab1d8d],
hostName[NNN.servicebus.windows.net], error[UnHandled exception while
processing events in reactor:{color}
{color:#24292e} java.lang.NullPointerException: uncorrelated channel: 3{color}
{color:#24292e}
org.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:112){color}
{color:#24292e}
org.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:324){color}
{color:#24292e}
org.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:292){color}
{color:#24292e}
com.microsoft.azure.eventhubs.impl.MessagingFactory$RunReactor.run(MessagingFactory.java:462){color}
here's how to reproduce this error:
* configure the listener - to delay respond to session.begins for ex: by 5 secs
* then client (or another peer) sends session.begin
* client doesn't receive any response even after 1 sec
* then the client decides to close the session
* then, after few sec's service(listener) responds back with session.begin
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1126) ERROR Attempt to attach too many inter-router links for priority sheaf.
Chuck Rolke created DISPATCH-1126: - Summary: ERROR Attempt to attach too many inter-router links for priority sheaf. Key: DISPATCH-1126 URL: https://issues.apache.org/jira/browse/DISPATCH-1126 Project: Qpid Dispatch Issue Type: Bug Components: Router Node Affects Versions: 1.3.0 Environment: Fedora 28 * Three router network in linear arrangement A - B - C. * B has a listener; A and C connect to it Reporter: Chuck Rolke Attachments: taj-GRN.log Some state probably not cleaned up when router connections are lost. 10 messages (error) Attempt to attach too many inter-router links for priority sheaf. appear when routers reconnect. Start the network. Then kill routers A and C and restart them. Router B prints the messages. Log file attached -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1126) ERROR Attempt to attach too many inter-router links for priority sheaf.
[ https://issues.apache.org/jira/browse/DISPATCH-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1126: -- Attachment: taj-GRN.log > ERROR Attempt to attach too many inter-router links for priority sheaf. > --- > > Key: DISPATCH-1126 > URL: https://issues.apache.org/jira/browse/DISPATCH-1126 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.3.0 > Environment: Fedora 28 > * Three router network in linear arrangement A - B - C. > * B has a listener; A and C connect to it > >Reporter: Chuck Rolke >Priority: Major > Attachments: taj-GRN.log > > > Some state probably not cleaned up when router connections are lost. 10 > messages > (error) Attempt to attach too many inter-router links for priority sheaf. > appear when routers reconnect. > Start the network. Then kill routers A and C and restart them. Router B > prints the messages. > Log file attached -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton pull request #158: PROTON-1937: Use value.type() to check for va...
GitHub user ChugR opened a pull request: https://github.com/apache/qpid-proton/pull/158 PROTON-1937: Use value.type() to check for value presence or absence This works for me on Fedroa 27 and 28 You can merge this pull request into a Git repository by running: $ git pull https://github.com/ChugR/qpid-proton PROTON-1937 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/158.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #158 commit ef657e67443e067d9fc74920960e6ce99c65f07c Author: Chuck Rolke Date: 2018-09-21T20:39:33Z PROTON-1937: Use value.type() to check for value presence or absence --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1937) Json::Value conversion error at build time
[
https://issues.apache.org/jira/browse/PROTON-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16624151#comment-16624151
]
ASF GitHub Bot commented on PROTON-1937:
GitHub user ChugR opened a pull request:
https://github.com/apache/qpid-proton/pull/158
PROTON-1937: Use value.type() to check for value presence or absence
This works for me on Fedroa 27 and 28
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ChugR/qpid-proton PROTON-1937
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/qpid-proton/pull/158.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #158
commit ef657e67443e067d9fc74920960e6ce99c65f07c
Author: Chuck Rolke
Date: 2018-09-21T20:39:33Z
PROTON-1937: Use value.type() to check for value presence or absence
> Json::Value conversion error at build time
> --
>
> Key: PROTON-1937
> URL: https://issues.apache.org/jira/browse/PROTON-1937
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.25.0
> Environment: Fedora 27, GNU C 7.3.1, JsonCpp 1.8.3
>Reporter: Chuck Rolke
>Priority: Major
> Attachments: proton-5595c-build.txt
>
>
> {{connect_config.cpp:73:15: error:}}
> {{could not convert ‘obj’ from ‘const Json::Value’ to ‘bool’}}
>
> Full build long attached
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1938) Transport error condition falsely pretends to be ConnectionError.FRAMING_ERROR
[ https://issues.apache.org/jira/browse/PROTON-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sreeram Garlapati updated PROTON-1938: -- Description: Although at various places in proton library - transport.setCondition() was invoked (for ex: IOHandler.java - invokes several places to communicate socket IOExceptions) - this was overwritten in TransportImpl.closed method and shows up as - ConnectionError.FRAMING_ERROR. I created this PR: to help easily identify - where the problem was: [https://github.com/apache/qpid-proton-j/pull/16] Please let me know if you need more info or have any inputs finishing the PR at sreer...@microsoft.com... was: Although at various places in proton library - transport.setCondition() was invoked (for ex: IOHandler.java - invokes several places to communicate socket IOExceptions) - this was overwritten in TransportImpl.closed method and shows up as - ConnectionError.FRAMING_ERROR. [https://github.com/apache/qpid-proton-j/pull/16] > Transport error condition falsely pretends to be ConnectionError.FRAMING_ERROR > -- > > Key: PROTON-1938 > URL: https://issues.apache.org/jira/browse/PROTON-1938 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: proton-j-0.29.0 >Reporter: Sreeram Garlapati >Priority: Minor > Fix For: proton-j-0.30.0 > > > Although at various places in proton library - transport.setCondition() was > invoked (for ex: IOHandler.java - invokes several places to communicate > socket IOExceptions) - this was overwritten in TransportImpl.closed method > and shows up as - ConnectionError.FRAMING_ERROR. > I created this PR: to help easily identify - where the problem was: > [https://github.com/apache/qpid-proton-j/pull/16] > Please let me know if you need more info or have any inputs finishing the PR > at sreer...@microsoft.com... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #157: WIP: extract connection_options_impl for tests and i...
Github user alanconway commented on the issue:
https://github.com/apache/qpid-proton/pull/157
On Fri, Sep 21, 2018 at 11:28 AM Andrew Stitcher
wrote:
> Honestly given the alternative, adding gets for the options seems fairly
> innocuous!
>
> To be (a little) less flippant Unit testing is actually a good reason to
> make the options readable too. Although I'm not sure if this is a good
idea
> for password though.
>
It shall be done.
On password - proton overwrites the password memory once it's been written
to the wire to void it hanging around in core dumps. Can we ever do this in
options, or does reconnect rely on options holding on to the password? We
could erase if reconnect is not enabled...
> I think the original reason for not making the options readable was that
> it was unecessary as the client program should know what options it set,
> but unit testing is important too.
>
I have a proposal for making it useful to users too:
void listen_handler::listen(listener&, connection_options&) {
// examine incoming connection info - e.g. virtual_host
// set further options for open response
}
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1927) Python _reactor.py creates duplicate link names for senders/receivers
[ https://issues.apache.org/jira/browse/PROTON-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16623922#comment-16623922 ] Alan Conway edited comment on PROTON-1927 at 9/21/18 5:32 PM: -- If name=None create_receiver is supposed to create a unique link ID. The problem is that python (unlike other bindings) generates a name from the container-id, source and target. So making 2 links between the same source/target fails Instead python should be generating a unique id like "container-id", similar to other bindings. was (Author: aconway): If name=create_receiver is supposed to create a unique link ID. The problem is that python (unlike other bindings) generates a name from the container-id, source and target. So making 2 links between the same source/target fails Instead python should be generating a unique id like "container-id", similar to other bindings. > Python _reactor.py creates duplicate link names for senders/receivers > - > > Key: PROTON-1927 > URL: https://issues.apache.org/jira/browse/PROTON-1927 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.24.0 >Reporter: Chuck Rolke >Priority: Major > > From DISPATCH-1114 > Creating a sender and a receiver in the same container produces duplicate > link names. Try python/examples/helloworld.py that executes: > event.container.create_receiver(conn, self.address) > event.container.create_sender(conn, self.address) > generates the same link name for each attach: > (M=a1b7d *1 ?3) chug@ratchet examples> PN_TRACE_FRM=1 ./helloworld.py > ... > [0x55a01066d9a0]:0 -> @attach(18) > [name="70ceeac8-50d8-4af2-9caf-20ef8700a7d3-examples", handle=0, role=true, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="examples", > durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, > timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] > [0x55a01066d9a0]:0 -> @attach(18) > [name="70ceeac8-50d8-4af2-9caf-20ef8700a7d3-examples", handle=1, role=false, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, > timeout=0, dynamic=false], target=@target(41) [address="examples", durable=0, > timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1927) Python _reactor.py creates duplicate link names for senders/receivers
[ https://issues.apache.org/jira/browse/PROTON-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16623922#comment-16623922 ] Alan Conway commented on PROTON-1927: - If name=create_receiver is supposed to create a unique link ID. The problem is that python (unlike other bindings) generates a name from the container-id, source and target. So making 2 links between the same source/target fails Instead python should be generating a unique id like "container-id", similar to other bindings. > Python _reactor.py creates duplicate link names for senders/receivers > - > > Key: PROTON-1927 > URL: https://issues.apache.org/jira/browse/PROTON-1927 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.24.0 >Reporter: Chuck Rolke >Priority: Major > > From DISPATCH-1114 > Creating a sender and a receiver in the same container produces duplicate > link names. Try python/examples/helloworld.py that executes: > event.container.create_receiver(conn, self.address) > event.container.create_sender(conn, self.address) > generates the same link name for each attach: > (M=a1b7d *1 ?3) chug@ratchet examples> PN_TRACE_FRM=1 ./helloworld.py > ... > [0x55a01066d9a0]:0 -> @attach(18) > [name="70ceeac8-50d8-4af2-9caf-20ef8700a7d3-examples", handle=0, role=true, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="examples", > durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, > timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] > [0x55a01066d9a0]:0 -> @attach(18) > [name="70ceeac8-50d8-4af2-9caf-20ef8700a7d3-examples", handle=1, role=false, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, > timeout=0, dynamic=false], target=@target(41) [address="examples", durable=0, > timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1927) Python _reactor.py creates duplicate link names for senders/receivers
[ https://issues.apache.org/jira/browse/PROTON-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16623912#comment-16623912 ] Justin Ross commented on PROTON-1927: - Some agreed points: - This behavior is wrong - We need to find out if it extends beyond Python > Python _reactor.py creates duplicate link names for senders/receivers > - > > Key: PROTON-1927 > URL: https://issues.apache.org/jira/browse/PROTON-1927 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.24.0 >Reporter: Chuck Rolke >Priority: Major > > From DISPATCH-1114 > Creating a sender and a receiver in the same container produces duplicate > link names. Try python/examples/helloworld.py that executes: > event.container.create_receiver(conn, self.address) > event.container.create_sender(conn, self.address) > generates the same link name for each attach: > (M=a1b7d *1 ?3) chug@ratchet examples> PN_TRACE_FRM=1 ./helloworld.py > ... > [0x55a01066d9a0]:0 -> @attach(18) > [name="70ceeac8-50d8-4af2-9caf-20ef8700a7d3-examples", handle=0, role=true, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="examples", > durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, > timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] > [0x55a01066d9a0]:0 -> @attach(18) > [name="70ceeac8-50d8-4af2-9caf-20ef8700a7d3-examples", handle=1, role=false, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, > timeout=0, dynamic=false], target=@target(41) [address="examples", durable=0, > timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1125) AMQP framing errors on forwarded multicast messages
[ https://issues.apache.org/jira/browse/DISPATCH-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1125: -- Attachment: DISPATCH-1125.txt > AMQP framing errors on forwarded multicast messages > --- > > Key: DISPATCH-1125 > URL: https://issues.apache.org/jira/browse/DISPATCH-1125 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.3.0 >Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1125.txt > > > These errors show up using the same setup described in DISPATCH-1124. > A three-router linear network uses a wireless connection for the interrouter > links. > Messages are injected into a router at one end of the chain and are forwarded > to receivers on the other two routers. > * The receiver attached to the router in the middle may receive tens of > millions of messages before getting an underflow. > * The receiver attached to the router at the far end of the chain may file > as soon as 25 messages or as late as several thousand messages. > * Messages are text strings 1,443 bytes long > Some observations: > * Normal transfer frames have transport size of 0x5ec bytes. > * Messages that fail with underrun commonly have a size of 0x1aa bytes. It > is not always 0x1aa but that number shows up in consecutive runs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1125) AMQP framing errors on forwarded multicast messages
[ https://issues.apache.org/jira/browse/DISPATCH-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16623902#comment-16623902 ] Chuck Rolke commented on DISPATCH-1125: --- The issue appears to be rooted in a race condition when a message has multiple destinations. Another observation was: * if there was no receiver on the middle router then the middle router would forward milliions of messages across the network no problem * as soon as the receiver was added then the problem would reappear After extensive logging the error pattern emerged. * A message bound for two destinations arrives * The message is copied and sent to the first destination * The whole message is sent to the first destination. Since there is no other destination yet the message buffers are freed as they are sent. * The message is copied again for the second destination. * The first buffer is sent to the second destination but that buffer is in the free list. After sending the first buffer the send function marches off sending buffers in the free list. See attached log file. > AMQP framing errors on forwarded multicast messages > --- > > Key: DISPATCH-1125 > URL: https://issues.apache.org/jira/browse/DISPATCH-1125 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.3.0 >Reporter: Chuck Rolke >Priority: Major > > These errors show up using the same setup described in DISPATCH-1124. > A three-router linear network uses a wireless connection for the interrouter > links. > Messages are injected into a router at one end of the chain and are forwarded > to receivers on the other two routers. > * The receiver attached to the router in the middle may receive tens of > millions of messages before getting an underflow. > * The receiver attached to the router at the far end of the chain may file > as soon as 25 messages or as late as several thousand messages. > * Messages are text strings 1,443 bytes long > Some observations: > * Normal transfer frames have transport size of 0x5ec bytes. > * Messages that fail with underrun commonly have a size of 0x1aa bytes. It > is not always 0x1aa but that number shows up in consecutive runs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #157: WIP: extract connection_options_impl for tests and i...
Github user astitcher commented on the issue: https://github.com/apache/qpid-proton/pull/157 Honestly given the alternative, adding gets for the options seems fairly innocuous! To be (a little) less flippant Unit testing is actually a good reason to make the options readable too. Although I'm not sure if this is a good idea for password though. I think the original reason for not making the options readable was that it was unecessary as the client program should know what options it set, but unit testing is important too. Perhaps an alternative would be a "dump" method for the options (akin to ```pn_inspect()``` or __str__) which outputs the options in json for comparison although you'd have to parse it and compare to be safe. But hey you've got a json parser linked in anyway! --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #157: WIP: extract connection_options_impl for tests and i...
Github user alanconway commented on the issue: https://github.com/apache/qpid-proton/pull/157 I want to unit test connection_config::parse by parsing various configs into connection_options, and then verifying that the connection_options receives the correct values. connection_options public API is set-only, no gets. I considered adding public get methods, if you think that's a good idea too I'll do that. Otherwise the only thing you can do with connaction_options is apply them to a connection. The connection, transport, sasl and ssl objects also have mostly set-only interfaces, so that doesn't help. I could write test to verify the *effects* of the values by making a connection, but I would much rather test parser as a unit, independently of tests for SASL/TLS functionality. Currently there are no tests for SASL or TLS except the examples, I don't think connection parser tests are the right place to add them. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton pull request #:
Github user jdanekrh commented on the pull request: https://github.com/apache/qpid-proton/commit/3dd3bd4913af915d1632fed57c350d76a5cd0ba2#commitcomment-30590156 In ruby/lib/core/connection.rb: In ruby/lib/core/connection.rb on line 117: @ssorj there is overrun line here in doc comment, it causes `file` to report different file type than in 0.24 release (now it is ASCII "with very long lines"), which causes RPMDiff waring. Don't know how multiline rdoc comments work in Ruby, but if it is possible, maybe it would be worth it to format this more nicely. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
