[jira] [Commented] (DISPATCH-2310) Enforce a limit to the length of a router's id
[ https://issues.apache.org/jira/browse/DISPATCH-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488423#comment-17488423 ] ASF GitHub Bot commented on DISPATCH-2310: -- jiridanek edited a comment on pull request #1511: URL: https://github.com/apache/qpid-dispatch/pull/1511#issuecomment-1031894498 I haven't fully appreciated I am commenting on a backport PR :facepalm: -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Enforce a limit to the length of a router's id > -- > > Key: DISPATCH-2310 > URL: https://issues.apache.org/jira/browse/DISPATCH-2310 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > Do not allow router id names of > 255 characters. > 255 characters should be enough for everybody. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2310) Enforce a limit to the length of a router's id
[ https://issues.apache.org/jira/browse/DISPATCH-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488422#comment-17488422 ] ASF GitHub Bot commented on DISPATCH-2310: -- jiridanek commented on pull request #1511: URL: https://github.com/apache/qpid-dispatch/pull/1511#issuecomment-1031894498 I haven't realized I am commenting on a backport PR :facepalm: -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Enforce a limit to the length of a router's id > -- > > Key: DISPATCH-2310 > URL: https://issues.apache.org/jira/browse/DISPATCH-2310 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > Do not allow router id names of > 255 characters. > 255 characters should be enough for everybody. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] jiridanek edited a comment on pull request #1511: DISPATCH-2310: limit router identifiers to 255 characters
jiridanek edited a comment on pull request #1511: URL: https://github.com/apache/qpid-dispatch/pull/1511#issuecomment-1031894498 I haven't fully appreciated I am commenting on a backport PR :facepalm: -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] jiridanek commented on pull request #1511: DISPATCH-2310: limit router identifiers to 255 characters
jiridanek commented on pull request #1511: URL: https://github.com/apache/qpid-dispatch/pull/1511#issuecomment-1031894498 I haven't realized I am commenting on a backport PR :facepalm: -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-2310) Enforce a limit to the length of a router's id
[ https://issues.apache.org/jira/browse/DISPATCH-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-2310. -- Resolution: Fixed Set max length to 127 - ensures str8-utf8 can hold a node id even after we've translated it to include a domain. > Enforce a limit to the length of a router's id > -- > > Key: DISPATCH-2310 > URL: https://issues.apache.org/jira/browse/DISPATCH-2310 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > Do not allow router id names of > 255 characters. > 255 characters should be enough for everybody. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2310) Enforce a limit to the length of a router's id
[ https://issues.apache.org/jira/browse/DISPATCH-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488418#comment-17488418 ] ASF subversion and git services commented on DISPATCH-2310: --- Commit 1f384f7a038a27987016e4ddbaa23d919bc87a37 in qpid-dispatch's branch refs/heads/main from Ken Giusti [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=1f384f7 ] DISPATCH-2310: limit router identifiers to 127 characters maximum > Enforce a limit to the length of a router's id > -- > > Key: DISPATCH-2310 > URL: https://issues.apache.org/jira/browse/DISPATCH-2310 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > Do not allow router id names of > 255 characters. > 255 characters should be enough for everybody. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2310) Enforce a limit to the length of a router's id
[ https://issues.apache.org/jira/browse/DISPATCH-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488419#comment-17488419 ] ASF GitHub Bot commented on DISPATCH-2310: -- asfgit merged pull request #1511: URL: https://github.com/apache/qpid-dispatch/pull/1511 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Enforce a limit to the length of a router's id > -- > > Key: DISPATCH-2310 > URL: https://issues.apache.org/jira/browse/DISPATCH-2310 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.19.0 > > > Do not allow router id names of > 255 characters. > 255 characters should be enough for everybody. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] asfgit merged pull request #1511: DISPATCH-2310: limit router identifiers to 255 characters
asfgit merged pull request #1511: URL: https://github.com/apache/qpid-dispatch/pull/1511 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPIDJMS-563) QPID JMS - Failover - endless loop on sending a message with reject outcome
[ https://issues.apache.org/jira/browse/QPIDJMS-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488161#comment-17488161 ] Robbie Gemmell edited comment on QPIDJMS-563 at 2/7/22, 2:56 PM: - There is a 'jms.sendTimeout' URI option setting which applies a time out each individual send attempt by a live underlying producer, and also has some related handling for the time spent awaiting a new connection during failover before a send attempt can occur. I thought perhaps you could use that to work around this particular unexpected server behaviour, however in considering furhter how it operates I think since the connection _does_ actually succeed in being reestablished in this case and it does a send that it wont be effective, as send request will occur and will get explicitly failed as the connection is killed, and the connection drops+reestablishes succesfully, it will thus cancel the awaiting-failover handling process, and since that will happen essentially immediately each time it drops+reconnects it will likely never actually run that process. Unless perhaps that is, you _also_ set the 'failover.reconnectDelay' option _and_ ensure it has a _higher_ value than the 'jms.sendTimeout', meaning it doesnt even try reconnecting+sending again after a drop until after the awaiting-failover process has had chance to kill the waiting send request before a reconnection stops it (this obviously that may limit you in terms of what you reasonably want to set the two values to). was (Author: gemmellr): There is a 'jms.sendTimeout' URI option setting which applies a time out each individual send attempt by a live underlying producer, and also has some related handling for the time spent awaiting a new connection during failover before a send attempt can occur. I thought perhaps you could use that to work around this particular unexpected server behaviour, however in considering furhter how it operates I think since the connection _does_ actually succeed in being reestablished in this case and it does a send that it wont be effective, as send request will occur and will get explicitly failed as the connection is killed, and the connection drops+reestablishes succesfully, it will thus cancel the awaiting-failover handling process, and since that will happen essentially immediately each time it drops+reconnects it will likely never actually run that process. Unless perhaps that is, you _also_ set the 'failover.reconnectDelay' option and ensure it has a _higher_ value than the jms.sendTimeout, meaning it doesnt even try reconnecting+sending again after a drop until after the awaiting-failover process has had chance to kill the waiting send request before a reconnection stops it (this obviously that may limit you in terms of what you reasonably want to set the two values to). > QPID JMS - Failover - endless loop on sending a message with reject outcome > --- > > Key: QPIDJMS-563 > URL: https://issues.apache.org/jira/browse/QPIDJMS-563 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 1.5.0 >Reporter: Thomas Stollenwerk >Priority: Critical > > +*Summary:*+ > Having a amqp v1 message which is rejected by the amqp v1 broker results in > an endless failover loop blocking the JmsMessageProducer.send method. > +*Expected:*+ > The failover of the qpid jms client tries to connect and send the rejected > message in a maximum of failover.maxReconnectAttempts. > +*Actual:*+ > The result of the message send task is not taken into account for counting > the attempts. > The JmsMessageProducer.send gets stuck forever. > # Failover connects to the failover uri and then resets the attempt counter. > # Sending the message results in REJECT outcome. > # Failover connects to the next failover uri and then resets the attempt > counter. > # Sending the message results in REJECT outcome. > # ... repeats and does not stop on maxReconnectAttempts. > +*Code analysis:*+ > *FailoverProvider.java#L1282* already resets the connection attempts with > *reconnectControl.connectionEstablished()* not waiting for the success of the > send task, resulting in an endless failover loop. > +*Background:*+ > In our case we are using RabbitMQ with the amqp v1 plugin. There are > scenarios where the broker is answering with REJECT outcomes (overflow > policy, high watermark etc). Right now we cannot use this feature because the > client is stuck and the RabbitMQ is flooded with reconnects. > We would be very grateful having a fix. > Thanks for the good work and best regards > Thomas > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To
[jira] [Commented] (QPIDJMS-563) QPID JMS - Failover - endless loop on sending a message with reject outcome
[ https://issues.apache.org/jira/browse/QPIDJMS-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488161#comment-17488161 ] Robbie Gemmell commented on QPIDJMS-563: There is a 'jms.sendTimeout' URI option setting which applies a time out each individual send attempt by a live underlying producer, and also has some related handling for the time spent awaiting a new connection during failover before a send attempt can occur. I thought perhaps you could use that to work around this particular unexpected server behaviour, however in considering furhter how it operates I think since the connection _does_ actually succeed in being reestablished in this case and it does a send that it wont be effective, as send request will occur and will get explicitly failed as the connection is killed, and the connection drops+reestablishes succesfully, it will thus cancel the awaiting-failover handling process, and since that will happen essentially immediately each time it drops+reconnects it will likely never actually run that process. Unless perhaps that is, you _also_ set the 'failover.reconnectDelay' option and ensure it has a _higher_ value than the jms.sendTimeout, meaning it doesnt even try reconnecting+sending again after a drop until after the awaiting-failover process has had chance to kill the waiting send request before a reconnection stops it (this obviously that may limit you in terms of what you reasonably want to set the two values to). > QPID JMS - Failover - endless loop on sending a message with reject outcome > --- > > Key: QPIDJMS-563 > URL: https://issues.apache.org/jira/browse/QPIDJMS-563 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 1.5.0 >Reporter: Thomas Stollenwerk >Priority: Critical > > +*Summary:*+ > Having a amqp v1 message which is rejected by the amqp v1 broker results in > an endless failover loop blocking the JmsMessageProducer.send method. > +*Expected:*+ > The failover of the qpid jms client tries to connect and send the rejected > message in a maximum of failover.maxReconnectAttempts. > +*Actual:*+ > The result of the message send task is not taken into account for counting > the attempts. > The JmsMessageProducer.send gets stuck forever. > # Failover connects to the failover uri and then resets the attempt counter. > # Sending the message results in REJECT outcome. > # Failover connects to the next failover uri and then resets the attempt > counter. > # Sending the message results in REJECT outcome. > # ... repeats and does not stop on maxReconnectAttempts. > +*Code analysis:*+ > *FailoverProvider.java#L1282* already resets the connection attempts with > *reconnectControl.connectionEstablished()* not waiting for the success of the > send task, resulting in an endless failover loop. > +*Background:*+ > In our case we are using RabbitMQ with the amqp v1 plugin. There are > scenarios where the broker is answering with REJECT outcomes (overflow > policy, high watermark etc). Right now we cannot use this feature because the > client is stuck and the RabbitMQ is flooded with reconnects. > We would be very grateful having a fix. > Thanks for the good work and best regards > Thomas > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-563) QPID JMS - Failover - endless loop on sending a message with reject outcome
[ https://issues.apache.org/jira/browse/QPIDJMS-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488158#comment-17488158 ] Robbie Gemmell commented on QPIDJMS-563: For failover to be happening at all and for the described behaviour to occur, it sounds more like the _connection_ is being erroneously terminated by the server while it is 'rejecting' the message, and that it is not actually _rejecting the message_ as such at all. This really isnt expected protocol behaviour and rather defeats the point of being able to [n]ack the message itself (where actually rejected would probably be the wrong state to use as that is intended to mean the message is malformed, a modified-failed disposition to indicate deliver failure would probably be a more suited for the described cases). I'd suggest confirming what is actually happening via the protocol trace log [https://qpid.apache.org/releases/qpid-jms-1.5.0/docs/index.html#logging] and perhaps even other general trace/debug. Meanwhile, assuming that is the case, since the new connection created _has_ actually _succeeded_ in being created and senders etc been reestablished to get to the point of a send occurring, the reconnect counter is reset and work using the connection then continues, which leads to the send. The maxReconnectAttempts thus has no effect in limiting this odd scenario, since the _new_ underlying connection going down begins a fresh reconnect cycle which naturally has its own maxReconnectAttempts. In general there is no 'send retries counting' as the client does not generally resend (failover is the only instance it ever can) and even then sending is really considered _outwith_ the connection process and sends are expected to succeed/fail individually and not in the manner it seems may be getting used here of killing the whole connection. > QPID JMS - Failover - endless loop on sending a message with reject outcome > --- > > Key: QPIDJMS-563 > URL: https://issues.apache.org/jira/browse/QPIDJMS-563 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 1.5.0 >Reporter: Thomas Stollenwerk >Priority: Critical > > +*Summary:*+ > Having a amqp v1 message which is rejected by the amqp v1 broker results in > an endless failover loop blocking the JmsMessageProducer.send method. > +*Expected:*+ > The failover of the qpid jms client tries to connect and send the rejected > message in a maximum of failover.maxReconnectAttempts. > +*Actual:*+ > The result of the message send task is not taken into account for counting > the attempts. > The JmsMessageProducer.send gets stuck forever. > # Failover connects to the failover uri and then resets the attempt counter. > # Sending the message results in REJECT outcome. > # Failover connects to the next failover uri and then resets the attempt > counter. > # Sending the message results in REJECT outcome. > # ... repeats and does not stop on maxReconnectAttempts. > +*Code analysis:*+ > *FailoverProvider.java#L1282* already resets the connection attempts with > *reconnectControl.connectionEstablished()* not waiting for the success of the > send task, resulting in an endless failover loop. > +*Background:*+ > In our case we are using RabbitMQ with the amqp v1 plugin. There are > scenarios where the broker is answering with REJECT outcomes (overflow > policy, high watermark etc). Right now we cannot use this feature because the > client is stuck and the RabbitMQ is flooded with reconnects. > We would be very grateful having a fix. > Thanks for the good work and best regards > Thomas > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2310) Enforce a limit to the length of a router's id
[
https://issues.apache.org/jira/browse/DISPATCH-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488157#comment-17488157
]
ASF GitHub Bot commented on DISPATCH-2310:
--
jiridanek commented on a change in pull request #1511:
URL: https://github.com/apache/qpid-dispatch/pull/1511#discussion_r800731953
##
File path: include/qpid/dispatch/router.h
##
@@ -33,6 +33,8 @@
#include
+#define QD_ROUTER_ID_MAX 127 // max length of router id in chars
Review comment:
It's inconvenient that there is a C version and Python version of the
constant. Is the #define actually used anywhere? I can't find any usage in this
PR
##
File path: python/qpid_dispatch_internal/management/qdrouter.py
##
@@ -53,35 +54,43 @@ def validate_add(self, attributes, entities):
entities = list(entities) # Iterate twice
super(QdSchema, self).validate_add(attributes, entities)
entities.append(attributes)
-router_mode = listener_connector_role = listener_role = None
+router_mode = router_id = listener_connector_role = listener_role =
None
for e in entities:
short_type = self.short_name(e['type'])
if short_type == "router":
router_mode = e['mode']
+if 'id' in e:
+router_id = e['id']
Review comment:
```python
router_id = e.get('id')
```
https://docs.python.org/3/library/stdtypes.html#dict.get
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Enforce a limit to the length of a router's id
> --
>
> Key: DISPATCH-2310
> URL: https://issues.apache.org/jira/browse/DISPATCH-2310
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Router Node
>Affects Versions: 1.18.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.19.0
>
>
> Do not allow router id names of > 255 characters.
> 255 characters should be enough for everybody.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] jiridanek commented on a change in pull request #1511: DISPATCH-2310: limit router identifiers to 255 characters
jiridanek commented on a change in pull request #1511:
URL: https://github.com/apache/qpid-dispatch/pull/1511#discussion_r800731953
##
File path: include/qpid/dispatch/router.h
##
@@ -33,6 +33,8 @@
#include
+#define QD_ROUTER_ID_MAX 127 // max length of router id in chars
Review comment:
It's inconvenient that there is a C version and Python version of the
constant. Is the #define actually used anywhere? I can't find any usage in this
PR
##
File path: python/qpid_dispatch_internal/management/qdrouter.py
##
@@ -53,35 +54,43 @@ def validate_add(self, attributes, entities):
entities = list(entities) # Iterate twice
super(QdSchema, self).validate_add(attributes, entities)
entities.append(attributes)
-router_mode = listener_connector_role = listener_role = None
+router_mode = router_id = listener_connector_role = listener_role =
None
for e in entities:
short_type = self.short_name(e['type'])
if short_type == "router":
router_mode = e['mode']
+if 'id' in e:
+router_id = e['id']
Review comment:
```python
router_id = e.get('id')
```
https://docs.python.org/3/library/stdtypes.html#dict.get
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2310) Enforce a limit to the length of a router's id
[ https://issues.apache.org/jira/browse/DISPATCH-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488155#comment-17488155 ] ASF GitHub Bot commented on DISPATCH-2310: -- codecov-commenter edited a comment on pull request #1511: URL: https://github.com/apache/qpid-dispatch/pull/1511#issuecomment-1030988941 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/1511?src=pr=h1_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) Report > Merging [#1511](https://codecov.io/gh/apache/qpid-dispatch/pull/1511?src=pr=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (1f384f7) into [main](https://codecov.io/gh/apache/qpid-dispatch/commit/f9a1639edef75d15a6ef5d8e4b466fda900a6a8a?el=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (f9a1639) will **increase** coverage by `0.04%`. > The diff coverage is `n/a`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/1511?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) ```diff @@Coverage Diff @@ ## main#1511 +/- ## == + Coverage 84.86% 84.90% +0.04% == Files 117 117 Lines 2864328643 == + Hits2430724319 +12 + Misses 4336 4324 -12 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/1511?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) | Coverage Δ | | |---|---|---| | [src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1511/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=) | `93.86% <0.00%> (-0.64%)` | :arrow_down: | | [src/router\_core/route\_tables.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1511/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlX3RhYmxlcy5j) | `81.84% <0.00%> (-0.56%)` | :arrow_down: | | [src/hash.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1511/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL2hhc2guYw==) | `79.53% <0.00%> (-0.47%)` | :arrow_down: | | [src/adaptors/tcp\_adaptor.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1511/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL2FkYXB0b3JzL3RjcF9hZGFwdG9yLmM=) | `77.10% <0.00%> (-0.11%)` | :arrow_down: | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1511/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `94.10% <0.00%> (+0.19%)` | :arrow_up: | | [src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1511/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3BhcnNlLmM=) | `88.18% <0.00%> (+0.21%)` | :arrow_up: | | [src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1511/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=) | `89.76% <0.00%> (+0.76%)` | :arrow_up: | | [src/router\_core/modules/edge\_router/edge\_mgmt.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1511/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL21vZHVsZXMvZWRnZV9yb3V0ZXIvZWRnZV9tZ210LmM=) | `85.14% <0.00%> (+0.99%)` | :arrow_up: | | [...router\_core/modules/edge\_router/link\_route\_proxy.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1511/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL21vZHVsZXMvZWRnZV9yb3V0ZXIvbGlua19yb3V0ZV9wcm94eS5j) | `82.84% <0.00%> (+4.14%)` | :arrow_up: | -- [Continue to review full report at
[GitHub] [qpid-dispatch] codecov-commenter edited a comment on pull request #1511: DISPATCH-2310: limit router identifiers to 255 characters
codecov-commenter edited a comment on pull request #1511: URL: https://github.com/apache/qpid-dispatch/pull/1511#issuecomment-1030988941 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/1511?src=pr=h1_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) Report > Merging [#1511](https://codecov.io/gh/apache/qpid-dispatch/pull/1511?src=pr=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (1f384f7) into [main](https://codecov.io/gh/apache/qpid-dispatch/commit/f9a1639edef75d15a6ef5d8e4b466fda900a6a8a?el=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (f9a1639) will **increase** coverage by `0.04%`. > The diff coverage is `n/a`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/1511?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) ```diff @@Coverage Diff @@ ## main#1511 +/- ## == + Coverage 84.86% 84.90% +0.04% == Files 117 117 Lines 2864328643 == + Hits2430724319 +12 + Misses 4336 4324 -12 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/1511?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) | Coverage Δ | | |---|---|---| | [src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1511/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=) | `93.86% <0.00%> (-0.64%)` | :arrow_down: | | [src/router\_core/route\_tables.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1511/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlX3RhYmxlcy5j) | `81.84% <0.00%> (-0.56%)` | :arrow_down: | | [src/hash.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1511/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL2hhc2guYw==) | `79.53% <0.00%> (-0.47%)` | :arrow_down: | | [src/adaptors/tcp\_adaptor.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1511/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL2FkYXB0b3JzL3RjcF9hZGFwdG9yLmM=) | `77.10% <0.00%> (-0.11%)` | :arrow_down: | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1511/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `94.10% <0.00%> (+0.19%)` | :arrow_up: | | [src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1511/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3BhcnNlLmM=) | `88.18% <0.00%> (+0.21%)` | :arrow_up: | | [src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1511/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=) | `89.76% <0.00%> (+0.76%)` | :arrow_up: | | [src/router\_core/modules/edge\_router/edge\_mgmt.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1511/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL21vZHVsZXMvZWRnZV9yb3V0ZXIvZWRnZV9tZ210LmM=) | `85.14% <0.00%> (+0.99%)` | :arrow_up: | | [...router\_core/modules/edge\_router/link\_route\_proxy.c](https://codecov.io/gh/apache/qpid-dispatch/pull/1511/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL3JvdXRlcl9jb3JlL21vZHVsZXMvZWRnZV9yb3V0ZXIvbGlua19yb3V0ZV9wcm94eS5j) | `82.84% <0.00%> (+4.14%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/1511?src=pr=continue_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation). > **Legend** - [Click here to learn
[jira] [Created] (QPIDJMS-563) QPID JMS - Failover - endless loop on sending a message with reject outcome
Thomas Stollenwerk created QPIDJMS-563: -- Summary: QPID JMS - Failover - endless loop on sending a message with reject outcome Key: QPIDJMS-563 URL: https://issues.apache.org/jira/browse/QPIDJMS-563 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 1.5.0 Reporter: Thomas Stollenwerk +*Summary:*+ Having a amqp v1 message which is rejected by the amqp v1 broker results in an endless failover loop blocking the JmsMessageProducer.send method. +*Expected:*+ The failover of the qpid jms client tries to connect and send the rejected message in a maximum of failover.maxReconnectAttempts. +*Actual:*+ The result of the message send task is not taken into account for counting the attempts. The JmsMessageProducer.send gets stuck forever. # Failover connects to the failover uri and then resets the attempt counter. # Sending the message results in REJECT outcome. # Failover connects to the next failover uri and then resets the attempt counter. # Sending the message results in REJECT outcome. # ... repeats and does not stop on maxReconnectAttempts. +*Code analysis:*+ *FailoverProvider.java#L1282* already resets the connection attempts with *reconnectControl.connectionEstablished()* not waiting for the success of the send task, resulting in an endless failover loop. +*Background:*+ In our case we are using RabbitMQ with the amqp v1 plugin. There are scenarios where the broker is answering with REJECT outcomes (overflow policy, high watermark etc). Right now we cannot use this feature because the client is stuck and the RabbitMQ is flooded with reconnects. We would be very grateful having a fix. Thanks for the good work and best regards Thomas -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-broker-j] vavrtom merged pull request #117: Update maven download URL in AppVeyor
vavrtom merged pull request #117: URL: https://github.com/apache/qpid-broker-j/pull/117 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
