[jira] [Created] (DISPATCH-1065) Doc new router statistics
Ben Hardesty created DISPATCH-1065: -- Summary: Doc new router statistics Key: DISPATCH-1065 URL: https://issues.apache.org/jira/browse/DISPATCH-1065 Project: Qpid Dispatch Issue Type: Improvement Components: Documentation Affects Versions: 1.2.0 Reporter: Ben Hardesty Assignee: Ben Hardesty Additional statistics are available from the router via the management protocol. New statistics include: * Number of pre-settled deliveries dropped on a link * Global scope counters for link and address statistics * Per-ingress counts for settled deliveries on egress links Managment tool doc (qdstat/qdmanage) should be updated to reflect these new statistics. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8208) [Broker-J] Improve handling of unexpected exceptions on establishing LDAP connections in SimpleLDAPAuthenticationProvider
[
https://issues.apache.org/jira/browse/QPID-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16534062#comment-16534062
]
ASF GitHub Bot commented on QPID-8208:
--
Github user overmeulen commented on a diff in the pull request:
https://github.com/apache/qpid-broker-j/pull/9#discussion_r200465916
--- Diff:
broker-plugins/jdbc-store/src/main/java/org/apache/qpid/server/store/jdbc/JDBCDetails.java
---
@@ -379,7 +403,8 @@ public boolean isOverridden()
return
contextMap.containsKey(CONTEXT_JDBCSTORE_USEBYTESFORBLOB)
||
contextMap.containsKey(CONTEXT_JDBCSTORE_BIGINTTYPE)
||
contextMap.containsKey(CONTEXT_JDBCSTORE_VARBINARYTYPE)
-||
contextMap.containsKey(CONTEXT_JDBCSTORE_BLOBTYPE);
+||
contextMap.containsKey(CONTEXT_JDBCSTORE_BLOBTYPE)
--- End diff --
The method modified here is isOverridden() not isUseBytesMethodForBlob()
> [Broker-J] Improve handling of unexpected exceptions on establishing LDAP
> connections in SimpleLDAPAuthenticationProvider
> --
>
> Key: QPID-8208
> URL: https://issues.apache.org/jira/browse/QPID-8208
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, 0.32, qpid-java-6.0, qpid-java-6.0.1,
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5,
> qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1,
> qpid-java-broker-7.0.4
>Reporter: Alex Rudyy
>Priority: Critical
>
> There is a weakness in Qpid exception handling when communication with
> external services like LDAP. The Broker should take a more defensive approach
> and handle unexpected exceptions thrown by underlying third-party API in
> addition to exceptions declared in API interfaces. The unexpected exceptions
> thrown by underlying API should not affect the stability of the Broker.
> It was reported that on establishment of connection with LDAP using default
> context factory {{com.sun.jndi.ldap.LdapCtxFactory}} the creation of
> {{InitialDirContext}} can end-up in unexpected exception thrown from
> {{com.sun.jndi.ldap.LdapClient}}. It looks like a defect in
> {{com.sun.jndi.ldap.LdapClient}}, but I could not find any existing open bug
> report raised against JVM with similar behaviour. I think that Broker should
> catch unexpected exception, log it and report authentication failure back to
> the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-broker-j pull request #9: [QPID-8208] Fix Sybase support for the link-s...
Github user overmeulen commented on a diff in the pull request: https://github.com/apache/qpid-broker-j/pull/9#discussion_r200465916 --- Diff: broker-plugins/jdbc-store/src/main/java/org/apache/qpid/server/store/jdbc/JDBCDetails.java --- @@ -379,7 +403,8 @@ public boolean isOverridden() return contextMap.containsKey(CONTEXT_JDBCSTORE_USEBYTESFORBLOB) || contextMap.containsKey(CONTEXT_JDBCSTORE_BIGINTTYPE) || contextMap.containsKey(CONTEXT_JDBCSTORE_VARBINARYTYPE) -|| contextMap.containsKey(CONTEXT_JDBCSTORE_BLOBTYPE); +|| contextMap.containsKey(CONTEXT_JDBCSTORE_BLOBTYPE) --- End diff -- The method modified here is isOverridden() not isUseBytesMethodForBlob() --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1064) Doc link route reconnect behavior
Ben Hardesty created DISPATCH-1064: -- Summary: Doc link route reconnect behavior Key: DISPATCH-1064 URL: https://issues.apache.org/jira/browse/DISPATCH-1064 Project: Qpid Dispatch Issue Type: Improvement Components: Documentation Affects Versions: 1.2.0 Reporter: Ben Hardesty Assignee: Ben Hardesty When the router is configured with a linkRoute and client connects using failover, the link will not be reestablished should the router's connection to the broker fail. If auto-reconnect is required, the router should be configured with autoLink. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1885) [python] move tests/python to python/tests
Alan Conway created PROTON-1885: --- Summary: [python] move tests/python to python/tests Key: PROTON-1885 URL: https://issues.apache.org/jira/browse/PROTON-1885 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: proton-c-0.23.0 Reporter: Alan Conway Assignee: Alan Conway The tests under tests/python are testing the python binding, but are also providing much of the coverage for the proton C library. Since they can't run unless the python binding is built, it seems more consistent to put them in python/tests like other bindings. Going forward we will add native C tests under c/tests to get coverage without relying on python. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1063) Receiver unable to receive messages on waypoint address with external-address in two router case
[
https://issues.apache.org/jira/browse/DISPATCH-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533953#comment-16533953
]
ASF subversion and git services commented on DISPATCH-1063:
---
Commit e2f73cdc27fdc81fcc92d0cb882323562b119f5d in qpid-dispatch's branch
refs/heads/master from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=e2f73cd ]
DISPATCH-1063 - Ensure that the to-override for a delivery uses the
internal/routable address and not the external address for an auto-link.
> Receiver unable to receive messages on waypoint address with external-address
> in two router case
>
>
> Key: DISPATCH-1063
> URL: https://issues.apache.org/jira/browse/DISPATCH-1063
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.1.0, 1.2.0
>Reporter: Ganesh Murthy
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.3.0
>
> Attachments: A2.conf, B2.conf
>
>
> Start two routers with the attached config files.
> Start a broker on port amqp and create a queue called abc.sms
> Attach a sender to Router B and send 100 messages to the "notify" address
> like this
> {noformat}
> python simple_recv.py -m100 --address 0.0.0.0:20101/notify{noformat}
> Attach a Receiver to Router B and receive 1 message from the "notify" address
> like this -
> {noformat}
> python simple_recv.py -m1 --address 0.0.0.0:20101/notify{noformat}
> The receiver never receives the message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1063) Receiver unable to receive messages on waypoint address with external-address in two router case
[
https://issues.apache.org/jira/browse/DISPATCH-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved DISPATCH-1063.
Resolution: Fixed
> Receiver unable to receive messages on waypoint address with external-address
> in two router case
>
>
> Key: DISPATCH-1063
> URL: https://issues.apache.org/jira/browse/DISPATCH-1063
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.1.0, 1.2.0
>Reporter: Ganesh Murthy
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.3.0
>
> Attachments: A2.conf, B2.conf
>
>
> Start two routers with the attached config files.
> Start a broker on port amqp and create a queue called abc.sms
> Attach a sender to Router B and send 100 messages to the "notify" address
> like this
> {noformat}
> python simple_recv.py -m100 --address 0.0.0.0:20101/notify{noformat}
> Attach a Receiver to Router B and receive 1 message from the "notify" address
> like this -
> {noformat}
> python simple_recv.py -m1 --address 0.0.0.0:20101/notify{noformat}
> The receiver never receives the message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1063) Receiver unable to receive messages on waypoint address with external-address in two router case
[
https://issues.apache.org/jira/browse/DISPATCH-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-1063:
---
Summary: Receiver unable to receive messages on waypoint address with
external-address in two router case (was: Receiver unable to receive messages
on waypoint address in two router case)
> Receiver unable to receive messages on waypoint address with external-address
> in two router case
>
>
> Key: DISPATCH-1063
> URL: https://issues.apache.org/jira/browse/DISPATCH-1063
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.1.0, 1.2.0
>Reporter: Ganesh Murthy
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.3.0
>
> Attachments: A2.conf, B2.conf
>
>
> Start two routers with the attached config files.
> Start a broker on port amqp and create a queue called abc.sms
> Attach a sender to Router B and send 100 messages to the "notify" address
> like this
> {noformat}
> python simple_recv.py -m100 --address 0.0.0.0:20101/notify{noformat}
> Attach a Receiver to Router B and receive 1 message from the "notify" address
> like this -
> {noformat}
> python simple_recv.py -m1 --address 0.0.0.0:20101/notify{noformat}
> The receiver never receives the message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1063) Receiver unable to receive messages on waypoint address in two router case
[
https://issues.apache.org/jira/browse/DISPATCH-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-1063:
---
Fix Version/s: 1.3.0
> Receiver unable to receive messages on waypoint address in two router case
> --
>
> Key: DISPATCH-1063
> URL: https://issues.apache.org/jira/browse/DISPATCH-1063
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.1.0, 1.2.0
>Reporter: Ganesh Murthy
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.3.0
>
> Attachments: A2.conf, B2.conf
>
>
> Start two routers with the attached config files.
> Start a broker on port amqp and create a queue called abc.sms
> Attach a sender to Router B and send 100 messages to the "notify" address
> like this
> {noformat}
> python simple_recv.py -m100 --address 0.0.0.0:20101/notify{noformat}
> Attach a Receiver to Router B and receive 1 message from the "notify" address
> like this -
> {noformat}
> python simple_recv.py -m1 --address 0.0.0.0:20101/notify{noformat}
> The receiver never receives the message
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7153) Allow expired messages to be sent to DLQ
[
https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533872#comment-16533872
]
Alex Rudyy commented on QPID-7153:
--
Rob,
I reverted the changes around {{wouldExpire}} and restored previous version of
the predicate passed into {{routeToAlternate}}.
A second version of the patch is attached.
> Allow expired messages to be sent to DLQ
>
>
> Key: QPID-7153
> URL: https://issues.apache.org/jira/browse/QPID-7153
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments: 0002-QPID-7153-Adress-review-comments-v2.patch,
> 0002-QPID-7153-Adress-review-comments.patch, QPID-7153v2.diff
>
>
> Currently the Java Broker simply discards messages that expire (TTL). The
> behaviour should be configurable and allow for expired messages to be
> directed to the alternate exchange to allow for dead-lettering.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7153) Allow expired messages to be sent to DLQ
[ https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7153: - Attachment: 0002-QPID-7153-Adress-review-comments-v2.patch > Allow expired messages to be sent to DLQ > > > Key: QPID-7153 > URL: https://issues.apache.org/jira/browse/QPID-7153 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: 0002-QPID-7153-Adress-review-comments-v2.patch, > 0002-QPID-7153-Adress-review-comments.patch, QPID-7153v2.diff > > > Currently the Java Broker simply discards messages that expire (TTL). The > behaviour should be configurable and allow for expired messages to be > directed to the alternate exchange to allow for dead-lettering. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1703) [cpp] Remove auto_settle from receiver options
[ https://issues.apache.org/jira/browse/PROTON-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533865#comment-16533865 ] Alan Conway commented on PROTON-1703: - I think the deprecated macros and comments are sufficient for marking the source code, but I like Robbie's suggestion of a master Jira. In this case the fix was made and reverted, so having a link to the Jira gives us the fix to be re-applied. When we get to a breaking release we can check both the linked Jiras and the source code to make sure we fix everything with maximum information. > [cpp] Remove auto_settle from receiver options > -- > > Key: PROTON-1703 > URL: https://issues.apache.org/jira/browse/PROTON-1703 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.19.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > > auto_settle is a sender-only option, the receiver equivalent is auto_accept. > auto_settle is only used at messaging_adapter.cpp#L172, which applies only to > senders, it was included in the option list by mistake. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8208) [Broker-J] Improve handling of unexpected exceptions on establishing LDAP connections in SimpleLDAPAuthenticationProvider
[
https://issues.apache.org/jira/browse/QPID-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533863#comment-16533863
]
ASF GitHub Bot commented on QPID-8208:
--
Github user alex-rufous commented on a diff in the pull request:
https://github.com/apache/qpid-broker-j/pull/9#discussion_r200405733
--- Diff:
broker-core/src/test/java/org/apache/qpid/server/store/BrokerStoreUpgraderAndRecovererTest.java
---
@@ -106,6 +106,7 @@ public void
testUpgradeVirtualHostWithJDBCStoreAndBoneCPPool()
hostAttributes.put("jdbcBigIntType", "mybigint");
hostAttributes.put("jdbcBlobType", "myblob");
hostAttributes.put("jdbcVarbinaryType", "myvarbinary");
+hostAttributes.put("jdbcTimestampType", "mytimestamp");
--- End diff --
Please undo the change as attribute "jdbcTimestampType" never existed in
previous models
> [Broker-J] Improve handling of unexpected exceptions on establishing LDAP
> connections in SimpleLDAPAuthenticationProvider
> --
>
> Key: QPID-8208
> URL: https://issues.apache.org/jira/browse/QPID-8208
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, 0.32, qpid-java-6.0, qpid-java-6.0.1,
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5,
> qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1,
> qpid-java-broker-7.0.4
>Reporter: Alex Rudyy
>Priority: Critical
>
> There is a weakness in Qpid exception handling when communication with
> external services like LDAP. The Broker should take a more defensive approach
> and handle unexpected exceptions thrown by underlying third-party API in
> addition to exceptions declared in API interfaces. The unexpected exceptions
> thrown by underlying API should not affect the stability of the Broker.
> It was reported that on establishment of connection with LDAP using default
> context factory {{com.sun.jndi.ldap.LdapCtxFactory}} the creation of
> {{InitialDirContext}} can end-up in unexpected exception thrown from
> {{com.sun.jndi.ldap.LdapClient}}. It looks like a defect in
> {{com.sun.jndi.ldap.LdapClient}}, but I could not find any existing open bug
> report raised against JVM with similar behaviour. I think that Broker should
> catch unexpected exception, log it and report authentication failure back to
> the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8208) [Broker-J] Improve handling of unexpected exceptions on establishing LDAP connections in SimpleLDAPAuthenticationProvider
[
https://issues.apache.org/jira/browse/QPID-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533858#comment-16533858
]
ASF GitHub Bot commented on QPID-8208:
--
Github user alex-rufous commented on a diff in the pull request:
https://github.com/apache/qpid-broker-j/pull/9#discussion_r200406371
--- Diff:
broker-core/src/test/java/org/apache/qpid/server/store/BrokerStoreUpgraderAndRecovererTest.java
---
@@ -131,6 +132,7 @@ public void
testUpgradeVirtualHostWithJDBCStoreAndBoneCPPool()
context.put("qpid.jdbcstore.bigIntType", "mybigint");
context.put("qpid.jdbcstore.varBinaryType", "myvarbinary");
context.put("qpid.jdbcstore.blobType", "myblob");
+context.put("qpid.jdbcstore.timestampType", "mytimestamp");
--- End diff --
Please undo the change as context variable "qpid.jdbcstore.timestampType"
did not exist in previous model versions
> [Broker-J] Improve handling of unexpected exceptions on establishing LDAP
> connections in SimpleLDAPAuthenticationProvider
> --
>
> Key: QPID-8208
> URL: https://issues.apache.org/jira/browse/QPID-8208
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, 0.32, qpid-java-6.0, qpid-java-6.0.1,
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5,
> qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1,
> qpid-java-broker-7.0.4
>Reporter: Alex Rudyy
>Priority: Critical
>
> There is a weakness in Qpid exception handling when communication with
> external services like LDAP. The Broker should take a more defensive approach
> and handle unexpected exceptions thrown by underlying third-party API in
> addition to exceptions declared in API interfaces. The unexpected exceptions
> thrown by underlying API should not affect the stability of the Broker.
> It was reported that on establishment of connection with LDAP using default
> context factory {{com.sun.jndi.ldap.LdapCtxFactory}} the creation of
> {{InitialDirContext}} can end-up in unexpected exception thrown from
> {{com.sun.jndi.ldap.LdapClient}}. It looks like a defect in
> {{com.sun.jndi.ldap.LdapClient}}, but I could not find any existing open bug
> report raised against JVM with similar behaviour. I think that Broker should
> catch unexpected exception, log it and report authentication failure back to
> the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8208) [Broker-J] Improve handling of unexpected exceptions on establishing LDAP connections in SimpleLDAPAuthenticationProvider
[
https://issues.apache.org/jira/browse/QPID-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533862#comment-16533862
]
ASF GitHub Bot commented on QPID-8208:
--
Github user alex-rufous commented on a diff in the pull request:
https://github.com/apache/qpid-broker-j/pull/9#discussion_r200407725
--- Diff:
broker-plugins/jdbc-store/src/main/java/org/apache/qpid/server/store/jdbc/JDBCDetails.java
---
@@ -379,7 +403,8 @@ public boolean isOverridden()
return
contextMap.containsKey(CONTEXT_JDBCSTORE_USEBYTESFORBLOB)
||
contextMap.containsKey(CONTEXT_JDBCSTORE_BIGINTTYPE)
||
contextMap.containsKey(CONTEXT_JDBCSTORE_VARBINARYTYPE)
-||
contextMap.containsKey(CONTEXT_JDBCSTORE_BLOBTYPE);
+||
contextMap.containsKey(CONTEXT_JDBCSTORE_BLOBTYPE)
--- End diff --
Please undo the change as context variable for timestamp type should not be
used to indicate to use bytes methods for blob.
> [Broker-J] Improve handling of unexpected exceptions on establishing LDAP
> connections in SimpleLDAPAuthenticationProvider
> --
>
> Key: QPID-8208
> URL: https://issues.apache.org/jira/browse/QPID-8208
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, 0.32, qpid-java-6.0, qpid-java-6.0.1,
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5,
> qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1,
> qpid-java-broker-7.0.4
>Reporter: Alex Rudyy
>Priority: Critical
>
> There is a weakness in Qpid exception handling when communication with
> external services like LDAP. The Broker should take a more defensive approach
> and handle unexpected exceptions thrown by underlying third-party API in
> addition to exceptions declared in API interfaces. The unexpected exceptions
> thrown by underlying API should not affect the stability of the Broker.
> It was reported that on establishment of connection with LDAP using default
> context factory {{com.sun.jndi.ldap.LdapCtxFactory}} the creation of
> {{InitialDirContext}} can end-up in unexpected exception thrown from
> {{com.sun.jndi.ldap.LdapClient}}. It looks like a defect in
> {{com.sun.jndi.ldap.LdapClient}}, but I could not find any existing open bug
> report raised against JVM with similar behaviour. I think that Broker should
> catch unexpected exception, log it and report authentication failure back to
> the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8208) [Broker-J] Improve handling of unexpected exceptions on establishing LDAP connections in SimpleLDAPAuthenticationProvider
[
https://issues.apache.org/jira/browse/QPID-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533861#comment-16533861
]
ASF GitHub Bot commented on QPID-8208:
--
Github user alex-rufous commented on a diff in the pull request:
https://github.com/apache/qpid-broker-j/pull/9#discussion_r200404852
--- Diff:
broker-core/src/main/java/org/apache/qpid/server/store/BrokerStoreUpgraderAndRecoverer.java
---
@@ -735,6 +735,7 @@ public MutableEntry transform(MutableEntry entry)
addAttributeTransformer("jdbcBytesForBlob",
addContextVar("qpid.jdbcstore.useBytesForBlob")).
addAttributeTransformer("jdbcBlobType",
addContextVar("qpid.jdbcstore.blobType")).
addAttributeTransformer("jdbcVarbinaryType",
addContextVar("qpid.jdbcstore.varBinaryType")).
+addAttributeTransformer("jdbcTimestampType",
addContextVar("qpid.jdbcstore.timestampType")).
--- End diff --
The VirtualHostEntryUpgrader is used to upgrade record for model of version
"1.3" into "2.0". There was no attribute "jdbcTimestampType" in model 1.3. The
line needs to be deleted
> [Broker-J] Improve handling of unexpected exceptions on establishing LDAP
> connections in SimpleLDAPAuthenticationProvider
> --
>
> Key: QPID-8208
> URL: https://issues.apache.org/jira/browse/QPID-8208
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, 0.32, qpid-java-6.0, qpid-java-6.0.1,
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5,
> qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1,
> qpid-java-broker-7.0.4
>Reporter: Alex Rudyy
>Priority: Critical
>
> There is a weakness in Qpid exception handling when communication with
> external services like LDAP. The Broker should take a more defensive approach
> and handle unexpected exceptions thrown by underlying third-party API in
> addition to exceptions declared in API interfaces. The unexpected exceptions
> thrown by underlying API should not affect the stability of the Broker.
> It was reported that on establishment of connection with LDAP using default
> context factory {{com.sun.jndi.ldap.LdapCtxFactory}} the creation of
> {{InitialDirContext}} can end-up in unexpected exception thrown from
> {{com.sun.jndi.ldap.LdapClient}}. It looks like a defect in
> {{com.sun.jndi.ldap.LdapClient}}, but I could not find any existing open bug
> report raised against JVM with similar behaviour. I think that Broker should
> catch unexpected exception, log it and report authentication failure back to
> the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8208) [Broker-J] Improve handling of unexpected exceptions on establishing LDAP connections in SimpleLDAPAuthenticationProvider
[
https://issues.apache.org/jira/browse/QPID-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533859#comment-16533859
]
ASF GitHub Bot commented on QPID-8208:
--
Github user alex-rufous commented on a diff in the pull request:
https://github.com/apache/qpid-broker-j/pull/9#discussion_r200406409
--- Diff:
broker-core/src/test/java/org/apache/qpid/server/store/BrokerStoreUpgraderAndRecovererTest.java
---
@@ -165,6 +167,7 @@ public void
testUpgradeVirtualHostWithJDBCStoreAndDefaultPool()
hostAttributes.put("jdbcBigIntType", "mybigint");
hostAttributes.put("jdbcBlobType", "myblob");
hostAttributes.put("jdbcVarbinaryType", "myvarbinary");
+hostAttributes.put("jdbcTimestampType", "mytimestamp");
--- End diff --
Please undo the change as context variable "qpid.jdbcstore.timestampType"
did not exist in previous model versions
> [Broker-J] Improve handling of unexpected exceptions on establishing LDAP
> connections in SimpleLDAPAuthenticationProvider
> --
>
> Key: QPID-8208
> URL: https://issues.apache.org/jira/browse/QPID-8208
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, 0.32, qpid-java-6.0, qpid-java-6.0.1,
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5,
> qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1,
> qpid-java-broker-7.0.4
>Reporter: Alex Rudyy
>Priority: Critical
>
> There is a weakness in Qpid exception handling when communication with
> external services like LDAP. The Broker should take a more defensive approach
> and handle unexpected exceptions thrown by underlying third-party API in
> addition to exceptions declared in API interfaces. The unexpected exceptions
> thrown by underlying API should not affect the stability of the Broker.
> It was reported that on establishment of connection with LDAP using default
> context factory {{com.sun.jndi.ldap.LdapCtxFactory}} the creation of
> {{InitialDirContext}} can end-up in unexpected exception thrown from
> {{com.sun.jndi.ldap.LdapClient}}. It looks like a defect in
> {{com.sun.jndi.ldap.LdapClient}}, but I could not find any existing open bug
> report raised against JVM with similar behaviour. I think that Broker should
> catch unexpected exception, log it and report authentication failure back to
> the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8208) [Broker-J] Improve handling of unexpected exceptions on establishing LDAP connections in SimpleLDAPAuthenticationProvider
[
https://issues.apache.org/jira/browse/QPID-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533860#comment-16533860
]
ASF GitHub Bot commented on QPID-8208:
--
Github user alex-rufous commented on a diff in the pull request:
https://github.com/apache/qpid-broker-j/pull/9#discussion_r200406444
--- Diff:
broker-core/src/test/java/org/apache/qpid/server/store/BrokerStoreUpgraderAndRecovererTest.java
---
@@ -191,6 +194,7 @@ public void
testUpgradeVirtualHostWithJDBCStoreAndDefaultPool()
context.put("qpid.jdbcstore.bigIntType", "mybigint");
context.put("qpid.jdbcstore.varBinaryType", "myvarbinary");
context.put("qpid.jdbcstore.blobType", "myblob");
+context.put("qpid.jdbcstore.timestampType", "mytimestamp");
--- End diff --
Please undo the change as context variable "qpid.jdbcstore.timestampType"
did not exist in previous model versions
> [Broker-J] Improve handling of unexpected exceptions on establishing LDAP
> connections in SimpleLDAPAuthenticationProvider
> --
>
> Key: QPID-8208
> URL: https://issues.apache.org/jira/browse/QPID-8208
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, 0.32, qpid-java-6.0, qpid-java-6.0.1,
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5,
> qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1,
> qpid-java-broker-7.0.4
>Reporter: Alex Rudyy
>Priority: Critical
>
> There is a weakness in Qpid exception handling when communication with
> external services like LDAP. The Broker should take a more defensive approach
> and handle unexpected exceptions thrown by underlying third-party API in
> addition to exceptions declared in API interfaces. The unexpected exceptions
> thrown by underlying API should not affect the stability of the Broker.
> It was reported that on establishment of connection with LDAP using default
> context factory {{com.sun.jndi.ldap.LdapCtxFactory}} the creation of
> {{InitialDirContext}} can end-up in unexpected exception thrown from
> {{com.sun.jndi.ldap.LdapClient}}. It looks like a defect in
> {{com.sun.jndi.ldap.LdapClient}}, but I could not find any existing open bug
> report raised against JVM with similar behaviour. I think that Broker should
> catch unexpected exception, log it and report authentication failure back to
> the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-broker-j pull request #9: [QPID-8208] Fix Sybase support for the link-s...
Github user alex-rufous commented on a diff in the pull request: https://github.com/apache/qpid-broker-j/pull/9#discussion_r200407725 --- Diff: broker-plugins/jdbc-store/src/main/java/org/apache/qpid/server/store/jdbc/JDBCDetails.java --- @@ -379,7 +403,8 @@ public boolean isOverridden() return contextMap.containsKey(CONTEXT_JDBCSTORE_USEBYTESFORBLOB) || contextMap.containsKey(CONTEXT_JDBCSTORE_BIGINTTYPE) || contextMap.containsKey(CONTEXT_JDBCSTORE_VARBINARYTYPE) -|| contextMap.containsKey(CONTEXT_JDBCSTORE_BLOBTYPE); +|| contextMap.containsKey(CONTEXT_JDBCSTORE_BLOBTYPE) --- End diff -- Please undo the change as context variable for timestamp type should not be used to indicate to use bytes methods for blob. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-broker-j pull request #9: [QPID-8208] Fix Sybase support for the link-s...
Github user alex-rufous commented on a diff in the pull request:
https://github.com/apache/qpid-broker-j/pull/9#discussion_r200406409
--- Diff:
broker-core/src/test/java/org/apache/qpid/server/store/BrokerStoreUpgraderAndRecovererTest.java
---
@@ -165,6 +167,7 @@ public void
testUpgradeVirtualHostWithJDBCStoreAndDefaultPool()
hostAttributes.put("jdbcBigIntType", "mybigint");
hostAttributes.put("jdbcBlobType", "myblob");
hostAttributes.put("jdbcVarbinaryType", "myvarbinary");
+hostAttributes.put("jdbcTimestampType", "mytimestamp");
--- End diff --
Please undo the change as context variable "qpid.jdbcstore.timestampType"
did not exist in previous model versions
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-broker-j pull request #9: [QPID-8208] Fix Sybase support for the link-s...
Github user alex-rufous commented on a diff in the pull request:
https://github.com/apache/qpid-broker-j/pull/9#discussion_r200404852
--- Diff:
broker-core/src/main/java/org/apache/qpid/server/store/BrokerStoreUpgraderAndRecoverer.java
---
@@ -735,6 +735,7 @@ public MutableEntry transform(MutableEntry entry)
addAttributeTransformer("jdbcBytesForBlob",
addContextVar("qpid.jdbcstore.useBytesForBlob")).
addAttributeTransformer("jdbcBlobType",
addContextVar("qpid.jdbcstore.blobType")).
addAttributeTransformer("jdbcVarbinaryType",
addContextVar("qpid.jdbcstore.varBinaryType")).
+addAttributeTransformer("jdbcTimestampType",
addContextVar("qpid.jdbcstore.timestampType")).
--- End diff --
The VirtualHostEntryUpgrader is used to upgrade record for model of version
"1.3" into "2.0". There was no attribute "jdbcTimestampType" in model 1.3. The
line needs to be deleted
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-broker-j pull request #9: [QPID-8208] Fix Sybase support for the link-s...
Github user alex-rufous commented on a diff in the pull request:
https://github.com/apache/qpid-broker-j/pull/9#discussion_r200406444
--- Diff:
broker-core/src/test/java/org/apache/qpid/server/store/BrokerStoreUpgraderAndRecovererTest.java
---
@@ -191,6 +194,7 @@ public void
testUpgradeVirtualHostWithJDBCStoreAndDefaultPool()
context.put("qpid.jdbcstore.bigIntType", "mybigint");
context.put("qpid.jdbcstore.varBinaryType", "myvarbinary");
context.put("qpid.jdbcstore.blobType", "myblob");
+context.put("qpid.jdbcstore.timestampType", "mytimestamp");
--- End diff --
Please undo the change as context variable "qpid.jdbcstore.timestampType"
did not exist in previous model versions
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-broker-j pull request #9: [QPID-8208] Fix Sybase support for the link-s...
Github user alex-rufous commented on a diff in the pull request:
https://github.com/apache/qpid-broker-j/pull/9#discussion_r200406371
--- Diff:
broker-core/src/test/java/org/apache/qpid/server/store/BrokerStoreUpgraderAndRecovererTest.java
---
@@ -131,6 +132,7 @@ public void
testUpgradeVirtualHostWithJDBCStoreAndBoneCPPool()
context.put("qpid.jdbcstore.bigIntType", "mybigint");
context.put("qpid.jdbcstore.varBinaryType", "myvarbinary");
context.put("qpid.jdbcstore.blobType", "myblob");
+context.put("qpid.jdbcstore.timestampType", "mytimestamp");
--- End diff --
Please undo the change as context variable "qpid.jdbcstore.timestampType"
did not exist in previous model versions
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-broker-j pull request #9: [QPID-8208] Fix Sybase support for the link-s...
Github user alex-rufous commented on a diff in the pull request:
https://github.com/apache/qpid-broker-j/pull/9#discussion_r200405733
--- Diff:
broker-core/src/test/java/org/apache/qpid/server/store/BrokerStoreUpgraderAndRecovererTest.java
---
@@ -106,6 +106,7 @@ public void
testUpgradeVirtualHostWithJDBCStoreAndBoneCPPool()
hostAttributes.put("jdbcBigIntType", "mybigint");
hostAttributes.put("jdbcBlobType", "myblob");
hostAttributes.put("jdbcVarbinaryType", "myvarbinary");
+hostAttributes.put("jdbcTimestampType", "mytimestamp");
--- End diff --
Please undo the change as attribute "jdbcTimestampType" never existed in
previous models
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1703) [cpp] Remove auto_settle from receiver options
[ https://issues.apache.org/jira/browse/PROTON-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533855#comment-16533855 ] ASF subversion and git services commented on PROTON-1703: - Commit ea315ff04bd91418aa9755e91370a97cca6bb61f in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=ea315ff ] PROTON-1703: [cpp] deprecated macro for receiver::auto_settle Was deprecated in comment only, added deprecation warning macro. > [cpp] Remove auto_settle from receiver options > -- > > Key: PROTON-1703 > URL: https://issues.apache.org/jira/browse/PROTON-1703 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.19.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > > auto_settle is a sender-only option, the receiver equivalent is auto_accept. > auto_settle is only used at messaging_adapter.cpp#L172, which applies only to > senders, it was included in the option list by mistake. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7153) Allow expired messages to be sent to DLQ
[
https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533852#comment-16533852
]
Rob Godfrey commented on QPID-7153:
---
{noformat}- q -> !((q instanceof AbstractQueue) && ((AbstractQueue)
q).wouldExpire(node.getMessage(;
+ q -> !((q instanceof Queue) && wouldExpireNow((Queue)q, node.getMessage(;
{noformat}
This seems wrong to me - you are passing a Queue object which does not define
the method to AbstractQueue which is a particular implementation. I think the
prior version is more correct.
> Allow expired messages to be sent to DLQ
>
>
> Key: QPID-7153
> URL: https://issues.apache.org/jira/browse/QPID-7153
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments: 0002-QPID-7153-Adress-review-comments.patch,
> QPID-7153v2.diff
>
>
> Currently the Java Broker simply discards messages that expire (TTL). The
> behaviour should be configurable and allow for expired messages to be
> directed to the alternate exchange to allow for dead-lettering.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8212) [JMS AMQP 0-x][AMQP 0-8..0-91] Consumer close can block for 60 seconds and endup in time-out exception
[
https://issues.apache.org/jira/browse/QPID-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533834#comment-16533834
]
ASF subversion and git services commented on QPID-8212:
---
Commit 242099b05b78d2a8c8360df10619d066f509891e in qpid-jms-amqp-0-x's branch
refs/heads/6.3.x from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=242099b ]
QPID-8212: [JMS AMQP 0-x][AMQP 0-8..0-91] Make sure that consumer close does
not delay concurrent connection close
(cherry picked from commit 22a4c4fc28f32e715d3852e303a2ed00e6770c44)
> [JMS AMQP 0-x][AMQP 0-8..0-91] Consumer close can block for 60 seconds and
> endup in time-out exception
> --
>
> Key: QPID-8212
> URL: https://issues.apache.org/jira/browse/QPID-8212
> Project: Qpid
> Issue Type: Bug
> Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.1
>Reporter: Alex Rudyy
>Priority: Blocker
> Fix For: qpid-java-client-0-x-6.3.2
>
>
> When method {{MessageConsumer#close()}} is invoked in one thread and method
> {{Connection#close()}} is invoked in another thread, the incoming
> {{BasicCancelOk}} frame can be ignored due to {{Connection#_closed}} flag
> being set. As result, the call to {{MessageConsumer#close()}} can block for
> 60 seconds and end up in exception due to not being able to receive
> {{BasicCancelOk}}. Invocation of {{Connection#close()}} also gets blocked
> due to message delivery lock being hold on consumer close.
> The defect was introduced as part of changes made against QPID-8185 in commit
> [f89f6c2f45d11fc63551d0d61c17eceedd6bd247|https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=f89f6c2]
> Method {{AMQProtocolSession#isClosedForInput}} checks whether session is
> closed for input by calling {{AMQSession#isClosed()}}. The latter returns
> true when either {{AMQSession#_closed}} or {{AMQConnection#_closed}} holds
> {{true}}. Only {{AMQSession#_closed}} should be checked in
> {{AMQProtocolSession#isClosedForInput}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7153) Allow expired messages to be sent to DLQ
[
https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533826#comment-16533826
]
Alex Rudyy commented on QPID-7153:
--
Attached a patch addressing review comments from Keith Wall and refactoring
{{calculationExpiration}} to get rid from extra argument for a Consumer function
> Allow expired messages to be sent to DLQ
>
>
> Key: QPID-7153
> URL: https://issues.apache.org/jira/browse/QPID-7153
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments: 0002-QPID-7153-Adress-review-comments.patch,
> QPID-7153v2.diff
>
>
> Currently the Java Broker simply discards messages that expire (TTL). The
> behaviour should be configurable and allow for expired messages to be
> directed to the alternate exchange to allow for dead-lettering.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7153) Allow expired messages to be sent to DLQ
[ https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7153: - Attachment: 0002-QPID-7153-Adress-review-comments.patch > Allow expired messages to be sent to DLQ > > > Key: QPID-7153 > URL: https://issues.apache.org/jira/browse/QPID-7153 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: 0002-QPID-7153-Adress-review-comments.patch, > QPID-7153v2.diff > > > Currently the Java Broker simply discards messages that expire (TTL). The > behaviour should be configurable and allow for expired messages to be > directed to the alternate exchange to allow for dead-lettering. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8217) [Broker-J] Evaluation of maximum message size can result in unexpected value
[
https://issues.apache.org/jira/browse/QPID-8217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-8217.
--
Resolution: Invalid
The JIRA is invalid as a {{VirtualHost}} is set as a context provider for
messaging AMQP connection. Using a minimum value looks like a valid approach to
me
> [Broker-J] Evaluation of maximum message size can result in unexpected value
>
>
> Key: QPID-8217
> URL: https://issues.apache.org/jira/browse/QPID-8217
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
>
> The maximum message size is evaluated as a minimum among context variable
> values for maximum message size on {{Port}} and {{Broker}} . Thus, when
> {{Broker}} maximum message size have value of {{10K}} and Port maximum
> message size have value of {{100M}}, the maximum message size would be
> {{10K}}. According to the rules for evaluation of context variables the
> {{Port}} context variable value should override the {{Broker}} one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Issue Comment Deleted] (QPID-8217) [Broker-J] Evaluation of maximum message size can result in unexpected value
[
https://issues.apache.org/jira/browse/QPID-8217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8217:
-
Comment: was deleted
(was: QPID-6962 added ability to impose max message size on a per virtual host
basis. This ability was lost as as part of refactoring made in
[https://svn.apache.org/r1745091] against QPID-7000. It seems it make sense to
restore this ability)
> [Broker-J] Evaluation of maximum message size can result in unexpected value
>
>
> Key: QPID-8217
> URL: https://issues.apache.org/jira/browse/QPID-8217
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
>
> The maximum message size is evaluated as a minimum among context variable
> values for maximum message size on {{Port}} and {{Broker}} . Thus, when
> {{Broker}} maximum message size have value of {{10K}} and Port maximum
> message size have value of {{100M}}, the maximum message size would be
> {{10K}}. According to the rules for evaluation of context variables the
> {{Port}} context variable value should override the {{Broker}} one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8217) [Broker-J] Evaluation of maximum message size can result in unexpected value
[
https://issues.apache.org/jira/browse/QPID-8217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533709#comment-16533709
]
Alex Rudyy commented on QPID-8217:
--
QPID-6962 added ability to impose max message size on a per virtual host basis.
This ability was lost as as part of refactoring made in
[https://svn.apache.org/r1745091] against QPID-7000. It seems it make sense to
restore this ability
> [Broker-J] Evaluation of maximum message size can result in unexpected value
>
>
> Key: QPID-8217
> URL: https://issues.apache.org/jira/browse/QPID-8217
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
>
> The maximum message size is evaluated as a minimum among context variable
> values for maximum message size on {{Port}} and {{Broker}} . Thus, when
> {{Broker}} maximum message size have value of {{10K}} and Port maximum
> message size have value of {{100M}}, the maximum message size would be
> {{10K}}. According to the rules for evaluation of context variables the
> {{Port}} context variable value should override the {{Broker}} one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8217) [Broker-J] Evaluation of maximum message size can result in unexpected value
[
https://issues.apache.org/jira/browse/QPID-8217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8217:
-
Description: The maximum message size is evaluated as a minimum among
context variable values for maximum message size on {{Port}} and {{Broker}} .
Thus, when {{Broker}} maximum message size have value of {{10K}} and Port
maximum message size have value of {{100M}}, the maximum message size would be
{{10K}}. According to the rules for evaluation of context variables the
{{Port}} context variable value should override the {{Broker}} one. (was: The
maximum message size is evaluated as a minimum among context variable values
for maximum message size on {{Port}} and {{Broker}} . Thus, when {{Broker}}
maximum message size have value of {{-1}} and Port maximum message size have
value of {{100M}}, the maximum message size would be {{-1}} which corresponds
to message size being unlimited. According to the rules for evaluation of
context variables the {{Port}} context variable value should override the
{{Broker}} one.)
> [Broker-J] Evaluation of maximum message size can result in unexpected value
>
>
> Key: QPID-8217
> URL: https://issues.apache.org/jira/browse/QPID-8217
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
>
> The maximum message size is evaluated as a minimum among context variable
> values for maximum message size on {{Port}} and {{Broker}} . Thus, when
> {{Broker}} maximum message size have value of {{10K}} and Port maximum
> message size have value of {{100M}}, the maximum message size would be
> {{10K}}. According to the rules for evaluation of context variables the
> {{Port}} context variable value should override the {{Broker}} one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8217) [Broker-J] Evaluation of maximum message size can result in unexpected value
[
https://issues.apache.org/jira/browse/QPID-8217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8217:
-
Description: The maximum message size is evaluated as a minimum among
context variable values for maximum message size on {{Port}} and {{Broker}} .
Thus, when {{Broker}} maximum message size have value of {{-1}} and Port
maximum message size have value of {{100M}}, the maximum message size would be
{{-1}} which corresponds to message size being unlimited. According to the
rules for evaluation of context variables the {{Port}} context variable value
should override the {{Broker}} one. (was: The maximum message size is
evaluated as a minimum among context variable values for maximum message size
on {{Port}} and {{Broker}} . Thus, when {{Broker}} maximum message size have
value of {{0}} and Port maximum message size have value of {{100M}}, the
maximum message size would be {{0}} which corresponds to message size being
unlimited. According to the rules for evaluation of context variables the
{{Port}} context variable value should override the {{Broker}} one.)
> [Broker-J] Evaluation of maximum message size can result in unexpected value
>
>
> Key: QPID-8217
> URL: https://issues.apache.org/jira/browse/QPID-8217
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
>
> The maximum message size is evaluated as a minimum among context variable
> values for maximum message size on {{Port}} and {{Broker}} . Thus, when
> {{Broker}} maximum message size have value of {{-1}} and Port maximum message
> size have value of {{100M}}, the maximum message size would be {{-1}} which
> corresponds to message size being unlimited. According to the rules for
> evaluation of context variables the {{Port}} context variable value should
> override the {{Broker}} one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8217) [Broker-J] Evaluation of maximum message size can result in unexpected value
[
https://issues.apache.org/jira/browse/QPID-8217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8217:
-
Priority: Trivial (was: Major)
> [Broker-J] Evaluation of maximum message size can result in unexpected value
>
>
> Key: QPID-8217
> URL: https://issues.apache.org/jira/browse/QPID-8217
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
>
> The maximum message size is evaluated as a minimum among context variable
> values for maximum message size on {{Port}} and {{Broker}} . Thus, when
> {{Broker}} maximum message size have value of {{0}} and Port maximum message
> size have value of {{100M}}, the maximum message size would be {{0}} which
> corresponds to message size being unlimited. According to the rules for
> evaluation of context variables the {{Port}} context variable value should
> override the {{Broker}} one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1703) [cpp] Remove auto_settle from receiver options
[ https://issues.apache.org/jira/browse/PROTON-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533687#comment-16533687 ] Robbie Gemmell commented on PROTON-1703: I'd say there should be JIRAs (like this one) for any such outstanding change needing made, and they could all be linked to another JIRA used to actually perform the major version change. > [cpp] Remove auto_settle from receiver options > -- > > Key: PROTON-1703 > URL: https://issues.apache.org/jira/browse/PROTON-1703 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.19.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > > auto_settle is a sender-only option, the receiver equivalent is auto_accept. > auto_settle is only used at messaging_adapter.cpp#L172, which applies only to > senders, it was included in the option list by mistake. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8217) [Broker-J] Evaluation of maximum message size can result in unexpected value
[
https://issues.apache.org/jira/browse/QPID-8217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy reassigned QPID-8217:
Assignee: Alex Rudyy
> [Broker-J] Evaluation of maximum message size can result in unexpected value
>
>
> Key: QPID-8217
> URL: https://issues.apache.org/jira/browse/QPID-8217
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
>
> The maximum message size is evaluated as a minimum among context variable
> values for maximum message size on {{Port}} and {{Broker}} . Thus, when
> {{Broker}} maximum message size have value of {{0}} and Port maximum message
> size have value of {{100M}}, the maximum message size would be {{0}} which
> corresponds to message size being unlimited. According to the rules for
> evaluation of context variables the {{Port}} context variable value should
> override the {{Broker}} one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8216) [Broker-J] Operational log message CHN-1011 about moving message to dead letter queue is not reported
[
https://issues.apache.org/jira/browse/QPID-8216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533684#comment-16533684
]
ASF subversion and git services commented on QPID-8216:
---
Commit b3ca3855e70fc499634b0de4ccc4424214120776 in qpid-broker-j's branch
refs/heads/7.0.x from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=b3ca385 ]
QPID-8216: [Broker-J] Restore reporting of pperational log message CHN-1011
about moving message to dead letter queue
(cherry picked from commit 38d5844e5df591e8a2850f6e302763a764cc50c8)
> [Broker-J] Operational log message CHN-1011 about moving message to dead
> letter queue is not reported
> -
>
> Key: QPID-8216
> URL: https://issues.apache.org/jira/browse/QPID-8216
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
>
> Operational log message CHN-1011 about moving message to dead letter queue is
> not reported any more. The changes committed in [
> https://svn.apache.org/r1776037 ] against QPID-6028 removed reporting of
> operational log message CHN-1011:
> {noformat}
> CHN-1011 : Message : moved to dead letter queue : name>
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8217) [Broker-J] Evaluation of maximum message size can result in unexpected value
Alex Rudyy created QPID-8217:
Summary: [Broker-J] Evaluation of maximum message size can result
in unexpected value
Key: QPID-8217
URL: https://issues.apache.org/jira/browse/QPID-8217
Project: Qpid
Issue Type: Bug
Components: Broker-J
Affects Versions: qpid-java-broker-7.0.6, qpid-java-broker-7.0.5,
qpid-java-broker-7.0.4, qpid-java-broker-7.0.1, qpid-java-broker-7.0.0,
qpid-java-broker-7.0.2, qpid-java-broker-7.0.3
Reporter: Alex Rudyy
Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
The maximum message size is evaluated as a minimum among context variable
values for maximum message size on {{Port}} and {{Broker}} . Thus, when
{{Broker}} maximum message size have value of {{0}} and Port maximum message
size have value of {{100M}}, the maximum message size would be {{0}} which
corresponds to message size being unlimited. According to the rules for
evaluation of context variables the {{Port}} context variable value should
override the {{Broker}} one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8216) [Broker-J] Operational log message CHN-1011 about moving message to dead letter queue is not reported
[
https://issues.apache.org/jira/browse/QPID-8216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8216:
-
Status: Reviewable (was: In Progress)
> [Broker-J] Operational log message CHN-1011 about moving message to dead
> letter queue is not reported
> -
>
> Key: QPID-8216
> URL: https://issues.apache.org/jira/browse/QPID-8216
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
>
> Operational log message CHN-1011 about moving message to dead letter queue is
> not reported any more. The changes committed in [
> https://svn.apache.org/r1776037 ] against QPID-6028 removed reporting of
> operational log message CHN-1011:
> {noformat}
> CHN-1011 : Message : moved to dead letter queue : name>
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8216) [Broker-J] Operational log message CHN-1011 about moving message to dead letter queue is not reported
[
https://issues.apache.org/jira/browse/QPID-8216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533630#comment-16533630
]
ASF subversion and git services commented on QPID-8216:
---
Commit 38d5844e5df591e8a2850f6e302763a764cc50c8 in qpid-broker-j's branch
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=38d5844 ]
QPID-8216: [Broker-J] Restore reporting of pperational log message CHN-1011
about moving message to dead letter queue
> [Broker-J] Operational log message CHN-1011 about moving message to dead
> letter queue is not reported
> -
>
> Key: QPID-8216
> URL: https://issues.apache.org/jira/browse/QPID-8216
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
>
> Operational log message CHN-1011 about moving message to dead letter queue is
> not reported any more. The changes committed in [
> https://svn.apache.org/r1776037 ] against QPID-6028 removed reporting of
> operational log message CHN-1011:
> {noformat}
> CHN-1011 : Message : moved to dead letter queue : name>
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8214) Reduce the table names size in the JDBC configuration store to fit Oracle's 30 characters limitation
[ https://issues.apache.org/jira/browse/QPID-8214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533629#comment-16533629 ] ASF subversion and git services commented on QPID-8214: --- Commit fbeb2084635c5b15bfeed25674513e2783457ccf in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=fbeb208 ] QPID-8214: [Broker-J][JDBC] Reduce the sizes of table names in the JDBC configuration store > Reduce the table names size in the JDBC configuration store to fit Oracle's > 30 characters limitation > > > Key: QPID-8214 > URL: https://issues.apache.org/jira/browse/QPID-8214 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.4 >Reporter: Olivier VERMEULEN >Assignee: Alex Rudyy >Priority: Major > Attachments: > 0001-QPID-8214-Broker-J-JDBC-Reduce-the-sizes-of-table-na.patch > > > 'QPID_CONFIGURED_OBJECT_HIERARCHY' is already 32 characters long. > And we should also take into account that users can specify a table name > prefix. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8216) [Broker-J] Operational log message CHN-1011 about moving message to dead letter queue is not reported
[
https://issues.apache.org/jira/browse/QPID-8216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy reassigned QPID-8216:
Assignee: Alex Rudyy
> [Broker-J] Operational log message CHN-1011 about moving message to dead
> letter queue is not reported
> -
>
> Key: QPID-8216
> URL: https://issues.apache.org/jira/browse/QPID-8216
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
>
> Operational log message CHN-1011 about moving message to dead letter queue is
> not reported any more. The changes committed in [
> https://svn.apache.org/r1776037 ] against QPID-6028 removed reporting of
> operational log message CHN-1011:
> {noformat}
> CHN-1011 : Message : moved to dead letter queue : name>
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1703) [cpp] Remove auto_settle from receiver options
[ https://issues.apache.org/jira/browse/PROTON-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533607#comment-16533607 ] Justin Ross commented on PROTON-1703: - [~aconway], I think we should review everything that's deprecated when we make a major-version jump. That said, it wouldn't hurt to have some in-source marker for a PLANNED-ABI-BREAK or something similar that we could search for. Alan, side note, this one seems like a good candidate to use the deprecation macro (the one with the warning), since no one should be using it. > [cpp] Remove auto_settle from receiver options > -- > > Key: PROTON-1703 > URL: https://issues.apache.org/jira/browse/PROTON-1703 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.19.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > > auto_settle is a sender-only option, the receiver equivalent is auto_accept. > auto_settle is only used at messaging_adapter.cpp#L172, which applies only to > senders, it was included in the option list by mistake. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1867) Debug libs missing in Windows build
[ https://issues.apache.org/jira/browse/PROTON-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533574#comment-16533574 ] ASF subversion and git services commented on PROTON-1867: - Commit e6a3e5c8a8c9e53c5324a3c641a266792eb57b22 in qpid-proton's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=e6a3e5c ] PROTON-1867: Position the debug postfix setting before calls to add_library > Debug libs missing in Windows build > --- > > Key: PROTON-1867 > URL: https://issues.apache.org/jira/browse/PROTON-1867 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Major > Fix For: proton-c-0.24.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8216) [Broker-J] Operational log message CHN-1011 about moving message to dead letter queue is not reported
Alex Rudyy created QPID-8216:
Summary: [Broker-J] Operational log message CHN-1011 about moving
message to dead letter queue is not reported
Key: QPID-8216
URL: https://issues.apache.org/jira/browse/QPID-8216
Project: Qpid
Issue Type: Bug
Components: Broker-J
Affects Versions: qpid-java-broker-7.0.6, qpid-java-broker-7.0.5,
qpid-java-broker-7.0.4, qpid-java-broker-7.0.1, qpid-java-broker-7.0.0,
qpid-java-broker-7.0.2, qpid-java-broker-7.0.3
Reporter: Alex Rudyy
Fix For: qpid-java-broker-7.0.7, qpid-java-broker-7.1.0
Operational log message CHN-1011 about moving message to dead letter queue is
not reported any more. The changes committed in [
https://svn.apache.org/r1776037 ] against QPID-6028 removed reporting of
operational log message CHN-1011:
{noformat}
CHN-1011 : Message : moved to dead letter queue :
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7153) Allow expired messages to be sent to DLQ
[ https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533464#comment-16533464 ] Alex Rudyy commented on QPID-7153: -- A link to the conversation about routing expired message to alternate binding [https://lists.apache.org/thread.html/f9d3eb16dfd4eda8bcd6195c1eb89e3ce8479233d507b73e5e8e8230@%3Cusers.qpid.apache.org%3E] > Allow expired messages to be sent to DLQ > > > Key: QPID-7153 > URL: https://issues.apache.org/jira/browse/QPID-7153 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: QPID-7153v2.diff > > > Currently the Java Broker simply discards messages that expire (TTL). The > behaviour should be configurable and allow for expired messages to be > directed to the alternate exchange to allow for dead-lettering. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
