[jira] [Closed] (QPID-8579) [AMQP-J] main branch uses many insecure libs
[ https://issues.apache.org/jira/browse/QPID-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Godfrey closed QPID-8579. Resolution: Won't Fix > [AMQP-J] main branch uses many insecure libs > > > Key: QPID-8579 > URL: https://issues.apache.org/jira/browse/QPID-8579 > Project: Qpid > Issue Type: Improvement >Reporter: PJ Fanning >Priority: Major > > ``` > 1.2.3 > 27.0-jre > 2.10.4 > 4.5.3 > ``` > All of these have open CVEs > https://github.com/apache/qpid-jms-amqp-0-x/blob/main/pom.xml -- 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] (QPID-8579) [AMQP-J] main branch uses many insecure libs
[ https://issues.apache.org/jira/browse/QPID-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514797#comment-17514797 ] Robert Godfrey commented on QPID-8579: -- The qpid-jms-amqp-0-x component is no longer being actively developed. The last release was two years ago as version 6.4.0. The current Qpid JMS client is [Qpid JMS 1.5.0|https://qpid.apache.org/releases/qpid-jms-1.5.0/index.html] which you can find at github here: https://github.com/apache/qpid-jms/tree/1.5.0 > [AMQP-J] main branch uses many insecure libs > > > Key: QPID-8579 > URL: https://issues.apache.org/jira/browse/QPID-8579 > Project: Qpid > Issue Type: Improvement >Reporter: PJ Fanning >Priority: Major > > ``` > 1.2.3 > 27.0-jre > 2.10.4 > 4.5.3 > ``` > All of these have open CVEs > https://github.com/apache/qpid-jms-amqp-0-x/blob/main/pom.xml -- 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] (QPID-8557) [Broker-J] Batching mode for CoalescingCommitter
[
https://issues.apache.org/jira/browse/QPID-8557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17407248#comment-17407248
]
Robert Godfrey commented on QPID-8557:
--
Until the data is flushed to disk the fact that it is "committed" doesn't mean
that the commit can't be lost - that is the entire point of the flush to disk.
Only once the flush is confirmed can the broker be assured that the data /
commit will not be lost in the event of (for instance) a power failure.
Seeing 10 flushes for 10 messages for a single thread / single connection is
exactly what I would expect. With 10 separate connections/threads there will
be opportunities to combine the syncs which will optimise the time, but the
actual number of syncs will depend on small timing differences: the absolute
minimum would probably be approx 20 flushes, whereas the worst case would be
100, so the 42-79 range sounds about right.
The change you have proposed would be (in general) unsafe because it would
break the guarantees expected of the broker. There _may_ be cases (depending
on the version of AMQP you are using) where there are optimisations that the
broker currently doesn't make use of (particularly on publishing of messages to
the broker) which could speed those cases up but that would not be changes in
Coalescing Commiter but higher up in the model
> [Broker-J] Batching mode for CoalescingCommitter
>
>
> Key: QPID-8557
> URL: https://issues.apache.org/jira/browse/QPID-8557
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.5
>Reporter: Daniil Kirilyuk
>Priority: Minor
>
> Although QPID-8547 introduced configurable parameters for
> CoalescingCommitter, BDB log is flushed to disc on every message. That is
> caused by calling future.get() inside of
> org.apache.qpid.server.txn.AsyncCommand.complete(). Such call forces broker
> to wait until CoalescingCommiter calls #CommitThread#processJobs() making the
> operation effectively sync instead of async (every message triggers
> processJobs() and data flush).
> To improve overall performance we suggest to add batching mode for
> CoalescingCommitter, which would consider BDBVirtualHost parameters and flush
> data in chunks of size ${qpid.broker.bdbCommiterNotifyThreshold} or every
> ${qpid.broker.bdbCommiterWaitTimeout} ms (whatever comes first).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8557) [Broker-J] Batching mode for CoalescingCommitter
[
https://issues.apache.org/jira/browse/QPID-8557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17396016#comment-17396016
]
Robert Godfrey commented on QPID-8557:
--
how many concurrent producing threads were you using? Unless the code has been
broken I'm pretty confident that it will combine writes from multiple threads
(i.e. multiple distinct producing) clients into a single flush.
If you want to batch up writes from a single producer then use transactions
which will cause the flush only on the client request to commit the transaction.
Simply delaying the flushes to batch from single connection will (of course)
give much higher thoughput - but breaks the safety guarantees
> [Broker-J] Batching mode for CoalescingCommitter
>
>
> Key: QPID-8557
> URL: https://issues.apache.org/jira/browse/QPID-8557
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.5
>Reporter: Daniil Kirilyuk
>Priority: Minor
>
> Although QPID-8547 introduced configurable parameters for
> CoalescingCommitter, BDB log is flushed to disc on every message. That is
> caused by calling future.get() inside of
> org.apache.qpid.server.txn.AsyncCommand.complete(). Such call forces broker
> to wait until CoalescingCommiter calls #CommitThread#processJobs() making the
> operation effectively sync instead of async (every message triggers
> processJobs() and data flush).
> To improve overall performance we suggest to add batching mode for
> CoalescingCommitter, which would consider BDBVirtualHost parameters and flush
> data in chunks of size ${qpid.broker.bdbCommiterNotifyThreshold} or every
> ${qpid.broker.bdbCommiterWaitTimeout} ms (whatever comes first).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8557) [Broker-J] Batching mode for CoalescingCommitter
[
https://issues.apache.org/jira/browse/QPID-8557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17394621#comment-17394621
]
Robert Godfrey commented on QPID-8557:
--
{quote}Although QPID-8547 introduced configurable parameters for
CoalescingCommitter, BDB log is flushed to disc on every message. That is
caused by calling future.get() inside of
org.apache.qpid.server.txn.AsyncCommand.complete(). Such call forces broker to
wait until CoalescingCommiter calls #CommitThread#processJobs() making the
operation effectively sync instead of async{quote}
Coalescing committer does not flush on every message - the design of
CoalescingCommitter is to coalesce writes from concurrent threads. Since the
flush to disk is essentially single threaded, the coalescing committer allows
for parallelism (in practice thread0 will start a flush, threads 1-X will then
be queued up waiting and then will all commit in a coalesced flush).
The broker code is written with the understanding that by the time the commit
returns, the data is safely written to disk - so I'd be very concerned about
changing the behaviour here
> [Broker-J] Batching mode for CoalescingCommitter
>
>
> Key: QPID-8557
> URL: https://issues.apache.org/jira/browse/QPID-8557
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.5
>Reporter: Daniil Kirilyuk
>Priority: Minor
>
> Although QPID-8547 introduced configurable parameters for
> CoalescingCommitter, BDB log is flushed to disc on every message. That is
> caused by calling future.get() inside of
> org.apache.qpid.server.txn.AsyncCommand.complete(). Such call forces broker
> to wait until CoalescingCommiter calls #CommitThread#processJobs() making the
> operation effectively sync instead of async (every message triggers
> processJobs() and data flush).
> To improve overall performance we suggest to add batching mode for
> CoalescingCommitter, which would consider BDBVirtualHost parameters and flush
> data in chunks of size ${qpid.broker.bdbCommiterNotifyThreshold} or every
> ${qpid.broker.bdbCommiterWaitTimeout} ms (whatever comes first).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-8499) [Broker-J] Customized TrustManager bypasses certificate verification
[ https://issues.apache.org/jira/browse/QPID-8499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268498#comment-17268498 ] Robert Godfrey edited comment on QPID-8499 at 1/20/21, 10:39 AM: - My understanding of this trust store type was that its intended use was for checking certificates passed by connecting clients as part of a client certificate exchange. It is _not_ intended to be used in the case where the broker is making an outbound TLS connection. As such the certificate is really just acting as a "secret" rather than necessarily being tied to a valid DNS name, moreover when receiving a client certificate I'm not sure it really makes sense to worry about MITM attacks. It would make sense for the implementation to, in some way, indicate that it is not suitable for use as a truststore in the case where it is being used to check the certificate presented by a server on an outbound (from the perspective of the broker) connection, and prevent its use in this way. It should also (if it does not already) validate the current date lies within the start/end dates on the presented certificate . was (Author: rgodfrey): My understanding of this trust store type was that its intended use was for checking certificates passed by connecting clients as part of a client certificate exchange. It is _not_ intended to be used in the case where the broker is making an outbound TLS connection. As such the certificate is really just acting as a "secret" rather than necessarily being tied to a valid DNS name, moreover when receiving a client certificate I'm not sure it really makes sense to worry about MITM attacks. It would make sense for the implementation to, in some way, indicate that it is not suitable for use as a truststore in the case where it is being used to check the certificate presented by a server on an outbound (from the perspective of the broker) connection, and prevent its sed int his way. It should also (if it does not already) validate the current date lies within the start/end dates on the presented certificate . > [Broker-J] Customized TrustManager bypasses certificate verification > > > Key: QPID-8499 > URL: https://issues.apache.org/jira/browse/QPID-8499 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Ya Xiao >Priority: Major > > We found a security vulnerability in file > [qpid-broker-j/broker-core/src/main/java/org/apache/qpid/server/security/SiteSpecificTrustStoreImpl.java|https://github.com/apache/qpid-broker-j/blob/a70ed6f5edbcf0e8690447d48a1fe64e599cb703/broker-core/src/main/java/org/apache/qpid/server/security/SiteSpecificTrustStoreImpl.java]. > The customized TrustManger (at Line 339) allows all certificates to pass the > verification. > *Security Impact*: > The checkClientTrusted and checkServerTrusted methods are expected to > implement the certificate validation logic. Bypassing it could allow > man-in-the-middle attacks. > *Useful Resources*: > [https://cwe.mitre.org/data/definitions/295.html] > [https://developer.android.com/training/articles/security-ssl|https://developer.android.com/training/articles/security-ssl#SelfSigned] > *Solution we suggest:* > Do not customize the TrustManger or specify the certificate validation logic > instead of allowing all certificates. See > [here|https://developer.android.com/training/articles/security-ssl] to > securely allow self-signed certificates and other common cases. > *Please share with us your opinions/comments if there is any:* > Is the bug report helpful? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8496) Randomly hit "unknown QBB implementation" error
[ https://issues.apache.org/jira/browse/QPID-8496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268501#comment-17268501 ] Robert Godfrey commented on QPID-8496: -- Glad to hear that Robbie's supreme diagnosis skills led you to the root cause of your issue... and at the same time you've helped us identify a bug in the broker which Alex has now fixed :) > Randomly hit "unknown QBB implementation" error > --- > > Key: QPID-8496 > URL: https://issues.apache.org/jira/browse/QPID-8496 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.2, qpid-java-broker-8.0.3 >Reporter: Lisa Hong >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.4 > > Attachments: UnknownQBB_callstack, proton.log > > > Hi team, > I'm running qpid java broker with modelVersion8.0. And the client is > qpid-proton with python. Unfortunately, my producer will randomly hit this > "unknown QBB implementation" error thus failing with on_connection_error. > Could you please help to advice what could be the root cause? The error call > stack could be found from attachment. > I'm suspending some null buffer is provided for this > QpidByteBufferFactory.concatenate method. But I have no idea why it could > happen. Would you please help to figure out? Thank you so much! > *Proton client version: 0.32.0* > *Qpid broker J version: 8.0* > Regards, > Lisa -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8499) [Broker-J] Customized TrustManager bypasses certificate verification
[ https://issues.apache.org/jira/browse/QPID-8499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268498#comment-17268498 ] Robert Godfrey commented on QPID-8499: -- My understanding of this trust store type was that its intended use was for checking certificates passed by connecting clients as part of a client certificate exchange. It is _not_ intended to be used in the case where the broker is making an outbound TLS connection. As such the certificate is really just acting as a "secret" rather than necessarily being tied to a valid DNS name, moreover when receiving a client certificate I'm not sure it really makes sense to worry about MITM attacks. It would make sense for the implementation to, in some way, indicate that it is not suitable for use as a truststore in the case where it is being used to check the certificate presented by a server on an outbound (from the perspective of the broker) connection, and prevent its sed int his way. It should also (if it does not already) validate the current date lies within the start/end dates on the presented certificate . > [Broker-J] Customized TrustManager bypasses certificate verification > > > Key: QPID-8499 > URL: https://issues.apache.org/jira/browse/QPID-8499 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Ya Xiao >Priority: Major > > We found a security vulnerability in file > [qpid-broker-j/broker-core/src/main/java/org/apache/qpid/server/security/SiteSpecificTrustStoreImpl.java|https://github.com/apache/qpid-broker-j/blob/a70ed6f5edbcf0e8690447d48a1fe64e599cb703/broker-core/src/main/java/org/apache/qpid/server/security/SiteSpecificTrustStoreImpl.java]. > The customized TrustManger (at Line 339) allows all certificates to pass the > verification. > *Security Impact*: > The checkClientTrusted and checkServerTrusted methods are expected to > implement the certificate validation logic. Bypassing it could allow > man-in-the-middle attacks. > *Useful Resources*: > [https://cwe.mitre.org/data/definitions/295.html] > [https://developer.android.com/training/articles/security-ssl|https://developer.android.com/training/articles/security-ssl#SelfSigned] > *Solution we suggest:* > Do not customize the TrustManger or specify the certificate validation logic > instead of allowing all certificates. See > [here|https://developer.android.com/training/articles/security-ssl] to > securely allow self-signed certificates and other common cases. > *Please share with us your opinions/comments if there is any:* > Is the bug report helpful? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8496) Randomly hit "unknown QBB implementation" error
[ https://issues.apache.org/jira/browse/QPID-8496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264185#comment-17264185 ] Robert Godfrey commented on QPID-8496: -- Hi [~hlizza88], I would suggest that you turn on AMQP (protocol) logging both on the client and the broker. Given where the exception occurs in the broker code, I'd be pretty sure that the ultimate error is on the client side (i.e. it is sending an illegal message transfer instruction with no associated message data). The transfer is never reaching a queue so the type of the queue will not be a factor. The hearbeats between client and broker are a different instruction type to message transfer, so again that will not be a factor. Hope this helps, Rob > Randomly hit "unknown QBB implementation" error > --- > > Key: QPID-8496 > URL: https://issues.apache.org/jira/browse/QPID-8496 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.2 >Reporter: Lisa Hong >Priority: Major > Attachments: UnknownQBB_callstack > > > Hi team, > I'm running qpid java broker with modelVersion8.0. And the client is > qpid-proton with python. Unfortunately, my producer will randomly hit this > "unknown QBB implementation" error thus failing with on_connection_error. > Could you please help to advice what could be the root cause? The error call > stack could be found from attachment. > I'm suspending some null buffer is provided for this > QpidByteBufferFactory.concatenate method. But I have no idea why it could > happen. Would you please help to figure out? Thank you so much! > Regards, > Lisa -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8452) Message larger than 2GB
[
https://issues.apache.org/jira/browse/QPID-8452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17185116#comment-17185116
]
Robert Godfrey commented on QPID-8452:
--
{quote}The AMQP protocol specification states that the Data section of the
message is a byte array, which has the size limit 4 GB. The best possible
improvement is from 2 GB to 4 GB.{quote}
while an individual data section is limited to 4Gb, there is no limit to the
number of data sections used in an individual message - so, from an AMQP point
of view, message sizes are potentially unbounded.
bq. Broker utilizes the Java byte array and ByteBuffer that have the limit 2
GB. Broker uses the sign integer for data size, length, position and the sign
integer can index 2 GB of data at most.
bq.
bq. Fixing the issue would require an extensive change of the Broker. I would
suggest limiting the maximum message size that the broker can process to the 2
GB. Let the broker gracefully fail when client tries to send a message bigger
than 2 GB.
I'd agree that limiting the max message size to <=2GB is the sensible approach.
If the broker is sent a message which is greater than the maximum allowed
message size, it should detach the link, as defined
[here|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-attach]
> Message larger than 2GB
> ---
>
> Key: QPID-8452
> URL: https://issues.apache.org/jira/browse/QPID-8452
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.0
>Reporter: Tomas Soltys
>Priority: Minor
>
> Seems like there is a 2GB limitation for how big the message can be. This is
> most likely due to usage of Int type.
> Also, when this limit is reached no exception is raised nor any message is
> printed into a broker log and sender seems to keep waiting for
> acknowledgement.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8455) [Broker-J]Use allow/deny list terminology for existing attributes and context variables
[ https://issues.apache.org/jira/browse/QPID-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159926#comment-17159926 ] Robert Godfrey commented on QPID-8455: -- [~DedeepyaT] Thanks for your patch, but as per the discussion between myself and Alex above, we cannot just change the names without providing some way for existing users to maintain compatibility. Any patch / PR needs to take this into account - minimally by also incrementing the configuration model version and adding an upgrade step to the model upgraders to update the config files for existing users. > [Broker-J]Use allow/deny list terminology for existing attributes and context > variables > --- > > Key: QPID-8455 > URL: https://issues.apache.org/jira/browse/QPID-8455 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Dedeepya >Priority: Major > Fix For: qpid-java-broker-8.0.1, qpid-java-broker-7.1.9 > > Attachments: > 0001-QPID-8455-Broker-J-Use-allow-deny-list-terminology-f.patch > > > Rename attributes and context variables containing the term white/black list > to allow/deny list. > The names allow/deny list are more inlined with current industry naming > standards. > Example: > The port derived attributes tlsCipherSuiteWhiteList and > tlsCipherSuiteBlackList will have to be renamed to tlsCipherSuiteAllowList > and tlsCipherSuiteDenyList respectively. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8455) [Broker-J]Use allow/deny list terminology for existing attributes and context variables
[ https://issues.apache.org/jira/browse/QPID-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159176#comment-17159176 ] Robert Godfrey commented on QPID-8455: -- [~orudyy] Personally I think it's acceptable to simply do the renames on the master branch for the next release that comes off that, and leave the existing names on the older, maintenance, release streams. We should signal that allow/deny list are the correct terms going forward - but for historic releases we won't break compatibility. This is inline with the approach I seeing followed in other projects. > [Broker-J]Use allow/deny list terminology for existing attributes and context > variables > --- > > Key: QPID-8455 > URL: https://issues.apache.org/jira/browse/QPID-8455 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Dedeepya >Priority: Major > Fix For: qpid-java-broker-8.0.1, qpid-java-broker-7.1.9 > > > Rename attributes and context variables containing the term white/black list > to allow/deny list. > The names allow/deny list are more inlined with current industry naming > standards. > Example: > The port derived attributes tlsCipherSuiteWhiteList and > tlsCipherSuiteBlackList will have to be renamed to tlsCipherSuiteAllowList > and tlsCipherSuiteDenyList respectively. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8454) [Broker-J] Expose configured object statistics in prometheus format
[
https://issues.apache.org/jira/browse/QPID-8454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159065#comment-17159065
]
Robert Godfrey commented on QPID-8454:
--
[~orudyy] I've not thought *hugely* about this... but my gut instinct is that
the metric names are probably best defined as something like
qpid___. The suffix can be constructed from the
StatisticUnit and StatisticType, with added labels for the names of the parent
objects... e.g. qpid_queue_consumers_count {queue=myqueue, virtualhost=myhost
...}. I think we probably want to allow for the fine tuning of the prometheus
name through annotation meta data on the statistic ( metricname="consumers" )
... and also maybe a way of indicating whether it should even be exposed via
Prometheus
> [Broker-J] Expose configured object statistics in prometheus format
> ---
>
> Key: QPID-8454
> URL: https://issues.apache.org/jira/browse/QPID-8454
> Project: Qpid
> Issue Type: New Feature
> Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.1, qpid-java-broker-7.1.9
>
>
> The configured object statistics currently can be retrieved using a call to
> method {{getStatistics()}}, configured object REST API endpoint
> {{/api/latest//}} or query API (
> {{/api/latest/querybroker/}} or {{/api/latest/queryvhost/ host node name>//}} ). The statistics is
> returned back to the caller in json format. That works for majority of uses
> cases. However, when it is required to integrate Qpid Broker-J with
> Prometheus, the Qpid users are required to implement an intermediate layer
> where Qpid metrics needs to be converted into a Prometheus format
> [https://prometheus.io/docs/concepts/data_model/].
> In order to easy the burden of integration Qpid Broker-J with Prometheus, the
> support for reporting statistics metrics in Prometheus format can be added
> into Qpid Broker-J.
> Potentially, we can add an endpoint exposing all Qpid statistics as
> Prometheus metrics [https://prometheus.io/docs/concepts/metric_types/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8455) [Broker-J]Use allow/deny list terminology for existing attributes and context variables
[ https://issues.apache.org/jira/browse/QPID-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159045#comment-17159045 ] Robert Godfrey commented on QPID-8455: -- [~orudyy] I worry the "alternative names" could lead to a maintenance nightmare, and the code to support it could be quite complicated. (Theoretically you'd need to add logic to check that the alternative names are not also used by actual attributes, etc). For derived attributes / statistics I think it is probably good enough to simply add deprecated duplicate methods in using the old names (and remove these after 1 further release). For setting the values, I think it is cleaner to simply up the model version and do an upgrade (for the 7.x versions we'd need to do a 7.2 , and have an upgrader from 7.0 to 7.2 in that code line. In the 8.0 and main branches we'd need to have upgrades from 8.0 and 7.2 to an 8.1 version (which would preclude going from 7.2 to 8.0, but I think that is OK). Obviously if you want to go to the effort of adding some sort of alternative names mechanism, feel free to - but I think this will end up being fairly complicated - and I don't imagine that there are many places where these values are being dynamically set via the APIs on a frequent basis > [Broker-J]Use allow/deny list terminology for existing attributes and context > variables > --- > > Key: QPID-8455 > URL: https://issues.apache.org/jira/browse/QPID-8455 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Dedeepya >Priority: Major > Fix For: qpid-java-broker-8.0.1, qpid-java-broker-7.1.9 > > > Rename attributes and context variables containing the term white/black list > to allow/deny list. > The names allow/deny list are more inlined with current industry naming > standards. > Example: > The port derived attributes tlsCipherSuiteWhiteList and > tlsCipherSuiteBlackList will have to be renamed to tlsCipherSuiteAllowList > and tlsCipherSuiteDenyList respectively. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8454) [Broker-J] Expose configured object statistics in prometheus format
[
https://issues.apache.org/jira/browse/QPID-8454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158022#comment-17158022
]
Robert Godfrey commented on QPID-8454:
--
Are you thinking of a single endpoint per broker, or one per virtualhost? Are
we defining which labels the metric will be enhanced with (e.g.
queue_depth{name=myqueue, type=lvq} or something? (Using queues as an eample,
it seems to me that virtualhost is probably the logical place for the metric
endpoint, or else you will need to add a fully qualified name, or add labels
for the names of each of the parent types)
> [Broker-J] Expose configured object statistics in prometheus format
> ---
>
> Key: QPID-8454
> URL: https://issues.apache.org/jira/browse/QPID-8454
> Project: Qpid
> Issue Type: New Feature
> Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.1, qpid-java-broker-7.1.9
>
>
> The configured object statistics currently can be retrieved using a call to
> method {{getStatistics()}}, configured object REST API endpoint
> {{/api/latest//}} or query API (
> {{/api/latest/querybroker/}} or {{/api/latest/queryvhost/ host node name>//}} ). The statistics is
> returned back to the caller in json format. That works for majority of uses
> cases. However, when it is required to integrate Qpid Broker-J with
> Prometheus, the Qpid users are required to implement an intermediate layer
> where Qpid metrics needs to be converted into a Prometheus format
> [https://prometheus.io/docs/concepts/data_model/].
> In order to easy the burden of integration Qpid Broker-J with Prometheus, the
> support for reporting statistics metrics in Prometheus format can be added
> into Qpid Broker-J.
> Potentially, we can add an endpoint exposing all Qpid statistics as
> Prometheus metrics [https://prometheus.io/docs/concepts/metric_types/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8455) [Broker-J]Use allow/deny list terminology for existing attributes and context variables
[ https://issues.apache.org/jira/browse/QPID-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158016#comment-17158016 ] Robert Godfrey commented on QPID-8455: -- I agree with these needing to be fixed, but I think we have to do this as part of a new minor release (e.g. 8.1) where the system can also update existing configs as part of the upgrade process. If we don't do it as part of an update (with a built in upgrade process) then we will break people's existing configurations. > [Broker-J]Use allow/deny list terminology for existing attributes and context > variables > --- > > Key: QPID-8455 > URL: https://issues.apache.org/jira/browse/QPID-8455 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Dedeepya >Priority: Major > Fix For: qpid-java-broker-8.0.1, qpid-java-broker-7.1.9 > > > Rename attributes and context variables containing the term white/black list > to allow/deny list. > The names allow/deny list are more inlined with current industry naming > standards. > Example: > The port derived attributes tlsCipherSuiteWhiteList and > tlsCipherSuiteBlackList will have to be renamed to tlsCipherSuiteAllowList > and tlsCipherSuiteDenyList respectively. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8427) [Broker-J] Housekeeping task threw StackOverflowError
[
https://issues.apache.org/jira/browse/QPID-8427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17057986#comment-17057986
]
Robert Godfrey commented on QPID-8427:
--
This sounds a lot like QPID-8393 which was fixed in v7.1.7 I believe
> [Broker-J] Housekeeping task threw StackOverflowError
> -
>
> Key: QPID-8427
> URL: https://issues.apache.org/jira/browse/QPID-8427
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.5
>Reporter: Tomas Vavricka
>Priority: Major
>
> Broker crashed when performing housekeeping task.
> {noformat}
> 2020-03-10 20:14:41,539 ERROR [virtualhost-default-pool-1]
> (o.a.q.s.u.HousekeepingExecutor) - Housekeeping task threw an exception:
> java.lang.StackOverflowError: null
> at
> org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
> at
> org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
> at
> org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
> at
> org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
> at
> org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
> ...
> at
> org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
> at
> org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
> at
> org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
> at
> org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
> at
> org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
> at
> org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8346) [Broker-J][AMQP 1.0] Broker prematurely enqueues unsettled messages with "receiver-settle-mode" set to "second"
[
https://issues.apache.org/jira/browse/QPID-8346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051019#comment-17051019
]
Robert Godfrey commented on QPID-8346:
--
I'm still not sure I agree with this
bq. The message should be enqueued after settling the delivery.
The point of receiver settles second is to ensure exactly-once delivery
semantics. If the broker does not enqueue until after the sender settles then
it seems to me you risk the broker failing between the point after the point at
which the sender has settled, believe the message to have been irreversibly
transferred.
I do not see a good reason for the broker to delay the enqueue. The delivery
has occurred - the sender cannot undo this.
> [Broker-J][AMQP 1.0] Broker prematurely enqueues unsettled messages with
> "receiver-settle-mode" set to "second"
> ---
>
> Key: QPID-8346
> URL: https://issues.apache.org/jira/browse/QPID-8346
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.1, qpid-java-broker-7.1.0,
> qpid-java-broker-7.0.4, qpid-java-broker-7.0.5, qpid-java-broker-7.0.6,
> qpid-java-broker-7.0.7, qpid-java-broker-7.1.1, qpid-java-broker-7.1.2,
> qpid-java-broker-7.0.8, qpid-java-broker-7.1.3, qpid-java-broker-7.1.4
>Reporter: Alex Rudyy
>Priority: Major
>
> When a sender link attached with {{receiver-settle-mode}} = {{second}} sends
> not-settled message without using transaction, that message is enqueued
> immediately into a queue without waiting for the settlement from the sender.
> It is immediately available for the consumption.
> The message should be enqueued after settling the delivery.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8346) [Broker-J][AMQP 1.0] Broker erronously enqueues unsettled messages with "receiver-settle-mode" set to "second"
[
https://issues.apache.org/jira/browse/QPID-8346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050445#comment-17050445
]
Robert Godfrey commented on QPID-8346:
--
I think I disagree with the premise of this Jira - the fact that the sender has
spontaneously chosen a disposition other than Accepted is not, to me, something
that the Broker should care about. The settlement of the disposition is simply
an agreement that both sides can now forget about the delivery. I think a
Broker or other intermediary *could* decide to defer the actual enqueue until
settlement (as in it is legal behaviour), but to me this appears to be a less
useful semantic.
> [Broker-J][AMQP 1.0] Broker erronously enqueues unsettled messages with
> "receiver-settle-mode" set to "second"
> --
>
> Key: QPID-8346
> URL: https://issues.apache.org/jira/browse/QPID-8346
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.1, qpid-java-broker-7.1.0,
> qpid-java-broker-7.0.4, qpid-java-broker-7.0.5, qpid-java-broker-7.0.6,
> qpid-java-broker-7.0.7, qpid-java-broker-7.1.1, qpid-java-broker-7.1.2,
> qpid-java-broker-7.0.8, qpid-java-broker-7.1.3, qpid-java-broker-7.1.4
>Reporter: Alex Rudyy
>Priority: Major
>
> When a sender link attached with {{receiver-settle-mode}} = {{second}} sends
> not-settled message without using transaction, that message is enqueued
> immediately into a queue without waiting for the settlement from the sender.
> It is immediately available for the consumption.
> The message enqueing should be delayed until receiving disposition settling
> the delivery and the delivery outcome is evaluated to {{Accepted}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2108) supported source outcomes not set
[ https://issues.apache.org/jira/browse/PROTON-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046475#comment-17046475 ] Robert Godfrey commented on PROTON-2108: To start with something I think we can all agree on bq. However I doubt anyone will be helped by clarification in a spec erratum at this point. +1 :-) As a bit of background here, I think the thought processes (such as they were, and digging up from my cloudy memory) were that there wasn't any sort of agreement about which outcomes implementations would actually be capable of supporting amongst reject/release/modify, and so the lowest common denominator was chosen - everything always has to support accepted, and that the ability to support more than that needs to be advertised. > supported source outcomes not set > - > > Key: PROTON-2108 > URL: https://issues.apache.org/jira/browse/PROTON-2108 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: proton-c-0.29.0 >Reporter: Robbie Gemmell >Priority: Critical > > From looking at some recent traces, it appears that the bindings (at least > for python, but probably others) do no set the outcomes (or default-outcome) > field on its source terminus, although they do use/support all the outcomes. > To a peer that actually inspects the outcomes to influence behaviour this > strictly means only Accepted is supported, which can lead to issues (e.g it > might accept a message then drop it, rather than release/modify/reject it, > under cases it couldn't be processed). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-2108) supported source outcomes not set
[ https://issues.apache.org/jira/browse/PROTON-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046377#comment-17046377 ] Robert Godfrey edited comment on PROTON-2108 at 2/27/20 9:20 AM: - [~jross] what it says is what the authors intended. Note that the set of outcomes is open, implementers are free to define their own outcomes in addition to those outlined in the spec, thus a definition along the lines that [~gsim] proposed above _"any of the outcomes are valid"_ would mean that it is implicitly saying that it will accept the new outcome "send_me_helium_filled_elephants" that I have just invented :). I don't intend to suggest that leaving the outcomes open for extension wasn't a mistake/confusing, but the definition of supported/default outcome was specifically crafted to account for these circumstances. was (Author: rgodfrey): [~jross] what it says is what the authors intended. Note that the set of outcomes is open, implementers are free to define their own outcomes in addition to those outlined in the spec, thus a definition along the lines that [~gsim] proposed above _"any of the outcomes are valid"_ would mean that it is implicitly saying that it will accept the new outcome "send_me_helium_filled_elephants" that I have just invented :). I don't intend to suggest that leaving the outcomes open for extension wasn't a mistake/confusing, but the definition of default outcome was specifically crafted to account for these circumstances. > supported source outcomes not set > - > > Key: PROTON-2108 > URL: https://issues.apache.org/jira/browse/PROTON-2108 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: proton-c-0.29.0 >Reporter: Robbie Gemmell >Priority: Critical > > From looking at some recent traces, it appears that the bindings (at least > for python, but probably others) do no set the outcomes (or default-outcome) > field on its source terminus, although they do use/support all the outcomes. > To a peer that actually inspects the outcomes to influence behaviour this > strictly means only Accepted is supported, which can lead to issues (e.g it > might accept a message then drop it, rather than release/modify/reject it, > under cases it couldn't be processed). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-2108) supported source outcomes not set
[ https://issues.apache.org/jira/browse/PROTON-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046377#comment-17046377 ] Robert Godfrey edited comment on PROTON-2108 at 2/27/20 9:18 AM: - [~jross] what it says is what the authors intended. Note that the set of outcomes is open, implementers are free to define their own outcomes in addition to those outlined in the spec, thus a definition along the lines that [~gsim] proposed above _"any of the outcomes are valid"_ would mean that it is implicitly saying that it will accept the new outcome "send_me_helium_filled_elephants" that I have just invented :). I don't intend to suggest that leaving the outcomes open for extension wasn't a mistake/confusing, but the definition of default outcome was specifically crafted to account for these circumstances. was (Author: rgodfrey): [~jross]what it says is what the authors intended. Note that the set of outcomes is open, implementers are free to define their own outcomes in addition to those outlined in the spec, thus a definition along the lines that [~gsim] proposed above _"any of the outcomes are valid"_ would mean that it is implicitly saying that it will accept the new outcome "send_me_helium_filled_elephants" that I have just invented :). I don't intend to suggest that leaving the outcomes open for extension wasn't a mistake/confusing, but the definition of default outcome was specifically crafted to account for these circumstances. > supported source outcomes not set > - > > Key: PROTON-2108 > URL: https://issues.apache.org/jira/browse/PROTON-2108 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: proton-c-0.29.0 >Reporter: Robbie Gemmell >Priority: Critical > > From looking at some recent traces, it appears that the bindings (at least > for python, but probably others) do no set the outcomes (or default-outcome) > field on its source terminus, although they do use/support all the outcomes. > To a peer that actually inspects the outcomes to influence behaviour this > strictly means only Accepted is supported, which can lead to issues (e.g it > might accept a message then drop it, rather than release/modify/reject it, > under cases it couldn't be processed). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-2108) supported source outcomes not set
[ https://issues.apache.org/jira/browse/PROTON-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046377#comment-17046377 ] Robert Godfrey edited comment on PROTON-2108 at 2/27/20 9:17 AM: - [~jross]what it says is what the authors intended. Note that the set of outcomes is open, implementers are free to define their own outcomes in addition to those outlined in the spec, thus a definition along the lines that [~gsim] proposed above _"any of the outcomes are valid"_ would mean that it is implicitly saying that it will accept the new outcome "send_me_helium_filled_elephants" that I have just invented :). I don't intend to suggest that leaving the outcomes open for extension wasn't a mistake/confusing, but the definition of default outcome was specifically crafted to account for these circumstances. was (Author: rgodfrey): [~jross]what it says is what the authors intended. Note that the set of outcomes is open, implementers are free to define their own outcomes in addition to those outlined in the spec, thus a definition along the lines that [~gsim] proposed above _"any of the outcomes are valid"_ would mean that it is implicitly saying that it will accept the new outcome "send_me_helium_filled_elephants" that I have just invented :). I don't intend to suggest that leaving the outcomes open for extension was a mistake/confusing, but the definition of default outcome was specifically crafted to account for these circumstances. > supported source outcomes not set > - > > Key: PROTON-2108 > URL: https://issues.apache.org/jira/browse/PROTON-2108 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: proton-c-0.29.0 >Reporter: Robbie Gemmell >Priority: Critical > > From looking at some recent traces, it appears that the bindings (at least > for python, but probably others) do no set the outcomes (or default-outcome) > field on its source terminus, although they do use/support all the outcomes. > To a peer that actually inspects the outcomes to influence behaviour this > strictly means only Accepted is supported, which can lead to issues (e.g it > might accept a message then drop it, rather than release/modify/reject it, > under cases it couldn't be processed). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2108) supported source outcomes not set
[ https://issues.apache.org/jira/browse/PROTON-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046377#comment-17046377 ] Robert Godfrey commented on PROTON-2108: [~jross]what it says is what the authors intended. Note that the set of outcomes is open, implementers are free to define their own outcomes in addition to those outlined in the spec, thus a definition along the lines that [~gsim] proposed above _"any of the outcomes are valid"_ would mean that it is implicitly saying that it will accept the new outcome "send_me_helium_filled_elephants" that I have just invented :). I don't intend to suggest that leaving the outcomes open for extension was a mistake/confusing, but the definition of default outcome was specifically crafted to account for these circumstances. > supported source outcomes not set > - > > Key: PROTON-2108 > URL: https://issues.apache.org/jira/browse/PROTON-2108 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: proton-c-0.29.0 >Reporter: Robbie Gemmell >Priority: Critical > > From looking at some recent traces, it appears that the bindings (at least > for python, but probably others) do no set the outcomes (or default-outcome) > field on its source terminus, although they do use/support all the outcomes. > To a peer that actually inspects the outcomes to influence behaviour this > strictly means only Accepted is supported, which can lead to issues (e.g it > might accept a message then drop it, rather than release/modify/reject it, > under cases it couldn't be processed). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8105) broker-core unit tests are failing because of wrong locale
[ https://issues.apache.org/jira/browse/QPID-8105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Godfrey reassigned QPID-8105: Assignee: Robert Godfrey > broker-core unit tests are failing because of wrong locale > -- > > Key: QPID-8105 > URL: https://issues.apache.org/jira/browse/QPID-8105 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.1 >Reporter: Olivier VERMEULEN >Assignee: Robert Godfrey >Priority: Major > > The tests make assumptions that they are running in a Locale where the comma > character is used to separate thousands in long numbers, and the dot > character is used to separate whole numbers from decimal fractions. > There are two types of errors, one where numbers are formatted in the tests > using the default Locale, but compared to output from the Broker messages > which always use Locale.US. Secondly there are tests which assume the output > value from the Broker will always be in a Locale.US format, but are actually > determined by the current Locale inside the broker (e.g. in the HTTP > management API, and in storing JSON). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8105) broker-core unit tests are failing because of wrong locale
[ https://issues.apache.org/jira/browse/QPID-8105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Godfrey updated QPID-8105: - Description: The tests make assumptions that they are running in a Locale where the comma character is used to separate thousands in long numbers, and the dot character is used to separate whole numbers from decimal fractions. There are two types of errors, one where numbers are formatted in the tests using the default Locale, but compared to output from the Broker messages which always use Locale.US. Secondly there are tests which assume the output value from the Broker will always be in a Locale.US format, but are actually determined by the current Locale inside the broker (e.g. in the HTTP management API, and in storing JSON). > broker-core unit tests are failing because of wrong locale > -- > > Key: QPID-8105 > URL: https://issues.apache.org/jira/browse/QPID-8105 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.1 >Reporter: Olivier VERMEULEN >Priority: Major > > The tests make assumptions that they are running in a Locale where the comma > character is used to separate thousands in long numbers, and the dot > character is used to separate whole numbers from decimal fractions. > There are two types of errors, one where numbers are formatted in the tests > using the default Locale, but compared to output from the Broker messages > which always use Locale.US. Secondly there are tests which assume the output > value from the Broker will always be in a Locale.US format, but are actually > determined by the current Locale inside the broker (e.g. in the HTTP > management API, and in storing JSON). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-8405) Per-message expiration is treated wrong for AMQP 0-9-1
[
https://issues.apache.org/jira/browse/QPID-8405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024244#comment-17024244
]
Robert Godfrey edited comment on QPID-8405 at 1/27/20 11:07 AM:
{quote}I see. So much for standards and their specifications...
{quote}
:) I will make the excuse that that "definition" was made before I, or the
Rabbit folks, got involved in the spec writing. For AMQP 1.0 we tried to do a
better job of making sure things were defined without ambiguity - though even
there we have found we were ultimately far from perfect.
{quote}Another suggestion would be to issue a warning if the expiration is way
in the past (e.g. 60,000 in our case). We were using the RabbitMQ client and
QPid as the broker and there are no signs whatsoever that something is going
wrong except that messages simply don't arrive at consumers. After some time
you see a "message discarded" log entry from QPid but that is long after it has
been submitted and in some cases also more or less matched the desired TTL.
{quote}
Well, one thing you can do in Qpid is set a minimum message TTL on a Queue - so
if you set the "minimumMessageTtl" attribute on the queue to 1 (ms) then
any message sent to the queue with an expiration "in the past" will be treated
as having a 10 second TTL.
Edited to add - you can set a Java system property to change the default
"minimumMessageTtl" for all queues (i.e. all queues which haven't had a minimum
message TTL explicitly set). The system property in question is
{{queue.minimumMessageTtl}}, and must be set before the broker is started (i.e.
changes made to the property value made after the broker is running will only
be picked up on newly created queues). Note that for messages without an
expiration set, or with an expiration set sufficiently in the future, then
setting the minimum TTL has no effect.
was (Author: rgodfrey):
{quote}I see. So much for standards and their specifications...
{quote}
:) I will make the excuse that that "definition" was made before I, or the
Rabbit folks, got involved in the spec writing. For AMQP 1.0 we tried to do a
better job of making sure things were defined without ambiguity - though even
there we have found we were ultimately far from perfect.
{quote}Another suggestion would be to issue a warning if the expiration is way
in the past (e.g. 60,000 in our case). We were using the RabbitMQ client and
QPid as the broker and there are no signs whatsoever that something is going
wrong except that messages simply don't arrive at consumers. After some time
you see a "message discarded" log entry from QPid but that is long after it has
been submitted and in some cases also more or less matched the desired TTL.
{quote}
Well, one thing you can do in Qpid is set a minimum message TTL on a Queue - so
if you set the "minimumMessageTtl" attribute on the queue to 1 (ms) then
any message sent to the queue with an expiration "in the past" will be treated
as having a 10 second TTL.
Edited to add - you can set a Java system property to change the default
"minimumMessageTtl" for all queues (i.e. all queues which haven't had a minimum
message TTL explicitly set). The system property in question is
{{queue.minimumMessageTtl}}. Note that for messages without an expiration set,
or with an expiration set sufficiently in the future, then setting the minimum
TTL has no effect.
> Per-message expiration is treated wrong for AMQP 0-9-1
> --
>
> Key: QPID-8405
> URL: https://issues.apache.org/jira/browse/QPID-8405
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.7
>Reporter: Thorsten Meinl
>Priority: Major
>
> We are using QPid with AMQP 0-9-1 support as an embedded alternative to
> RabbitMQ. RabbitMQ has extended the 0-9-1 specification with [per-message
> TTLs|https://www.rabbitmq.com/ttl.html#per-message-ttl]. The documentation
> states that the value of the {{expiration}} header is the time-to-live in
> milliseconds. However, when we set an expiration of 60,000 when sending a
> message to QPid this message gets discarded immediately and is not delivered
> to any consumer. I had a look at the code and the bug is obvious: instead of
> treating the {{expiration}} header as a TTL it is treated as an absolute
> expiration timestamp, see
> {{org.apache.qpid.server.queue.QueueEntryImpl.expired()}}. Either QPid
> shouldn't support expiration at all for AMPQ 0-9-1 since it's not part of the
> standard or it should follow the RabbitMQ implementation since I assume it
> was introduced by them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail:
[jira] [Comment Edited] (QPID-8405) Per-message expiration is treated wrong for AMQP 0-9-1
[
https://issues.apache.org/jira/browse/QPID-8405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024244#comment-17024244
]
Robert Godfrey edited comment on QPID-8405 at 1/27/20 11:05 AM:
{quote}I see. So much for standards and their specifications...
{quote}
:) I will make the excuse that that "definition" was made before I, or the
Rabbit folks, got involved in the spec writing. For AMQP 1.0 we tried to do a
better job of making sure things were defined without ambiguity - though even
there we have found we were ultimately far from perfect.
{quote}Another suggestion would be to issue a warning if the expiration is way
in the past (e.g. 60,000 in our case). We were using the RabbitMQ client and
QPid as the broker and there are no signs whatsoever that something is going
wrong except that messages simply don't arrive at consumers. After some time
you see a "message discarded" log entry from QPid but that is long after it has
been submitted and in some cases also more or less matched the desired TTL.
{quote}
Well, one thing you can do in Qpid is set a minimum message TTL on a Queue - so
if you set the "minimumMessageTtl" attribute on the queue to 1 (ms) then
any message sent to the queue with an expiration "in the past" will be treated
as having a 10 second TTL.
Edited to add - you can set a Java system property to change the default
"minimumMessageTtl" for all queues (i.e. all queues which haven't had a minimum
message TTL explicitly set). The system property in question is
{{queue.minimumMessageTtl}}. Note that for messages without an expiration set,
or with an expiration set sufficiently in the future, then setting the minimum
TTL has no effect.
was (Author: rgodfrey):
bq. I see. So much for standards and their specifications...
:-) I will make the excuse that that "definition" was made before I, or the
Rabbit folks, got involved in the spec writing. For AMQP 1.0 we tried to do a
better job of making sure things were defined without ambiguity - though even
there we have found we were ultimately far from perfect.
bq. Another suggestion would be to issue a warning if the expiration is way in
the past (e.g. 60,000 in our case). We were using the RabbitMQ client and QPid
as the broker and there are no signs whatsoever that something is going wrong
except that messages simply don't arrive at consumers. After some time you see
a "message discarded" log entry from QPid but that is long after it has been
submitted and in some cases also more or less matched the desired TTL.
Well, one thing you can do in Qpid is set a minimum message TTL on a Queue - so
if you set the "minimumMessageTtl" attribute on the queue to 1 (ms) then
any message sent to the queue with an expiration "in the past" will be treated
as having a 10 second TTL.
> Per-message expiration is treated wrong for AMQP 0-9-1
> --
>
> Key: QPID-8405
> URL: https://issues.apache.org/jira/browse/QPID-8405
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.7
>Reporter: Thorsten Meinl
>Priority: Major
>
> We are using QPid with AMQP 0-9-1 support as an embedded alternative to
> RabbitMQ. RabbitMQ has extended the 0-9-1 specification with [per-message
> TTLs|https://www.rabbitmq.com/ttl.html#per-message-ttl]. The documentation
> states that the value of the {{expiration}} header is the time-to-live in
> milliseconds. However, when we set an expiration of 60,000 when sending a
> message to QPid this message gets discarded immediately and is not delivered
> to any consumer. I had a look at the code and the bug is obvious: instead of
> treating the {{expiration}} header as a TTL it is treated as an absolute
> expiration timestamp, see
> {{org.apache.qpid.server.queue.QueueEntryImpl.expired()}}. Either QPid
> shouldn't support expiration at all for AMPQ 0-9-1 since it's not part of the
> standard or it should follow the RabbitMQ implementation since I assume it
> was introduced by them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8405) Per-message expiration is treated wrong for AMQP 0-9-1
[
https://issues.apache.org/jira/browse/QPID-8405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024244#comment-17024244
]
Robert Godfrey commented on QPID-8405:
--
bq. I see. So much for standards and their specifications...
:-) I will make the excuse that that "definition" was made before I, or the
Rabbit folks, got involved in the spec writing. For AMQP 1.0 we tried to do a
better job of making sure things were defined without ambiguity - though even
there we have found we were ultimately far from perfect.
bq. Another suggestion would be to issue a warning if the expiration is way in
the past (e.g. 60,000 in our case). We were using the RabbitMQ client and QPid
as the broker and there are no signs whatsoever that something is going wrong
except that messages simply don't arrive at consumers. After some time you see
a "message discarded" log entry from QPid but that is long after it has been
submitted and in some cases also more or less matched the desired TTL.
Well, one thing you can do in Qpid is set a minimum message TTL on a Queue - so
if you set the "minimumMessageTtl" attribute on the queue to 1 (ms) then
any message sent to the queue with an expiration "in the past" will be treated
as having a 10 second TTL.
> Per-message expiration is treated wrong for AMQP 0-9-1
> --
>
> Key: QPID-8405
> URL: https://issues.apache.org/jira/browse/QPID-8405
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.7
>Reporter: Thorsten Meinl
>Priority: Major
>
> We are using QPid with AMQP 0-9-1 support as an embedded alternative to
> RabbitMQ. RabbitMQ has extended the 0-9-1 specification with [per-message
> TTLs|https://www.rabbitmq.com/ttl.html#per-message-ttl]. The documentation
> states that the value of the {{expiration}} header is the time-to-live in
> milliseconds. However, when we set an expiration of 60,000 when sending a
> message to QPid this message gets discarded immediately and is not delivered
> to any consumer. I had a look at the code and the bug is obvious: instead of
> treating the {{expiration}} header as a TTL it is treated as an absolute
> expiration timestamp, see
> {{org.apache.qpid.server.queue.QueueEntryImpl.expired()}}. Either QPid
> shouldn't support expiration at all for AMPQ 0-9-1 since it's not part of the
> standard or it should follow the RabbitMQ implementation since I assume it
> was introduced by them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-8405) Per-message expiration is treated wrong for AMQP 0-9-1
[
https://issues.apache.org/jira/browse/QPID-8405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023014#comment-17023014
]
Robert Godfrey edited comment on QPID-8405 at 1/24/20 3:17 PM:
---
For AMQP 0-9-1 the "expiration" field in Basic.ContentHeaderProperties didn't
have any semantics specified. The definition literally is:
{{1.8.2.8. Property basic.expiration (shortstr)}}
{{Domain: shortstr}}
{{Label: message expiration specification}}
It is, however, specifically labelled as "expiration" rather than ttl.
I'm pretty sure that the Qpid implementation actually pre-dates the RabbitMQ
one (I think this was first implemented in Qpid in the 2006/2007 timeframe -
but the code has changed and moved around so much since then it would take a
while to track it down) but I don't think it is appropriate to say either one
is right or wrong, nor that one should change.
One thing that could potentially be done on the Qpid side is to add some sort
of property in the client-properties sent by the client in Connection.start-ok
to request that Qpid Broker-J treat the "expiration" field as is done by
RabbitMQ.
was (Author: rgodfrey):
For AMQP 0-9-1 the "expiration" field in Basic.ContentHeaderProperties didn't
have any semantics specified. The definition literally is:
{{1.8.2.8. Property basic.expiration (shortstr)}}
{{Domain: shortstr}}
{{ Label: message expiration specification}}
It is, however, specifically labelled as "expiration" rather than ttl.
I'm pretty sure that the Qpid implementation actually pre-dates the RabbitMQ
one (I think this was first implemented in Qpid in the 2006/2007 timeframe -
but the code has changed and moved around so much since then it would take a
while to track it down) but I don't think it is appropriate to say either one
is right or wrong, nor that one should change.
One thing that could potentially be done on the Qpid side is to add some sort
of property in the client-properties sent by the client in Connection.start-ok
to request that Qpid Broker-J treat the "expiration" field as is done by
RabbitMQ.
> Per-message expiration is treated wrong for AMQP 0-9-1
> --
>
> Key: QPID-8405
> URL: https://issues.apache.org/jira/browse/QPID-8405
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.7
>Reporter: Thorsten Meinl
>Priority: Major
>
> We are using QPid with AMQP 0-9-1 support as an embedded alternative to
> RabbitMQ. RabbitMQ has extended the 0-9-1 specification with [per-message
> TTLs|https://www.rabbitmq.com/ttl.html#per-message-ttl]. The documentation
> states that the value of the {{expiration}} header is the time-to-live in
> milliseconds. However, when we set an expiration of 60,000 when sending a
> message to QPid this message gets discarded immediately and is not delivered
> to any consumer. I had a look at the code and the bug is obvious: instead of
> treating the {{expiration}} header as a TTL it is treated as an absolute
> expiration timestamp, see
> {{org.apache.qpid.server.queue.QueueEntryImpl.expired()}}. Either QPid
> shouldn't support expiration at all for AMPQ 0-9-1 since it's not part of the
> standard or it should follow the RabbitMQ implementation since I assume it
> was introduced by them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8405) Per-message expiration is treated wrong for AMQP 0-9-1
[
https://issues.apache.org/jira/browse/QPID-8405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023014#comment-17023014
]
Robert Godfrey commented on QPID-8405:
--
For AMQP 0-9-1 the "expiration" field in Basic.ContentHeaderProperties didn't
have any semantics specified. The definition literally is:
{{1.8.2.8. Property basic.expiration (shortstr)}}
{{Domain: shortstr}}
{{ Label: message expiration specification}}
It is, however, specifically labelled as "expiration" rather than ttl.
I'm pretty sure that the Qpid implementation actually pre-dates the RabbitMQ
one (I think this was first implemented in Qpid in the 2006/2007 timeframe -
but the code has changed and moved around so much since then it would take a
while to track it down) but I don't think it is appropriate to say either one
is right or wrong, nor that one should change.
One thing that could potentially be done on the Qpid side is to add some sort
of property in the client-properties sent by the client in Connection.start-ok
to request that Qpid Broker-J treat the "expiration" field as is done by
RabbitMQ.
> Per-message expiration is treated wrong for AMQP 0-9-1
> --
>
> Key: QPID-8405
> URL: https://issues.apache.org/jira/browse/QPID-8405
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.7
>Reporter: Thorsten Meinl
>Priority: Major
>
> We are using QPid with AMQP 0-9-1 support as an embedded alternative to
> RabbitMQ. RabbitMQ has extended the 0-9-1 specification with [per-message
> TTLs|https://www.rabbitmq.com/ttl.html#per-message-ttl]. The documentation
> states that the value of the {{expiration}} header is the time-to-live in
> milliseconds. However, when we set an expiration of 60,000 when sending a
> message to QPid this message gets discarded immediately and is not delivered
> to any consumer. I had a look at the code and the bug is obvious: instead of
> treating the {{expiration}} header as a TTL it is treated as an absolute
> expiration timestamp, see
> {{org.apache.qpid.server.queue.QueueEntryImpl.expired()}}. Either QPid
> shouldn't support expiration at all for AMPQ 0-9-1 since it's not part of the
> standard or it should follow the RabbitMQ implementation since I assume it
> was introduced by them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8404) [Broker-J] Use of TLS client certificates in versions > = 7.1.5 broken by Jetty changes
[ https://issues.apache.org/jira/browse/QPID-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Godfrey updated QPID-8404: - Attachment: 0001-QPID-8404-Fix-usage-of-Jetty-for-TLS-client-certs.patch > [Broker-J] Use of TLS client certificates in versions > = 7.1.5 broken by > Jetty changes > --- > > Key: QPID-8404 > URL: https://issues.apache.org/jira/browse/QPID-8404 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.5, qpid-java-broker-7.1.6, > qpid-java-broker-7.1.7 >Reporter: Robert Godfrey >Assignee: Robert Godfrey >Priority: Major > Attachments: > 0001-QPID-8404-Fix-usage-of-Jetty-for-TLS-client-certs.patch > > > Changes in Jetty aimed at improving the client side use of TLS using that > library broke implementations using it for server side usage of client certs. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8404) [Broker-J] Use of TLS client certificates in versions > = 7.1.5 broken by Jetty changes
[ https://issues.apache.org/jira/browse/QPID-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Godfrey reassigned QPID-8404: Assignee: Robert Godfrey > [Broker-J] Use of TLS client certificates in versions > = 7.1.5 broken by > Jetty changes > --- > > Key: QPID-8404 > URL: https://issues.apache.org/jira/browse/QPID-8404 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.5, qpid-java-broker-7.1.6, > qpid-java-broker-7.1.7 >Reporter: Robert Godfrey >Assignee: Robert Godfrey >Priority: Major > > Changes in Jetty aimed at improving the client side use of TLS using that > library broke implementations using it for server side usage of client certs. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8404) [Broker-J] Use of TLS client certificates in versions > = 7.1.5 broken by Jetty changes
[ https://issues.apache.org/jira/browse/QPID-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Godfrey updated QPID-8404: - Issue Type: Bug (was: Improvement) > [Broker-J] Use of TLS client certificates in versions > = 7.1.5 broken by > Jetty changes > --- > > Key: QPID-8404 > URL: https://issues.apache.org/jira/browse/QPID-8404 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.5, qpid-java-broker-7.1.6, > qpid-java-broker-7.1.7 >Reporter: Robert Godfrey >Priority: Major > > Changes in Jetty aimed at improving the client side use of TLS using that > library broke implementations using it for server side usage of client certs. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8404) [Broker-J] Use of TLS client certificates in versions > = 7.1.5 broken by Jetty changes
Robert Godfrey created QPID-8404: Summary: [Broker-J] Use of TLS client certificates in versions > = 7.1.5 broken by Jetty changes Key: QPID-8404 URL: https://issues.apache.org/jira/browse/QPID-8404 Project: Qpid Issue Type: Improvement Components: Broker-J Affects Versions: qpid-java-broker-7.1.7, qpid-java-broker-7.1.6, qpid-java-broker-7.1.5 Reporter: Robert Godfrey Changes in Jetty aimed at improving the client side use of TLS using that library broke implementations using it for server side usage of client certs. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8401) [Broker-J] Broker dies when DB connection is lost
[
https://issues.apache.org/jira/browse/QPID-8401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014413#comment-17014413
]
Robert Godfrey commented on QPID-8401:
--
{quote}Now regarding the current behavior of the broker, note that when the
broker dies this way I end up with a message that stays acquired forever (not
by any client consumer but by the housekeeping task itself). When I restart the
broker this message never gets deleted even though it expired and I can't
consume it either... Shouldn't the message be released when rolling back the
failed dequeue operation?
[https://github.com/apache/qpid-broker-j/blob/master/broker-core/src/main/java/org/apache/qpid/server/queue/AbstractQueue.java#L1852]
{quote}
So acquisition should not be persisted, so when the broker dies and then
restarts the message should not be acquired. In terms of the onRollback in the
code quoted - that logic is for when a transaction is manually rolled back by a
client (not applicable in this case), it is not designed for handling the case
where the broker initiates rollback - in this case the expected behaviour is
that the broker (really should be the virtual host) dies.
> [Broker-J] Broker dies when DB connection is lost
> -
>
> Key: QPID-8401
> URL: https://issues.apache.org/jira/browse/QPID-8401
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.6
>Reporter: Olivier VERMEULEN
>Priority: Critical
>
> When using a JDBC message store, if the housekeeping task is triggered while
> the DB connection is lost (DB down or network problem) then the Broker dies
> with the stack below.
> This happens when a message expires and the housekeeping task tries to delete
> it from the store while the DB is not accessible. In this case a
> StoreException is thrown but this exception is not catched by the
> Housekeeping task which is only catching ConnectionScopedRuntimeExceptions.
>
> 2019-12-12 16:22:40,671 ERROR [virtualhost-default-pool-3] (o.a.q.s.Main) -
> Uncaught exception, shutting down.
> org.apache.qpid.server.store.StoreException: java.sql.SQLException: JZ006:
> Caught IOException: com.sybase.jdbc4.jdbc.SybConnectionDeadException: JZ0C0:
> Connection is already closed.
> at
> org.apache.qpid.server.store.jdbc.AbstractJDBCMessageStore$JDBCTransaction.(AbstractJDBCMessageStore.java:1153)
> at
> org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:122)
> at
> org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:118)
> at
> org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore.newTransaction(GenericAbstractJDBCMessageStore.java:114)
> at
> org.apache.qpid.server.txn.AutoCommitTransaction.dequeue(AutoCommitTransaction.java:87)
> at
> org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1780)
> at
> org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1775)
> at
> org.apache.qpid.server.queue.AbstractQueue.deleteEntry(AbstractQueue.java:1819)
> at
> org.apache.qpid.server.queue.AbstractQueue.expireEntry(AbstractQueue.java:2354)
> at
> org.apache.qpid.server.queue.AbstractQueue.getNextAvailableEntry(AbstractQueue.java:2236)
> at
> org.apache.qpid.server.queue.AbstractQueue.access$1800(AbstractQueue.java:131)
> at
> org.apache.qpid.server.queue.AbstractQueue$AdvanceConsumersTask.execute(AbstractQueue.java:3712)
> at
> org.apache.qpid.server.virtualhost.HouseKeepingTask$1.run(HouseKeepingTask.java:56)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.virtualhost.HouseKeepingTask.run(HouseKeepingTask.java:51)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.sql.SQLException: JZ006: Caught IOException:
> com.sybase.jdbc4.jdbc.SybConnectionDeadException: JZ0C0: Connection is
> already closed.
> at
> com.sybase.jdbc4.jdbc.ErrorMessage.createIOEKilledConnEx(ErrorMessage.java:1155)
> at
>
[jira] [Commented] (QPID-8401) [Broker-J] Broker dies when DB connection is lost
[ https://issues.apache.org/jira/browse/QPID-8401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17012996#comment-17012996 ] Robert Godfrey commented on QPID-8401: -- In general I don't think the broker can ignore store issues. In this particular case (deleting an expired message) failure is possibly not all that important and could potentially be retried, the general case doesn't really allow this - and it would require substantial changes to the internal model and APIs to cover this case. Admittedly store failure should possibly be treated only as a failure at the virtual host level, leading to simply attempting to restart the virtual host (rather than killing the whole broker process), but I'm not sure those mechanisms currently exist. Another way to approach this problem is by adding intelligence to the connection pool / connection logic allowing it to detect failures and possibly even perform retries. > [Broker-J] Broker dies when DB connection is lost > - > > Key: QPID-8401 > URL: https://issues.apache.org/jira/browse/QPID-8401 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.6 >Reporter: Olivier VERMEULEN >Priority: Critical > > When using a JDBC message store, if the housekeeping task is triggered while > the DB connection is lost (DB down or network problem) then the Broker dies > with the stack below. > This happens when a message expires and the housekeeping task tries to delete > it from the store while the DB is not accessible. In this case a > StoreException is thrown but this exception is not catched by the > Housekeeping task which is only catching ConnectionScopedRuntimeExceptions. > > 2019-12-12 16:22:40,671 ERROR [virtualhost-default-pool-3] (o.a.q.s.Main) - > Uncaught exception, shutting down. > org.apache.qpid.server.store.StoreException: java.sql.SQLException: JZ006: > Caught IOException: com.sybase.jdbc4.jdbc.SybConnectionDeadException: JZ0C0: > Connection is already closed. > at > org.apache.qpid.server.store.jdbc.AbstractJDBCMessageStore$JDBCTransaction.(AbstractJDBCMessageStore.java:1153) > at > org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:122) > at > org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:118) > at > org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore.newTransaction(GenericAbstractJDBCMessageStore.java:114) > at > org.apache.qpid.server.txn.AutoCommitTransaction.dequeue(AutoCommitTransaction.java:87) > at > org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1780) > at > org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1775) > at > org.apache.qpid.server.queue.AbstractQueue.deleteEntry(AbstractQueue.java:1819) > at > org.apache.qpid.server.queue.AbstractQueue.expireEntry(AbstractQueue.java:2354) > at > org.apache.qpid.server.queue.AbstractQueue.getNextAvailableEntry(AbstractQueue.java:2236) > at > org.apache.qpid.server.queue.AbstractQueue.access$1800(AbstractQueue.java:131) > at > org.apache.qpid.server.queue.AbstractQueue$AdvanceConsumersTask.execute(AbstractQueue.java:3712) > at > org.apache.qpid.server.virtualhost.HouseKeepingTask$1.run(HouseKeepingTask.java:56) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.qpid.server.virtualhost.HouseKeepingTask.run(HouseKeepingTask.java:51) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at > org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.sql.SQLException: JZ006: Caught IOException: > com.sybase.jdbc4.jdbc.SybConnectionDeadException: JZ0C0: Connection is > already closed. > at > com.sybase.jdbc4.jdbc.ErrorMessage.createIOEKilledConnEx(ErrorMessage.java:1155) > at > com.sybase.jdbc4.jdbc.ErrorMessage.raiseErrorCheckDead(ErrorMessage.java:1194) > at com.sybase.jdbc4.tds.Tds.handleIOE(Tds.java:5250) > at com.sybase.jdbc4.tds.Tds.handleIOE(Tds.java:5195) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (QPID-8395) [Broker-J] Refactor selector/filter handling when adding consumers to queues
[ https://issues.apache.org/jira/browse/QPID-8395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Godfrey reassigned QPID-8395: Assignee: Robert Godfrey > [Broker-J] Refactor selector/filter handling when adding consumers to queues > > > Key: QPID-8395 > URL: https://issues.apache.org/jira/browse/QPID-8395 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Robert Godfrey >Assignee: Robert Godfrey >Priority: Minor > > Much of the code around adding filters (selectors) to consumers is driven by > the legacy AMQP 0-x mechanisms. > As a prelude to adding support to more filters types being defined for AMQP > 1.0, the filter code should be refactored. In particular consumers in > general should be able to support multiple (named) filters, which override > "default" filters defined on the queue. The names associated with the > filters are arbitrary. For AMQP 0-x protocols the JMS Selector filter type > is supported, and a broker defined name is used. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8395) [Broker-J] Refactor selector/filter handling when adding consumers to queues
[ https://issues.apache.org/jira/browse/QPID-8395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Godfrey updated QPID-8395: - Description: Much of the code around adding filters (selectors) to consumers is driven by the legacy AMQP 0-x mechanisms. As a prelude to adding support to more filters types being defined for AMQP 1.0, the filter code should be refactored. In particular consumers in general should be able to support multiple (named) filters, which override "default" filters defined on the queue. The names associated with the filters are arbitrary. For AMQP 0-x protocols the JMS Selector filter type is supported, and a broker defined name is used. > [Broker-J] Refactor selector/filter handling when adding consumers to queues > > > Key: QPID-8395 > URL: https://issues.apache.org/jira/browse/QPID-8395 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Robert Godfrey >Priority: Minor > > Much of the code around adding filters (selectors) to consumers is driven by > the legacy AMQP 0-x mechanisms. > As a prelude to adding support to more filters types being defined for AMQP > 1.0, the filter code should be refactored. In particular consumers in > general should be able to support multiple (named) filters, which override > "default" filters defined on the queue. The names associated with the > filters are arbitrary. For AMQP 0-x protocols the JMS Selector filter type > is supported, and a broker defined name is used. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8395) [Broker-J] Refactor selector/filter handling when adding consumers to queues
[ https://issues.apache.org/jira/browse/QPID-8395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Godfrey updated QPID-8395: - Environment: (was: Much of the code around adding filters (selectors) to consumers is driven by the legacy AMQP 0-x mechanisms. As a prelude to adding support to more filters types being defined for AMQP 1.0, the filter code should be refactored. In particular consumers in general should be able to support multiple (named) filters, which override "default" filters defined on the queue. The names associated with the filters are arbitrary. For AMQP 0-x protocols the JMS Selector filter type is supported, and a broker defined name is used.) > [Broker-J] Refactor selector/filter handling when adding consumers to queues > > > Key: QPID-8395 > URL: https://issues.apache.org/jira/browse/QPID-8395 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Robert Godfrey >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8395) [Broker-J] Refactor selector/filter handling when adding consumers to queues
Robert Godfrey created QPID-8395: Summary: [Broker-J] Refactor selector/filter handling when adding consumers to queues Key: QPID-8395 URL: https://issues.apache.org/jira/browse/QPID-8395 Project: Qpid Issue Type: Improvement Components: Broker-J Environment: Much of the code around adding filters (selectors) to consumers is driven by the legacy AMQP 0-x mechanisms. As a prelude to adding support to more filters types being defined for AMQP 1.0, the filter code should be refactored. In particular consumers in general should be able to support multiple (named) filters, which override "default" filters defined on the queue. The names associated with the filters are arbitrary. For AMQP 0-x protocols the JMS Selector filter type is supported, and a broker defined name is used. Reporter: Robert Godfrey -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8389) [Broker-J] Support the ability to limit the number of active consumers
[ https://issues.apache.org/jira/browse/QPID-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004283#comment-17004283 ] Robert Godfrey commented on QPID-8389: -- Thanks [~orudyy] getting back to address your comments was on my TODO list :-) > [Broker-J] Support the ability to limit the number of active consumers > -- > > Key: QPID-8389 > URL: https://issues.apache.org/jira/browse/QPID-8389 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Robert Godfrey >Assignee: Robert Godfrey >Priority: Major > Fix For: qpid-java-broker-8.0.0 > > > RabbitMQ supports an extension to queue.declare to designate that the queue > will support only one "active" consumer, while keeping other consumers > connected to act as a fast failover (see > [https://www.rabbitmq.com/consumers.html#single-active-consumer]). > We should add the ability for similar configuration to Broker-J -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8385) [Broker-J] Improve performance of dequeuing old queue entries on triggering ring policy
[
https://issues.apache.org/jira/browse/QPID-8385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003007#comment-17003007
]
Robert Godfrey commented on QPID-8385:
--
[~orudyy] I updated [^QPID-8385_QPID-8393.patch] to prevent a recursion that
occurs when checkOverflow causes a messages to be dequeued, and incorporated
your changes to use AsyncAutoCommitTransaction (although the patch doesn't
include your additions to the test). Applying this patch I see a *substantial*
performance improvement
> [Broker-J] Improve performance of dequeuing old queue entries on triggering
> ring policy
> ---
>
> Key: QPID-8385
> URL: https://issues.apache.org/jira/browse/QPID-8385
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
> Attachments:
> 0001-QPID-8385-Broker-J-Delete-queue-entry-asynchronously.patch,
> 0001-QPID-8385-Broker-J-Utilize-AsyncAutoCommitTransactio.patch,
> QPID-8385_QPID-8393.patch
>
>
> The performance of dequeuing old queue entries with triggering ring policy is
> affected by the following factors:
> * the oldest entry is not deleted immediately. As result, the deletion of
> the same oldest entry can be requested from multiple publishing IO threads
> * only one publishing thread can acquire the message with
> {{QueueEntry#acquireOrSteal}}, whilst the rest of publishing IO threads would
> set a {{DelayedAcquisitionStateListener}}. As result, thousands of
> {{DelayedAcquisitionStateListeners}} can be potentially set on the same queue
> entry
> * Setting of {{DelayedAcquisitionStateListeners}} from concurrent IO threads
> can consume host CPU up to 100% as there is a tight loop in
> {{StateChangeListenerEntry#add(StateChangeListenerEntry)}}. There is a
> risk of running into defect {{QPID-8393}} whilst setting a listener.
> * The old message is deleted in IO thread blocking the enqueing of new
> messages
> It seems that high CPU consumption on setting of
> {{DelayedAcquisitionStateListeners}} is the main contributor for the
> perfromance degradation on old entries dequeueing by ring policy.
> The current approach for dequeuing of old queue entries from ring policy
> should be revisited. We need a mechanism to avoid multiple dequeueing of the
> same queue entry from concurrent threads. Only after introduction of such
> mechanism we can look into further performance optimisation for deletion of
> persistent queue entries.
> AutoCommitTransaction is used to dequeue entries on message expiration or
> breaching ring policy threshold. As result, the dequeueing operation for
> persistent queue entry blocks until queue entry record is removed from the
> store and the underlying store transaction is synced to disk. The sequential
> removal of multiple entries can results in unnecessary delays due to syncing
> disk on every dequeue.
> The broker performance for the corner cases described above can be
> significantly improved by using asynchronous transactions in dequeue
> operations.
> Asynchronous transaction does not wait for the store dequeue transaction to
> sync to disk. As result, the performance of removal unneeded queue entries
> can increase.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8385) [Broker-J] Improve performance of dequeuing old queue entries on triggering ring policy
[
https://issues.apache.org/jira/browse/QPID-8385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Godfrey updated QPID-8385:
-
Attachment: (was: QPID-8385_QPID-8393.patch)
> [Broker-J] Improve performance of dequeuing old queue entries on triggering
> ring policy
> ---
>
> Key: QPID-8385
> URL: https://issues.apache.org/jira/browse/QPID-8385
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
> Attachments:
> 0001-QPID-8385-Broker-J-Delete-queue-entry-asynchronously.patch,
> 0001-QPID-8385-Broker-J-Utilize-AsyncAutoCommitTransactio.patch,
> QPID-8385_QPID-8393.patch
>
>
> The performance of dequeuing old queue entries with triggering ring policy is
> affected by the following factors:
> * the oldest entry is not deleted immediately. As result, the deletion of
> the same oldest entry can be requested from multiple publishing IO threads
> * only one publishing thread can acquire the message with
> {{QueueEntry#acquireOrSteal}}, whilst the rest of publishing IO threads would
> set a {{DelayedAcquisitionStateListener}}. As result, thousands of
> {{DelayedAcquisitionStateListeners}} can be potentially set on the same queue
> entry
> * Setting of {{DelayedAcquisitionStateListeners}} from concurrent IO threads
> can consume host CPU up to 100% as there is a tight loop in
> {{StateChangeListenerEntry#add(StateChangeListenerEntry)}}. There is a
> risk of running into defect {{QPID-8393}} whilst setting a listener.
> * The old message is deleted in IO thread blocking the enqueing of new
> messages
> It seems that high CPU consumption on setting of
> {{DelayedAcquisitionStateListeners}} is the main contributor for the
> perfromance degradation on old entries dequeueing by ring policy.
> The current approach for dequeuing of old queue entries from ring policy
> should be revisited. We need a mechanism to avoid multiple dequeueing of the
> same queue entry from concurrent threads. Only after introduction of such
> mechanism we can look into further performance optimisation for deletion of
> persistent queue entries.
> AutoCommitTransaction is used to dequeue entries on message expiration or
> breaching ring policy threshold. As result, the dequeueing operation for
> persistent queue entry blocks until queue entry record is removed from the
> store and the underlying store transaction is synced to disk. The sequential
> removal of multiple entries can results in unnecessary delays due to syncing
> disk on every dequeue.
> The broker performance for the corner cases described above can be
> significantly improved by using asynchronous transactions in dequeue
> operations.
> Asynchronous transaction does not wait for the store dequeue transaction to
> sync to disk. As result, the performance of removal unneeded queue entries
> can increase.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8385) [Broker-J] Improve performance of dequeuing old queue entries on triggering ring policy
[
https://issues.apache.org/jira/browse/QPID-8385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Godfrey updated QPID-8385:
-
Attachment: QPID-8385_QPID-8393.patch
> [Broker-J] Improve performance of dequeuing old queue entries on triggering
> ring policy
> ---
>
> Key: QPID-8385
> URL: https://issues.apache.org/jira/browse/QPID-8385
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
> Attachments:
> 0001-QPID-8385-Broker-J-Delete-queue-entry-asynchronously.patch,
> 0001-QPID-8385-Broker-J-Utilize-AsyncAutoCommitTransactio.patch,
> QPID-8385_QPID-8393.patch
>
>
> The performance of dequeuing old queue entries with triggering ring policy is
> affected by the following factors:
> * the oldest entry is not deleted immediately. As result, the deletion of
> the same oldest entry can be requested from multiple publishing IO threads
> * only one publishing thread can acquire the message with
> {{QueueEntry#acquireOrSteal}}, whilst the rest of publishing IO threads would
> set a {{DelayedAcquisitionStateListener}}. As result, thousands of
> {{DelayedAcquisitionStateListeners}} can be potentially set on the same queue
> entry
> * Setting of {{DelayedAcquisitionStateListeners}} from concurrent IO threads
> can consume host CPU up to 100% as there is a tight loop in
> {{StateChangeListenerEntry#add(StateChangeListenerEntry)}}. There is a
> risk of running into defect {{QPID-8393}} whilst setting a listener.
> * The old message is deleted in IO thread blocking the enqueing of new
> messages
> It seems that high CPU consumption on setting of
> {{DelayedAcquisitionStateListeners}} is the main contributor for the
> perfromance degradation on old entries dequeueing by ring policy.
> The current approach for dequeuing of old queue entries from ring policy
> should be revisited. We need a mechanism to avoid multiple dequeueing of the
> same queue entry from concurrent threads. Only after introduction of such
> mechanism we can look into further performance optimisation for deletion of
> persistent queue entries.
> AutoCommitTransaction is used to dequeue entries on message expiration or
> breaching ring policy threshold. As result, the dequeueing operation for
> persistent queue entry blocks until queue entry record is removed from the
> store and the underlying store transaction is synced to disk. The sequential
> removal of multiple entries can results in unnecessary delays due to syncing
> disk on every dequeue.
> The broker performance for the corner cases described above can be
> significantly improved by using asynchronous transactions in dequeue
> operations.
> Asynchronous transaction does not wait for the store dequeue transaction to
> sync to disk. As result, the performance of removal unneeded queue entries
> can increase.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-8385) [Broker-J] Improve performance of dequeuing old queue entries on triggering ring policy
[
https://issues.apache.org/jira/browse/QPID-8385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002991#comment-17002991
]
Robert Godfrey edited comment on QPID-8385 at 12/24/19 8:46 PM:
[~orudyy] So one approach here is simply to implement equality on the
DelayedAcquisitionStateListener (and on the Runnable tasks passed therein).
The add function already tests for equality and doesn't add if the listener is
already present. I've knocked up a [patch|^QPID-8385_QPID-8393.patch] which
I think will do the trick (and also addresses the StackOverflowError in
QPID-8393).
was (Author: rgodfrey):
[~orudyy] So one approach here is simply to implement equality on the
DelayedAcquisitionStateListener (and on the Runnable tasks passed therein).
The add function already tests for equality and doesn't add if the listener is
already present. I've knocked up a [patch|^QPID-8385_QPID-8393.patch] which
I think will do the trick (and also address the StackOverflowError in
QPID-8393).
> [Broker-J] Improve performance of dequeuing old queue entries on triggering
> ring policy
> ---
>
> Key: QPID-8385
> URL: https://issues.apache.org/jira/browse/QPID-8385
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
> Attachments:
> 0001-QPID-8385-Broker-J-Delete-queue-entry-asynchronously.patch,
> 0001-QPID-8385-Broker-J-Utilize-AsyncAutoCommitTransactio.patch,
> QPID-8385_QPID-8393.patch
>
>
> The performance of dequeuing old queue entries with triggering ring policy is
> affected by the following factors:
> * the oldest entry is not deleted immediately. As result, the deletion of
> the same oldest entry can be requested from multiple publishing IO threads
> * only one publishing thread can acquire the message with
> {{QueueEntry#acquireOrSteal}}, whilst the rest of publishing IO threads would
> set a {{DelayedAcquisitionStateListener}}. As result, thousands of
> {{DelayedAcquisitionStateListeners}} can be potentially set on the same queue
> entry
> * Setting of {{DelayedAcquisitionStateListeners}} from concurrent IO threads
> can consume host CPU up to 100% as there is a tight loop in
> {{StateChangeListenerEntry#add(StateChangeListenerEntry)}}. There is a
> risk of running into defect {{QPID-8393}} whilst setting a listener.
> * The old message is deleted in IO thread blocking the enqueing of new
> messages
> It seems that high CPU consumption on setting of
> {{DelayedAcquisitionStateListeners}} is the main contributor for the
> perfromance degradation on old entries dequeueing by ring policy.
> The current approach for dequeuing of old queue entries from ring policy
> should be revisited. We need a mechanism to avoid multiple dequeueing of the
> same queue entry from concurrent threads. Only after introduction of such
> mechanism we can look into further performance optimisation for deletion of
> persistent queue entries.
> AutoCommitTransaction is used to dequeue entries on message expiration or
> breaching ring policy threshold. As result, the dequeueing operation for
> persistent queue entry blocks until queue entry record is removed from the
> store and the underlying store transaction is synced to disk. The sequential
> removal of multiple entries can results in unnecessary delays due to syncing
> disk on every dequeue.
> The broker performance for the corner cases described above can be
> significantly improved by using asynchronous transactions in dequeue
> operations.
> Asynchronous transaction does not wait for the store dequeue transaction to
> sync to disk. As result, the performance of removal unneeded queue entries
> can increase.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-8385) [Broker-J] Improve performance of dequeuing old queue entries on triggering ring policy
[
https://issues.apache.org/jira/browse/QPID-8385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002991#comment-17002991
]
Robert Godfrey edited comment on QPID-8385 at 12/24/19 8:45 PM:
[~orudyy] So one approach here is simply to implement equality on the
DelayedAcquisitionStateListener (and on the Runnable tasks passed therein).
The add function already tests for equality and doesn't add if the listener is
already present. I've knocked up a [patch|^QPID-8385_QPID-8393.patch] which
I think will do the trick (and also address the StackOverflowError in
QPID-8393).
was (Author: rgodfrey):
[~orudyy] So one approach here is simply to implement equality on the
DelayedAcquisitionStateListener (and on the Runnable tasks passed therein).
The add function already tests for equality and doesn't add if the listener is
already present. I've knocked up a quick patch which I think will do the trick
(and also address the StackOverflowError in QPID-8393).
> [Broker-J] Improve performance of dequeuing old queue entries on triggering
> ring policy
> ---
>
> Key: QPID-8385
> URL: https://issues.apache.org/jira/browse/QPID-8385
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
> Attachments:
> 0001-QPID-8385-Broker-J-Delete-queue-entry-asynchronously.patch,
> 0001-QPID-8385-Broker-J-Utilize-AsyncAutoCommitTransactio.patch,
> QPID-8385_QPID-8393.patch
>
>
> The performance of dequeuing old queue entries with triggering ring policy is
> affected by the following factors:
> * the oldest entry is not deleted immediately. As result, the deletion of
> the same oldest entry can be requested from multiple publishing IO threads
> * only one publishing thread can acquire the message with
> {{QueueEntry#acquireOrSteal}}, whilst the rest of publishing IO threads would
> set a {{DelayedAcquisitionStateListener}}. As result, thousands of
> {{DelayedAcquisitionStateListeners}} can be potentially set on the same queue
> entry
> * Setting of {{DelayedAcquisitionStateListeners}} from concurrent IO threads
> can consume host CPU up to 100% as there is a tight loop in
> {{StateChangeListenerEntry#add(StateChangeListenerEntry)}}. There is a
> risk of running into defect {{QPID-8393}} whilst setting a listener.
> * The old message is deleted in IO thread blocking the enqueing of new
> messages
> It seems that high CPU consumption on setting of
> {{DelayedAcquisitionStateListeners}} is the main contributor for the
> perfromance degradation on old entries dequeueing by ring policy.
> The current approach for dequeuing of old queue entries from ring policy
> should be revisited. We need a mechanism to avoid multiple dequeueing of the
> same queue entry from concurrent threads. Only after introduction of such
> mechanism we can look into further performance optimisation for deletion of
> persistent queue entries.
> AutoCommitTransaction is used to dequeue entries on message expiration or
> breaching ring policy threshold. As result, the dequeueing operation for
> persistent queue entry blocks until queue entry record is removed from the
> store and the underlying store transaction is synced to disk. The sequential
> removal of multiple entries can results in unnecessary delays due to syncing
> disk on every dequeue.
> The broker performance for the corner cases described above can be
> significantly improved by using asynchronous transactions in dequeue
> operations.
> Asynchronous transaction does not wait for the store dequeue transaction to
> sync to disk. As result, the performance of removal unneeded queue entries
> can increase.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8385) [Broker-J] Improve performance of dequeuing old queue entries on triggering ring policy
[
https://issues.apache.org/jira/browse/QPID-8385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Godfrey updated QPID-8385:
-
Attachment: QPID-8385_QPID-8393.patch
> [Broker-J] Improve performance of dequeuing old queue entries on triggering
> ring policy
> ---
>
> Key: QPID-8385
> URL: https://issues.apache.org/jira/browse/QPID-8385
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
> Attachments:
> 0001-QPID-8385-Broker-J-Delete-queue-entry-asynchronously.patch,
> 0001-QPID-8385-Broker-J-Utilize-AsyncAutoCommitTransactio.patch,
> QPID-8385_QPID-8393.patch
>
>
> The performance of dequeuing old queue entries with triggering ring policy is
> affected by the following factors:
> * the oldest entry is not deleted immediately. As result, the deletion of
> the same oldest entry can be requested from multiple publishing IO threads
> * only one publishing thread can acquire the message with
> {{QueueEntry#acquireOrSteal}}, whilst the rest of publishing IO threads would
> set a {{DelayedAcquisitionStateListener}}. As result, thousands of
> {{DelayedAcquisitionStateListeners}} can be potentially set on the same queue
> entry
> * Setting of {{DelayedAcquisitionStateListeners}} from concurrent IO threads
> can consume host CPU up to 100% as there is a tight loop in
> {{StateChangeListenerEntry#add(StateChangeListenerEntry)}}. There is a
> risk of running into defect {{QPID-8393}} whilst setting a listener.
> * The old message is deleted in IO thread blocking the enqueing of new
> messages
> It seems that high CPU consumption on setting of
> {{DelayedAcquisitionStateListeners}} is the main contributor for the
> perfromance degradation on old entries dequeueing by ring policy.
> The current approach for dequeuing of old queue entries from ring policy
> should be revisited. We need a mechanism to avoid multiple dequeueing of the
> same queue entry from concurrent threads. Only after introduction of such
> mechanism we can look into further performance optimisation for deletion of
> persistent queue entries.
> AutoCommitTransaction is used to dequeue entries on message expiration or
> breaching ring policy threshold. As result, the dequeueing operation for
> persistent queue entry blocks until queue entry record is removed from the
> store and the underlying store transaction is synced to disk. The sequential
> removal of multiple entries can results in unnecessary delays due to syncing
> disk on every dequeue.
> The broker performance for the corner cases described above can be
> significantly improved by using asynchronous transactions in dequeue
> operations.
> Asynchronous transaction does not wait for the store dequeue transaction to
> sync to disk. As result, the performance of removal unneeded queue entries
> can increase.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8385) [Broker-J] Improve performance of dequeuing old queue entries on triggering ring policy
[
https://issues.apache.org/jira/browse/QPID-8385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002991#comment-17002991
]
Robert Godfrey commented on QPID-8385:
--
[~orudyy] So one approach here is simply to implement equality on the
DelayedAcquisitionStateListener (and on the Runnable tasks passed therein).
The add function already tests for equality and doesn't add if the listener is
already present. I've knocked up a quick patch which I think will do the trick
(and also address the StackOverflowError in QPID-8393).
> [Broker-J] Improve performance of dequeuing old queue entries on triggering
> ring policy
> ---
>
> Key: QPID-8385
> URL: https://issues.apache.org/jira/browse/QPID-8385
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
> Attachments:
> 0001-QPID-8385-Broker-J-Delete-queue-entry-asynchronously.patch,
> 0001-QPID-8385-Broker-J-Utilize-AsyncAutoCommitTransactio.patch
>
>
> The performance of dequeuing old queue entries with triggering ring policy is
> affected by the following factors:
> * the oldest entry is not deleted immediately. As result, the deletion of
> the same oldest entry can be requested from multiple publishing IO threads
> * only one publishing thread can acquire the message with
> {{QueueEntry#acquireOrSteal}}, whilst the rest of publishing IO threads would
> set a {{DelayedAcquisitionStateListener}}. As result, thousands of
> {{DelayedAcquisitionStateListeners}} can be potentially set on the same queue
> entry
> * Setting of {{DelayedAcquisitionStateListeners}} from concurrent IO threads
> can consume host CPU up to 100% as there is a tight loop in
> {{StateChangeListenerEntry#add(StateChangeListenerEntry)}}. There is a
> risk of running into defect {{QPID-8393}} whilst setting a listener.
> * The old message is deleted in IO thread blocking the enqueing of new
> messages
> It seems that high CPU consumption on setting of
> {{DelayedAcquisitionStateListeners}} is the main contributor for the
> perfromance degradation on old entries dequeueing by ring policy.
> The current approach for dequeuing of old queue entries from ring policy
> should be revisited. We need a mechanism to avoid multiple dequeueing of the
> same queue entry from concurrent threads. Only after introduction of such
> mechanism we can look into further performance optimisation for deletion of
> persistent queue entries.
> AutoCommitTransaction is used to dequeue entries on message expiration or
> breaching ring policy threshold. As result, the dequeueing operation for
> persistent queue entry blocks until queue entry record is removed from the
> store and the underlying store transaction is synced to disk. The sequential
> removal of multiple entries can results in unnecessary delays due to syncing
> disk on every dequeue.
> The broker performance for the corner cases described above can be
> significantly improved by using asynchronous transactions in dequeue
> operations.
> Asynchronous transaction does not wait for the store dequeue transaction to
> sync to disk. As result, the performance of removal unneeded queue entries
> can increase.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8392) [Broker-J] Remove references to x-qpid-dlq-enabled from docs
[
https://issues.apache.org/jira/browse/QPID-8392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Godfrey updated QPID-8392:
-
Description: In Qpid 7.0 the way that DLQs were configured was changed, and
the implementation simplified (see QPID-7606), however documentation (and code)
was left over for the now non-functional {{x-qpid-dlq-enabled}} queue declare
argument. Attempting to use this argument when declaring a queue on v7.0 or
above now causes a cryptic error (unless suitable node creation policies are in
place). (was: In Qpid 7.0 the way that DLQs were configured was changed, and
the implementation simplified (see QPID-7606), however documentation (and code)
was left over for the now non-functional {{x-qpid-dlq-enabled}} queue declare
argument. Attempting to use this argument when declaring a queue on v7.0 or
above now causes a cryptic error (unless suitable node creation policies are
coincidentally in place).)
> [Broker-J] Remove references to x-qpid-dlq-enabled from docs
>
>
> Key: QPID-8392
> URL: https://issues.apache.org/jira/browse/QPID-8392
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Robert Godfrey
>Priority: Major
>
> In Qpid 7.0 the way that DLQs were configured was changed, and the
> implementation simplified (see QPID-7606), however documentation (and code)
> was left over for the now non-functional {{x-qpid-dlq-enabled}} queue declare
> argument. Attempting to use this argument when declaring a queue on v7.0 or
> above now causes a cryptic error (unless suitable node creation policies are
> in place).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8392) [Broker-J] Remove references to x-qpid-dlq-enabled from docs
[
https://issues.apache.org/jira/browse/QPID-8392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Godfrey updated QPID-8392:
-
Summary: [Broker-J] Remove references to x-qpid-dlq-enabled from docs
(was: [Broker-J] Remove references to x-qpid-dlq-enabled from code and docs)
> [Broker-J] Remove references to x-qpid-dlq-enabled from docs
>
>
> Key: QPID-8392
> URL: https://issues.apache.org/jira/browse/QPID-8392
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Robert Godfrey
>Priority: Major
>
> In Qpid 7.0 the way that DLQs were configured was changed, and the
> implementation simplified (see QPID-7606), however documentation (and code)
> was left over for the now non-functional {{x-qpid-dlq-enabled}} queue declare
> argument. Attempting to use this argument when declaring a queue on v7.0 or
> above now causes a cryptic error (unless suitable node creation policies are
> coincidentally in place).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8392) [Broker-J] Remove references to x-qpid-dlq-enabled from code and docs
Robert Godfrey created QPID-8392:
Summary: [Broker-J] Remove references to x-qpid-dlq-enabled from
code and docs
Key: QPID-8392
URL: https://issues.apache.org/jira/browse/QPID-8392
Project: Qpid
Issue Type: Improvement
Components: Broker-J
Reporter: Robert Godfrey
In Qpid 7.0 the way that DLQs were configured was changed, and the
implementation simplified (see QPID-7606), however documentation (and code) was
left over for the now non-functional {{x-qpid-dlq-enabled}} queue declare
argument. Attempting to use this argument when declaring a queue on v7.0 or
above now causes a cryptic error (unless suitable node creation policies are
coincidentally in place).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8389) [Broker-J] Support the ability to limit the number of active consumers
[ https://issues.apache.org/jira/browse/QPID-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999779#comment-16999779 ] Robert Godfrey commented on QPID-8389: -- So "operational" vs. "live"... I can't say I'm particularly fond of "live", but I think operational (or more specifically non-operational) gives the wrong impression. If I think of something as being non-operational I think of it being broken in some way. Active / non-active is clearly the best wording, but active already means something else for consumers in Broker-J. Maybe activated/standby? In terms of factoring the increment/decrement stuff... I'm ok with that In the test I actually wanted stuff prefetched and then returned when the consumer closes... (or in the case of 0-9-1 the session closes :-) ) Having isNonLive (or isStandby) a derived attribute makes sense > [Broker-J] Support the ability to limit the number of active consumers > -- > > Key: QPID-8389 > URL: https://issues.apache.org/jira/browse/QPID-8389 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Robert Godfrey >Assignee: Robert Godfrey >Priority: Major > Fix For: qpid-java-broker-8.0.0 > > > RabbitMQ supports an extension to queue.declare to designate that the queue > will support only one "active" consumer, while keeping other consumers > connected to act as a fast failover (see > [https://www.rabbitmq.com/consumers.html#single-active-consumer]). > We should add the ability for similar configuration to Broker-J -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8389) [Broker-J] Support the ability to limit the number of active consumers
[ https://issues.apache.org/jira/browse/QPID-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16991383#comment-16991383 ] Robert Godfrey commented on QPID-8389: -- Currently this does not fully support modifying the setting on a queue while consumers are attached. Nor is the value displayed (or modifiable) via the UI. Finally there is not obvious way of identifying which consumers are "live" and "nonlive" from viewing the consumer through management > [Broker-J] Support the ability to limit the number of active consumers > -- > > Key: QPID-8389 > URL: https://issues.apache.org/jira/browse/QPID-8389 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Robert Godfrey >Assignee: Robert Godfrey >Priority: Major > Fix For: qpid-java-broker-8.0.0 > > > RabbitMQ supports an extension to queue.declare to designate that the queue > will support only one "active" consumer, while keeping other consumers > connected to act as a fast failover (see > [https://www.rabbitmq.com/consumers.html#single-active-consumer]). > We should add the ability for similar configuration to Broker-J -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8389) [Broker-J] Support the ability to limit the number of active consumers
[ https://issues.apache.org/jira/browse/QPID-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Godfrey reassigned QPID-8389: Assignee: Robert Godfrey > [Broker-J] Support the ability to limit the number of active consumers > -- > > Key: QPID-8389 > URL: https://issues.apache.org/jira/browse/QPID-8389 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Robert Godfrey >Assignee: Robert Godfrey >Priority: Major > Fix For: qpid-java-broker-8.0.0 > > > RabbitMQ supports an extension to queue.declare to designate that the queue > will support only one "active" consumer, while keeping other consumers > connected to act as a fast failover (see > [https://www.rabbitmq.com/consumers.html#single-active-consumer]). > We should add the ability for similar configuration to Broker-J -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8388) [Broker-J] Allow for configuration to ignore unknown Queue arguments
[ https://issues.apache.org/jira/browse/QPID-8388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Godfrey reassigned QPID-8388: Assignee: Robert Godfrey > [Broker-J] Allow for configuration to ignore unknown Queue arguments > > > Key: QPID-8388 > URL: https://issues.apache.org/jira/browse/QPID-8388 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.5 >Reporter: Leo Keogh >Assignee: Robert Godfrey >Priority: Major > > As with issue https://issues.apache.org/jira/browse/QPID-8377 when using > Broker-J as an embedded test broker in place of an alternative AMQP 0-x > implementation, it can be useful to configure the broker to ignore *Queue > Declare* options that it does not support (rather than the default policy of > this causing a connection closure with error). > The queue we wish to test has the argument *x-single-active-consumer* with > causes the qpid test broker to fail with "Unsupported queue declare > argument(s) : x-single-active-consumer" in log > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8388) [Broker-J] Allow for configuration to ignore unknown Queue arguments
[ https://issues.apache.org/jira/browse/QPID-8388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Godfrey updated QPID-8388: - Issue Type: Improvement (was: Bug) > [Broker-J] Allow for configuration to ignore unknown Queue arguments > > > Key: QPID-8388 > URL: https://issues.apache.org/jira/browse/QPID-8388 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.5 >Reporter: Leo Keogh >Priority: Major > > As with issue https://issues.apache.org/jira/browse/QPID-8377 when using > Broker-J as an embedded test broker in place of an alternative AMQP 0-x > implementation, it can be useful to configure the broker to ignore *Queue > Declare* options that it does not support (rather than the default policy of > this causing a connection closure with error). > The queue we wish to test has the argument *x-single-active-consumer* with > causes the qpid test broker to fail with "Unsupported queue declare > argument(s) : x-single-active-consumer" in log > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8388) [Broker-J] Allow for configuration to ignore unknown Queue arguments
[ https://issues.apache.org/jira/browse/QPID-8388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988865#comment-16988865 ] Robert Godfrey commented on QPID-8388: -- I've made a change to enable the configuration of behaviour on queue declaration, but separately I think Broker-J should be enhanced with similar functionality (which I've raised as QPID-8389) > [Broker-J] Allow for configuration to ignore unknown Queue arguments > > > Key: QPID-8388 > URL: https://issues.apache.org/jira/browse/QPID-8388 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.5 >Reporter: Leo Keogh >Priority: Major > > As with issue https://issues.apache.org/jira/browse/QPID-8377 when using > Broker-J as an embedded test broker in place of an alternative AMQP 0-x > implementation, it can be useful to configure the broker to ignore *Queue > Declare* options that it does not support (rather than the default policy of > this causing a connection closure with error). > The queue we wish to test has the argument *x-single-active-consumer* with > causes the qpid test broker to fail with "Unsupported queue declare > argument(s) : x-single-active-consumer" in log > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8389) [Broker-J] Support the ability to limit the number of active consumers
Robert Godfrey created QPID-8389: Summary: [Broker-J] Support the ability to limit the number of active consumers Key: QPID-8389 URL: https://issues.apache.org/jira/browse/QPID-8389 Project: Qpid Issue Type: Improvement Components: Broker-J Reporter: Robert Godfrey Fix For: qpid-java-broker-8.0.0 RabbitMQ supports an extension to queue.declare to designate that the queue will support only one "active" consumer, while keeping other consumers connected to act as a fast failover (see [https://www.rabbitmq.com/consumers.html#single-active-consumer]). We should add the ability for similar configuration to Broker-J -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8378) [Broker-J] Message references can be leaked in some rare circumstances
[
https://issues.apache.org/jira/browse/QPID-8378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Godfrey updated QPID-8378:
-
Description: A defect was found in changes for method
{{AbstractQueue#visit()QueueEntryVisitor}} introduced as part of QPID-8273. In
some rare circumstance the message references can be leaked (when method
{{#visitor()}} is called and entry is deleted between call to
{{QueueEntryIterator#advance}} and
{{org.apache.qpid.server.queue.QueueEntry#newMessageReference}} ), which could
result in unexpected message references left behind. Potentially, the
persistent message can be left un-deleted after removal of queue entry. (was:
A defect was found in changes for method
{{AbstractQueue#visit()QueueEntryVisitor}} introduced as part of QPID-8273. In
some rear circumstance the message references can be leaked (when method
{{#visitor()}} is called and entry is deleted between call to
{{QueueEntryIterator#advance}} and
{{org.apache.qpid.server.queue.QueueEntry#newMessageReference}} ), which could
result in unexpected message references left behind. Potentially, the
persistent message can be left un-deleted after removal of queue entry.)
> [Broker-J] Message references can be leaked in some rare circumstances
> --
>
> Key: QPID-8378
> URL: https://issues.apache.org/jira/browse/QPID-8378
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.1, qpid-java-broker-7.1.2,
> qpid-java-broker-7.1.3, qpid-java-broker-7.1.4, qpid-java-broker-7.1.5
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.6
>
>
> A defect was found in changes for method
> {{AbstractQueue#visit()QueueEntryVisitor}} introduced as part of QPID-8273.
> In some rare circumstance the message references can be leaked (when method
> {{#visitor()}} is called and entry is deleted between call to
> {{QueueEntryIterator#advance}} and
> {{org.apache.qpid.server.queue.QueueEntry#newMessageReference}} ), which
> could result in unexpected message references left behind. Potentially, the
> persistent message can be left un-deleted after removal of queue entry.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8378) [Broker-J] Message references can be leaked in some rare circumstances
[
https://issues.apache.org/jira/browse/QPID-8378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Godfrey updated QPID-8378:
-
Summary: [Broker-J] Message references can be leaked in some rare
circumstances (was: [Broker-J] Message references can be leaked in some rear
circumstances)
> [Broker-J] Message references can be leaked in some rare circumstances
> --
>
> Key: QPID-8378
> URL: https://issues.apache.org/jira/browse/QPID-8378
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.1, qpid-java-broker-7.1.2,
> qpid-java-broker-7.1.3, qpid-java-broker-7.1.4, qpid-java-broker-7.1.5
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.6
>
>
> A defect was found in changes for method
> {{AbstractQueue#visit()QueueEntryVisitor}} introduced as part of QPID-8273.
> In some rear circumstance the message references can be leaked (when method
> {{#visitor()}} is called and entry is deleted between call to
> {{QueueEntryIterator#advance}} and
> {{org.apache.qpid.server.queue.QueueEntry#newMessageReference}} ), which
> could result in unexpected message references left behind. Potentially, the
> persistent message can be left un-deleted after removal of queue entry.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8376) [Broker-J] Add Process CPU time to collected Broker statistics
[ https://issues.apache.org/jira/browse/QPID-8376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16980521#comment-16980521 ] Robert Godfrey commented on QPID-8376: -- I've tested now on Oracle JDK 8 on OS X, Open JDK 11 (Hotspot and J9 versions) on OS X, and IBM JDK on x86-64 Linux ... and everything seemed to work as expected > [Broker-J] Add Process CPU time to collected Broker statistics > -- > > Key: QPID-8376 > URL: https://issues.apache.org/jira/browse/QPID-8376 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Robert Godfrey >Assignee: Robert Godfrey >Priority: Minor > Fix For: qpid-java-broker-8.0.0 > > Attachments: > 0001-QPID-8376-Broker-J-Handle-InaccessibleObjectExceptio.patch > > > As per > [this|http://qpid.2158936.n2.nabble.com/Broker-J-statistics-and-CPU-consumption-tp7687889.html] > discussion on the mailing list - add the ability to capture CPU time and CPU > load from the broker statistics (where available from the underlying JVM > platform. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8382) [Broker-J] Allow for attribute injectors to be type specific
[ https://issues.apache.org/jira/browse/QPID-8382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Godfrey updated QPID-8382: - Status: Reviewable (was: In Progress) > [Broker-J] Allow for attribute injectors to be type specific > > > Key: QPID-8382 > URL: https://issues.apache.org/jira/browse/QPID-8382 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Robert Godfrey >Assignee: Robert Godfrey >Priority: Major > > As discussed in QPID-8376 is makes sense to allow for attribute injectors to > indicate which object types they apply to (as well as indicating this on the > individual attribute level) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8382) [Broker-J] Allow for attribute injectors to be type specific
Robert Godfrey created QPID-8382: Summary: [Broker-J] Allow for attribute injectors to be type specific Key: QPID-8382 URL: https://issues.apache.org/jira/browse/QPID-8382 Project: Qpid Issue Type: Improvement Components: Broker-J Reporter: Robert Godfrey Assignee: Robert Godfrey As discussed in QPID-8376 is makes sense to allow for attribute injectors to indicate which object types they apply to (as well as indicating this on the individual attribute level) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8376) [Broker-J] Add Process CPU time to collected Broker statistics
[ https://issues.apache.org/jira/browse/QPID-8376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16978350#comment-16978350 ] Robert Godfrey commented on QPID-8376: -- All good with me - apologies for not testing with the IBM JDK. As an aside - why is BrokerAttributeInjector being called by every class, that seems sub-optimal (and probably my fault at some point in the past :) ) > [Broker-J] Add Process CPU time to collected Broker statistics > -- > > Key: QPID-8376 > URL: https://issues.apache.org/jira/browse/QPID-8376 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Robert Godfrey >Assignee: Robert Godfrey >Priority: Minor > Fix For: qpid-java-broker-8.0.0 > > Attachments: > 0001-QPID-8376-Broker-J-Handle-InaccessibleObjectExceptio.patch > > > As per > [this|http://qpid.2158936.n2.nabble.com/Broker-J-statistics-and-CPU-consumption-tp7687889.html] > discussion on the mailing list - add the ability to capture CPU time and CPU > load from the broker statistics (where available from the underlying JVM > platform. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8380) [Broker-J] getMessageInfo on a queue does not include groupId
[ https://issues.apache.org/jira/browse/QPID-8380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Godfrey updated QPID-8380: - Status: Reviewable (was: In Progress) > [Broker-J] getMessageInfo on a queue does not include groupId > - > > Key: QPID-8380 > URL: https://issues.apache.org/jira/browse/QPID-8380 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Robert Godfrey >Assignee: Robert Godfrey >Priority: Major > > As per the > [discussion|https://lists.apache.org/thread.html/f3786a89ac67b379c6957d141e12a5aab93f8391c4fe6c5c94bd2542@%3Cusers.qpid.apache.org%3E] > on the mailing, getting the messageInfo on a message using the REST API does > not currently contain the group id. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8380) [Broker-J] getMessageInfo on a queue does not include groupId
Robert Godfrey created QPID-8380: Summary: [Broker-J] getMessageInfo on a queue does not include groupId Key: QPID-8380 URL: https://issues.apache.org/jira/browse/QPID-8380 Project: Qpid Issue Type: Improvement Components: Broker-J Reporter: Robert Godfrey Assignee: Robert Godfrey As per the [discussion|https://lists.apache.org/thread.html/f3786a89ac67b379c6957d141e12a5aab93f8391c4fe6c5c94bd2542@%3Cusers.qpid.apache.org%3E] on the mailing, getting the messageInfo on a message using the REST API does not currently contain the group id. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8377) [Broker-J] Allow for configuration to ignore unknown Exchange.Declare arguments
[
https://issues.apache.org/jira/browse/QPID-8377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16977238#comment-16977238
]
Robert Godfrey commented on QPID-8377:
--
Thanks Alex - must have been unlucky in the choices of test files that I was
looking at for examples! I'll add a test to cover this case
> [Broker-J] Allow for configuration to ignore unknown Exchange.Declare
> arguments
> ---
>
> Key: QPID-8377
> URL: https://issues.apache.org/jira/browse/QPID-8377
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Robert Godfrey
>Assignee: Robert Godfrey
>Priority: Minor
>
> As per the mailing list discussion
> [here|http://mail-archives.apache.org/mod_mbox/qpid-users/201911.mbox/%3CCAH-wkTg4bQ2Gc83HHvUKZzC%2BXbvKimUV5Bx%2B_J9bbDXAQAYM-A%40mail.gmail.com%3E]
> when using Broker-J as an embedded test broker in place of an alternative
> AMQP 0-x implementation, it can be useful to configure the broker to ignore
> Exchange Declare options that it does not support (rather than the default
> policy of this causing a connection closure with error).
> As per the suggestion in the follow-up mail - allow for the policy to be
> configured via a context variable, such that, for example, the behaviour can
> be changed to ignore such failures simply by setting the system property
> {{exchange.behaviourOnUnknownDeclareArgument}}
> to {{IGNORE}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8377) [Broker-J] Allow for configuration to ignore unknown Exchange.Declare arguments
[
https://issues.apache.org/jira/browse/QPID-8377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976181#comment-16976181
]
Robert Godfrey commented on QPID-8377:
--
[~orudyy] is there an easy way to write a protocol test where we set a context
variable prior to execution? I didn't see any examples to copy from :)
> [Broker-J] Allow for configuration to ignore unknown Exchange.Declare
> arguments
> ---
>
> Key: QPID-8377
> URL: https://issues.apache.org/jira/browse/QPID-8377
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Robert Godfrey
>Assignee: Robert Godfrey
>Priority: Minor
>
> As per the mailing list discussion
> [here|http://mail-archives.apache.org/mod_mbox/qpid-users/201911.mbox/%3CCAH-wkTg4bQ2Gc83HHvUKZzC%2BXbvKimUV5Bx%2B_J9bbDXAQAYM-A%40mail.gmail.com%3E]
> when using Broker-J as an embedded test broker in place of an alternative
> AMQP 0-x implementation, it can be useful to configure the broker to ignore
> Exchange Declare options that it does not support (rather than the default
> policy of this causing a connection closure with error).
> As per the suggestion in the follow-up mail - allow for the policy to be
> configured via a context variable, such that, for example, the behaviour can
> be changed to ignore such failures simply by setting the system property
> {{exchange.behaviourOnUnknownDeclareArgument}}
> to {{IGNORE}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8377) [Broker-J] Allow for configuration to ignore unknown Exchange.Declare arguments
[
https://issues.apache.org/jira/browse/QPID-8377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Godfrey updated QPID-8377:
-
Status: Reviewable (was: In Progress)
> [Broker-J] Allow for configuration to ignore unknown Exchange.Declare
> arguments
> ---
>
> Key: QPID-8377
> URL: https://issues.apache.org/jira/browse/QPID-8377
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Robert Godfrey
>Assignee: Robert Godfrey
>Priority: Minor
>
> As per the mailing list discussion
> [here|http://mail-archives.apache.org/mod_mbox/qpid-users/201911.mbox/%3CCAH-wkTg4bQ2Gc83HHvUKZzC%2BXbvKimUV5Bx%2B_J9bbDXAQAYM-A%40mail.gmail.com%3E]
> when using Broker-J as an embedded test broker in place of an alternative
> AMQP 0-x implementation, it can be useful to configure the broker to ignore
> Exchange Declare options that it does not support (rather than the default
> policy of this causing a connection closure with error).
> As per the suggestion in the follow-up mail - allow for the policy to be
> configured via a context variable, such that, for example, the behaviour can
> be changed to ignore such failures simply by setting the system property
> {{exchange.behaviourOnUnknownDeclareArgument}}
> to {{IGNORE}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8377) [Broker-J] Allow for configuration to ignore unknown Exchange.Declare arguments
Robert Godfrey created QPID-8377:
Summary: [Broker-J] Allow for configuration to ignore unknown
Exchange.Declare arguments
Key: QPID-8377
URL: https://issues.apache.org/jira/browse/QPID-8377
Project: Qpid
Issue Type: Improvement
Components: Broker-J
Reporter: Robert Godfrey
Assignee: Robert Godfrey
As per the mailing list discussion
[here|http://mail-archives.apache.org/mod_mbox/qpid-users/201911.mbox/%3CCAH-wkTg4bQ2Gc83HHvUKZzC%2BXbvKimUV5Bx%2B_J9bbDXAQAYM-A%40mail.gmail.com%3E]
when using Broker-J as an embedded test broker in place of an alternative AMQP
0-x implementation, it can be useful to configure the broker to ignore Exchange
Declare options that it does not support (rather than the default policy of
this causing a connection closure with error).
As per the suggestion in the follow-up mail - allow for the policy to be
configured via a context variable, such that, for example, the behaviour can be
changed to ignore such failures simply by setting the system property
{{exchange.behaviourOnUnknownDeclareArgument}}
to {{IGNORE}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8376) [Broker-J] Add Process CPU time to collected Broker statistics
[ https://issues.apache.org/jira/browse/QPID-8376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Godfrey updated QPID-8376: - Fix Version/s: qpid-java-broker-8.0.0 > [Broker-J] Add Process CPU time to collected Broker statistics > -- > > Key: QPID-8376 > URL: https://issues.apache.org/jira/browse/QPID-8376 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Robert Godfrey >Assignee: Robert Godfrey >Priority: Minor > Fix For: qpid-java-broker-8.0.0 > > > As per > [this|http://qpid.2158936.n2.nabble.com/Broker-J-statistics-and-CPU-consumption-tp7687889.html] > discussion on the mailing list - add the ability to capture CPU time and CPU > load from the broker statistics (where available from the underlying JVM > platform. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8376) [Broker-J] Add Process CPU time to collected Broker statistics
[ https://issues.apache.org/jira/browse/QPID-8376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Godfrey updated QPID-8376: - Status: Reviewable (was: In Progress) > [Broker-J] Add Process CPU time to collected Broker statistics > -- > > Key: QPID-8376 > URL: https://issues.apache.org/jira/browse/QPID-8376 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Robert Godfrey >Assignee: Robert Godfrey >Priority: Minor > > As per > [this|http://qpid.2158936.n2.nabble.com/Broker-J-statistics-and-CPU-consumption-tp7687889.html] > discussion on the mailing list - add the ability to capture CPU time and CPU > load from the broker statistics (where available from the underlying JVM > platform. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8376) [Broker-J] Add Process CPU time to collected Broker statistics
Robert Godfrey created QPID-8376: Summary: [Broker-J] Add Process CPU time to collected Broker statistics Key: QPID-8376 URL: https://issues.apache.org/jira/browse/QPID-8376 Project: Qpid Issue Type: Improvement Components: Broker-J Reporter: Robert Godfrey Assignee: Robert Godfrey As per [this|http://qpid.2158936.n2.nabble.com/Broker-J-statistics-and-CPU-consumption-tp7687889.html] discussion on the mailing list - add the ability to capture CPU time and CPU load from the broker statistics (where available from the underlying JVM platform. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8331) [Broker-J] Upgrade derby dependency
[ https://issues.apache.org/jira/browse/QPID-8331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16950138#comment-16950138 ] Robert Godfrey commented on QPID-8331: -- While it makes complete sense to upgrade Derby... my recollection is that there is no open network server port for Derby that is exposed - we run Derby purely as an embedded service, so I would think that even using the old version Qpid would not be vulnerable > [Broker-J] Upgrade derby dependency > --- > > Key: QPID-8331 > URL: https://issues.apache.org/jira/browse/QPID-8331 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.0 > > > Upgrade derby dependency to version 10.14.2.0 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8369) [Broker-J] Limit number of connections per user
[ https://issues.apache.org/jira/browse/QPID-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16947288#comment-16947288 ] Robert Godfrey commented on QPID-8369: -- bq. Obviously, the rule will limit only AMQP connections. If malicious user would try to perform DOS attack, the rule would be applied on finishing of authentication stage. Thus, before the authentication any number of TCP connections can be created. I am wondering whether a similar limits can be applied to IP or domain addresses in order to restrict the number of TCP connections which can be open from given host or domain address. Thus, if IP/domain address check is performed immediately after opening of TCP connection, it would eliminate the need to wait for applying the limit for connection principal, if IP/domain address limit is breached. Thus, such breaching connection would be closed immediately and might save some host resources. I am not sure whether adding such check make sense. Perhaps, it should be a responsibility of some proxy/gateway sitting in front of the broker instance. What do you think? I think that if protection against deliberate DoS attacks is desired, this should be implemented elsewhere in a gateway / hardware device. I do not think it makes sense to re-implement this functionality in the Broker (particularly as the very act of handling the connection and then determining that it should be denied will in itself take resources, and so would still leave the broker vulnerable to such a deliberate attack). > [Broker-J] Limit number of connections per user > --- > > Key: QPID-8369 > URL: https://issues.apache.org/jira/browse/QPID-8369 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Tomas Vavricka >Priority: Major > Labels: connection, limit, user > Fix For: qpid-java-broker-8.0.0 > > Attachments: > 0001-QPID-8369-Broker-J-WIP-Add-connection-limit-support-.patch > > > There is only limit for number of connections per amqp/amqps port. > If some user creates too much connections, he can prevent other users from > connecting to amqp ports. > Qpid Broker-J should support some limitation for connections per user. > Broker should also support limitation of number of created connections per > time frame ex: create 60 connections per one minute at maximum -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
