[jira] [Updated] (QPID-8316) [Broker-J][AMQP 0-8..0-91] The meta data of flowed to disk messages continue to occupy heap memory

2019-05-22 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8316:
-
Description: 
A regression in heap memory utilization was introduced in message validation 
functionality implemented as part of IBAMQ-8318. The message metadata is loaded 
into heap for message validation and continue to remain in heap until message 
is consumed. The flow to disk functionality does not clean metadata objects as 
message is not considered as being resided in memory.

The issue can be mitigated by increasing heap size.

  was:A regression in heap memory utilization was introduced in message 
validation functionality implemented as part of IBAMQ-8318. The message 
metadata is loaded into heap for message validation and continue to remain in 
heap until message is consumed. The flow to disk functionality does not clean 
metadata objects as message is not considered as being resided in memory.


> [Broker-J][AMQP 0-8..0-91] The meta data of flowed to disk messages continue 
> to occupy heap memory
> --
>
> Key: QPID-8316
> URL: https://issues.apache.org/jira/browse/QPID-8316
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.7, qpid-java-broker-7.1.1, 
> qpid-java-broker-7.1.2, qpid-java-broker-7.1.3
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.8, qpid-java-broker-7.1.4
>
>
> A regression in heap memory utilization was introduced in message validation 
> functionality implemented as part of IBAMQ-8318. The message metadata is 
> loaded into heap for message validation and continue to remain in heap until 
> message is consumed. The flow to disk functionality does not clean metadata 
> objects as message is not considered as being resided in memory.
> The issue can be mitigated by increasing heap size.



--
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-8316) [Broker-J][AMQP 0-8..0-91] The meta data of flowed to disk messages continue to occupy heap memory

2019-05-22 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8316:
-
Priority: Critical  (was: Major)

> [Broker-J][AMQP 0-8..0-91] The meta data of flowed to disk messages continue 
> to occupy heap memory
> --
>
> Key: QPID-8316
> URL: https://issues.apache.org/jira/browse/QPID-8316
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.7, qpid-java-broker-7.1.1, 
> qpid-java-broker-7.1.2, qpid-java-broker-7.1.3
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.8, qpid-java-broker-7.1.4
>
>
> A regression in heap memory utilization was introduced in message validation 
> functionality implemented as part of IBAMQ-8318. The message metadata is 
> loaded into heap for message validation and continue to remain in heap until 
> message is consumed. The flow to disk functionality does not clean metadata 
> objects as message is not considered as being resided in memory.



--
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-8316) [Broker-J][AMQP 0-8..0-91] The meta data of flowed to disk messages continue to occupy heap memory

2019-05-22 Thread Alex Rudyy (JIRA)
Alex Rudyy created QPID-8316:


 Summary: [Broker-J][AMQP 0-8..0-91] The meta data of flowed to 
disk messages continue to occupy heap memory
 Key: QPID-8316
 URL: https://issues.apache.org/jira/browse/QPID-8316
 Project: Qpid
  Issue Type: Bug
  Components: Broker-J
Affects Versions: qpid-java-broker-7.1.3, qpid-java-broker-7.1.2, 
qpid-java-broker-7.1.1, qpid-java-broker-7.0.7
Reporter: Alex Rudyy
 Fix For: qpid-java-broker-7.0.8, qpid-java-broker-7.1.4


A regression in heap memory utilization was introduced in message validation 
functionality implemented as part of IBAMQ-8318. The message metadata is loaded 
into heap for message validation and continue to remain in heap until message 
is consumed. The flow to disk functionality does not clean metadata objects as 
message is not considered as being resided in memory.



--
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] [Closed] (QPID-8296) [JMS AMQP 0-x] Release 6.3.4 version of Qpid JMS client for AMQP 0-x

2019-05-20 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy closed QPID-8296.

Resolution: Done

> [JMS AMQP 0-x] Release 6.3.4 version of Qpid JMS client for AMQP 0-x
> 
>
> Key: QPID-8296
> URL: https://issues.apache.org/jira/browse/QPID-8296
> Project: Qpid
>  Issue Type: Task
>  Components: JMS AMQP 0-x
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.4
>
>
> Release Qpid JMS AMQP 0-x client following instructions 
> [here|https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+JMS+AMQP+0-x]



--
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-8255) [JMS AMQP 0-x] Connection failure with connection option 'client_cert_priv_key_path' and java 11

2019-05-20 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-8255.
--
Resolution: Fixed

> [JMS AMQP 0-x] Connection failure  with connection option 
> 'client_cert_priv_key_path' and java 11
> -
>
> Key: QPID-8255
> URL: https://issues.apache.org/jira/browse/QPID-8255
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.3
> Environment: java11
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.4, qpid-java-client-0-x-6.4.0
>
>
> Connection establishment fails with java 11 when connection option 
> 'client_cert_priv_key_path' is used:
> {noformat}
> javax.jms.JMSException: Error creating connection: Key protection  algorithm 
> not found: java.security.UnrecoverableKeyException: Encrypt Private Key 
> failed: getSecretKey failed: Password is not ASCII
>     at 
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:169)
>     at 
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:143)
>     at 
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:57)
>     at 
> org.apache.qpid.systests.QpidJmsClient0xConnectionBuilder.build(QpidJmsClient0xConnectionBuilder.java:270)
>     at 
> org.apache.qpid.systests.jms_1_1.extensions.tls.TlsTest.testCreateSSLWithCertFileAndPrivateKey(TlsTest.java:508)
>     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>     at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>     at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>     at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>     at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at 
> org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:84)
>     at 
> org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:28)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>     at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.apache.qpid.tests.utils.QpidTestRunner.run(QpidTestRunner.java:59)
>     at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
>     at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>     at 
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
>     at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
>     at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: org.apache.qpid.AMQConnectionFailureException: Key protection  
> algorithm not found: java.security.UnrecoverableKeyException: Encrypt Private 
> Key failed: getSecretKey failed: Password is not ASCII
>     at 
> org.apache.qpid.client.AMQConnection.makeConnection(AMQConnection.java:672)
>     at org.apache.qpid.client.AMQConnection.(AMQConnection.java:522)
>     at 
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:164)
>     ... 32 more
> Caused by: org.apache.qpid.transport.TransportException: Error creating SSL 
> Context
>     at 
> org.apache.qpid.transport.network.security.SecurityLayerFactory$SSLSecurityLayer.(SecurityLayerFactory.java:100)
>     at 
> org.apache.qpid.transport.network.security.SecurityLayerFactory.newInstance(SecurityLayerFactory.java:59)
>     at 
> 

[jira] [Resolved] (QPID-8283) [JMS AMQP 0-x] Connection option 'encryption_trust_store_password' is mistakenly used to set encryption keystore password rather than encryption trust store password as i

2019-05-20 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-8283.
--
Resolution: Fixed

> [JMS AMQP 0-x] Connection option 'encryption_trust_store_password' is 
> mistakenly used to set encryption keystore password rather than encryption 
> trust store password as intendant 
> ---
>
> Key: QPID-8283
> URL: https://issues.apache.org/jira/browse/QPID-8283
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-6.1.6, 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-client-0-x-6.3.0, qpid-java-6.1.5, qpid-java-client-0-x-6.3.1, 
> qpid-java-6.1.7, qpid-java-client-0-x-6.3.2, qpid-java-client-0-x-6.3.3
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.4
>
>
> Connection option {{encryption_trust_store_password}} is mistakenly used to 
> set encryption keystore password rather than encryption trust store password 
> as intendant.
> Here is problematic code in {{BrokerDetails}}:
> {code}
> if 
> (getProperty(BrokerDetails.OPTIONS_ENCRYPTION_TRUST_STORE_PASSWORD) != null)
> {
> conSettings.setEncryptionKeyStorePassword(
> 
> getProperty(BrokerDetails.OPTIONS_ENCRYPTION_TRUST_STORE_PASSWORD));
> }
> {code}
> Method {{conSettings.setEncryptionTrustStorePassword}} should be invoked 
> instead. 
> The workaround for this issue is to set trust store password using JVM 
> property {{javax.net.ssl.trustStorePassword}}.



--
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-8285) [JMS AMQP 0-x] Deadlock during receiveMessage when broker connecton fails

2019-05-20 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-8285.
--
Resolution: Fixed

> [JMS AMQP 0-x] Deadlock during receiveMessage when broker connecton fails
> -
>
> Key: QPID-8285
> URL: https://issues.apache.org/jira/browse/QPID-8285
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
> Environment: * Java 1.8.0_20, 1.8.0_192, & 1.8.0_172
>  * Linux 4.9.0-4-amd64 & 3.10.0-327.13
>  * qpidd 1.39.0
>Reporter: Jonathan Beales
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.4
>
> Attachments: qpid_jms_deaklock.patch
>
>
> When a JMS MessageConsumer calls receiveMessage with a timeout, if no message 
> is received during the timeout, 
> BasicMessageConsumer_0_10.getMessageFromQueue() calls the syncDispatchQueue() 
> method.  As not the dispatcher thread, the consumer waits on a method local 
> CountDownLatch which should be decremented when the AMQSession.Dispatcher 
> thread calls dispatch().
> In the AMQSession.Dispatcher thread, the core loop will stop pulling from the 
> queue to dispatch messages when the connection to the broker is lost 
> (isClosing() becomes true).
> In this scenario, the receiveMessage call is waiting forever because the 
> Dispatcher will never call dispatch.  This also leaves the Dispatcher thread 
> in an infinite loop (using 100% CPU) waiting to be fully closed.
> This can fixed by allowing the AMQSession.Dispatcher to always dispatch 
> remaining queue content to ensure a consumer is not waiting forever (see 
> attached).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Resolved] (QPID-8282) [JMS AMQP 0-x] Java 11 build/runtime failure due to use of javax.xml.bind.DatatypeConverter

2019-05-20 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-8282.
--
Resolution: Fixed

> [JMS AMQP 0-x] Java 11 build/runtime failure due to use of 
> javax.xml.bind.DatatypeConverter
> ---
>
> Key: QPID-8282
> URL: https://issues.apache.org/jira/browse/QPID-8282
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.3
>Reporter: Robbie Gemmell
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.4, qpid-java-client-0-x-6.4.0
>
>
> In setting up a new system, I happened to make attempt to build the JMS AMQP 
> 0-x client using Java 11. It failed to compile due to use of 
> javax.xml.bind.DatatypeConverter for Base64 handling in the SCRAM-SHA 
> mechanisms. This prevents building on Java 11, and would break use of 
> SCRAM-SHA while running on Java 11 assuming nothing else stopped things 
> working.
> Although the 0-x client is essentially in maintenance/legacy mode at this 
> point, blockers as trivial as Base 64 handling would be nice to resolved if 
> it made using Java 11 possible, if only to simplify migrations later.



--
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-8314) [Broker-J][WMC] Allow selection of all messages displayed in the message table on queue tab

2019-05-17 Thread Alex Rudyy (JIRA)
Alex Rudyy created QPID-8314:


 Summary: [Broker-J][WMC] Allow selection of all messages displayed 
in the message table on queue tab
 Key: QPID-8314
 URL: https://issues.apache.org/jira/browse/QPID-8314
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J
Reporter: Alex Rudyy
 Fix For: qpid-java-broker-7.1.4, qpid-java-broker-8.0.0


The current message selection functionality only allows to select individual 
messages one by one. A bulk selection can be added to check all messages 
displayed on the current page of the message table



--
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-8296) [JMS AMQP 0-x] Release 6.3.4 version of Qpid JMS client for AMQP 0-x

2019-05-14 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8296:


Assignee: Alex Rudyy

> [JMS AMQP 0-x] Release 6.3.4 version of Qpid JMS client for AMQP 0-x
> 
>
> Key: QPID-8296
> URL: https://issues.apache.org/jira/browse/QPID-8296
> Project: Qpid
>  Issue Type: Task
>  Components: JMS AMQP 0-x
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.4
>
>
> Release Qpid JMS AMQP 0-x client following instructions 
> [here|https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+JMS+AMQP+0-x]



--
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-8312) [Broker-J] Release Qpid Broker-J version 7.1.3

2019-05-14 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8312:
-
Status: Reviewable  (was: In Progress)

> [Broker-J] Release Qpid Broker-J version 7.1.3
> --
>
> Key: QPID-8312
> URL: https://issues.apache.org/jira/browse/QPID-8312
> Project: Qpid
>  Issue Type: Task
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.3
>
>
> Release Qpid Broker-J version 7.1.3 as per instructions at
> [https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J]



--
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-8285) [JMS AMQP 0-x] Deadlock during receiveMessage when broker connecton fails

2019-05-13 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8285:
-
Summary: [JMS AMQP 0-x] Deadlock during receiveMessage when broker 
connecton fails  (was: Deadlock during receiveMessage when broker connecton 
fails)

> [JMS AMQP 0-x] Deadlock during receiveMessage when broker connecton fails
> -
>
> Key: QPID-8285
> URL: https://issues.apache.org/jira/browse/QPID-8285
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
> Environment: * Java 1.8.0_20, 1.8.0_192, & 1.8.0_172
>  * Linux 4.9.0-4-amd64 & 3.10.0-327.13
>  * qpidd 1.39.0
>Reporter: Jonathan Beales
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.4
>
> Attachments: qpid_jms_deaklock.patch
>
>
> When a JMS MessageConsumer calls receiveMessage with a timeout, if no message 
> is received during the timeout, 
> BasicMessageConsumer_0_10.getMessageFromQueue() calls the syncDispatchQueue() 
> method.  As not the dispatcher thread, the consumer waits on a method local 
> CountDownLatch which should be decremented when the AMQSession.Dispatcher 
> thread calls dispatch().
> In the AMQSession.Dispatcher thread, the core loop will stop pulling from the 
> queue to dispatch messages when the connection to the broker is lost 
> (isClosing() becomes true).
> In this scenario, the receiveMessage call is waiting forever because the 
> Dispatcher will never call dispatch.  This also leaves the Dispatcher thread 
> in an infinite loop (using 100% CPU) waiting to be fully closed.
> This can fixed by allowing the AMQSession.Dispatcher to always dispatch 
> remaining queue content to ensure a consumer is not waiting forever (see 
> attached).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (QPID-8285) Deadlock during receiveMessage when broker connecton fails

2019-05-13 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8285:
-
Status: Reviewable  (was: In Progress)

> Deadlock during receiveMessage when broker connecton fails
> --
>
> Key: QPID-8285
> URL: https://issues.apache.org/jira/browse/QPID-8285
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
> Environment: * Java 1.8.0_20, 1.8.0_192, & 1.8.0_172
>  * Linux 4.9.0-4-amd64 & 3.10.0-327.13
>  * qpidd 1.39.0
>Reporter: Jonathan Beales
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.4
>
> Attachments: qpid_jms_deaklock.patch
>
>
> When a JMS MessageConsumer calls receiveMessage with a timeout, if no message 
> is received during the timeout, 
> BasicMessageConsumer_0_10.getMessageFromQueue() calls the syncDispatchQueue() 
> method.  As not the dispatcher thread, the consumer waits on a method local 
> CountDownLatch which should be decremented when the AMQSession.Dispatcher 
> thread calls dispatch().
> In the AMQSession.Dispatcher thread, the core loop will stop pulling from the 
> queue to dispatch messages when the connection to the broker is lost 
> (isClosing() becomes true).
> In this scenario, the receiveMessage call is waiting forever because the 
> Dispatcher will never call dispatch.  This also leaves the Dispatcher thread 
> in an infinite loop (using 100% CPU) waiting to be fully closed.
> This can fixed by allowing the AMQSession.Dispatcher to always dispatch 
> remaining queue content to ensure a consumer is not waiting forever (see 
> attached).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Assigned] (QPID-8285) Deadlock during receiveMessage when broker connecton fails

2019-05-13 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8285:


Assignee: Alex Rudyy

> Deadlock during receiveMessage when broker connecton fails
> --
>
> Key: QPID-8285
> URL: https://issues.apache.org/jira/browse/QPID-8285
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
> Environment: * Java 1.8.0_20, 1.8.0_192, & 1.8.0_172
>  * Linux 4.9.0-4-amd64 & 3.10.0-327.13
>  * qpidd 1.39.0
>Reporter: Jonathan Beales
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.4
>
> Attachments: qpid_jms_deaklock.patch
>
>
> When a JMS MessageConsumer calls receiveMessage with a timeout, if no message 
> is received during the timeout, 
> BasicMessageConsumer_0_10.getMessageFromQueue() calls the syncDispatchQueue() 
> method.  As not the dispatcher thread, the consumer waits on a method local 
> CountDownLatch which should be decremented when the AMQSession.Dispatcher 
> thread calls dispatch().
> In the AMQSession.Dispatcher thread, the core loop will stop pulling from the 
> queue to dispatch messages when the connection to the broker is lost 
> (isClosing() becomes true).
> In this scenario, the receiveMessage call is waiting forever because the 
> Dispatcher will never call dispatch.  This also leaves the Dispatcher thread 
> in an infinite loop (using 100% CPU) waiting to be fully closed.
> This can fixed by allowing the AMQSession.Dispatcher to always dispatch 
> remaining queue content to ensure a consumer is not waiting forever (see 
> attached).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (QPID-8283) [JMS AMQP 0-x] Connection option 'encryption_trust_store_password' is mistakenly used to set encryption keystore password rather than encryption trust store password as in

2019-05-10 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8283:
-
Status: Reviewable  (was: In Progress)

> [JMS AMQP 0-x] Connection option 'encryption_trust_store_password' is 
> mistakenly used to set encryption keystore password rather than encryption 
> trust store password as intendant 
> ---
>
> Key: QPID-8283
> URL: https://issues.apache.org/jira/browse/QPID-8283
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-6.1.6, 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-client-0-x-6.3.0, qpid-java-6.1.5, qpid-java-client-0-x-6.3.1, 
> qpid-java-6.1.7, qpid-java-client-0-x-6.3.2, qpid-java-client-0-x-6.3.3
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.4
>
>
> Connection option {{encryption_trust_store_password}} is mistakenly used to 
> set encryption keystore password rather than encryption trust store password 
> as intendant.
> Here is problematic code in {{BrokerDetails}}:
> {code}
> if 
> (getProperty(BrokerDetails.OPTIONS_ENCRYPTION_TRUST_STORE_PASSWORD) != null)
> {
> conSettings.setEncryptionKeyStorePassword(
> 
> getProperty(BrokerDetails.OPTIONS_ENCRYPTION_TRUST_STORE_PASSWORD));
> }
> {code}
> Method {{conSettings.setEncryptionTrustStorePassword}} should be invoked 
> instead. 
> The workaround for this issue is to set trust store password using JVM 
> property {{javax.net.ssl.trustStorePassword}}.



--
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-8283) [JMS AMQP 0-x] Connection option 'encryption_trust_store_password' is mistakenly used to set encryption keystore password rather than encryption trust store password as i

2019-05-10 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8283:


Assignee: Alex Rudyy

> [JMS AMQP 0-x] Connection option 'encryption_trust_store_password' is 
> mistakenly used to set encryption keystore password rather than encryption 
> trust store password as intendant 
> ---
>
> Key: QPID-8283
> URL: https://issues.apache.org/jira/browse/QPID-8283
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-6.1.6, 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-client-0-x-6.3.0, qpid-java-6.1.5, qpid-java-client-0-x-6.3.1, 
> qpid-java-6.1.7, qpid-java-client-0-x-6.3.2, qpid-java-client-0-x-6.3.3
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.4
>
>
> Connection option {{encryption_trust_store_password}} is mistakenly used to 
> set encryption keystore password rather than encryption trust store password 
> as intendant.
> Here is problematic code in {{BrokerDetails}}:
> {code}
> if 
> (getProperty(BrokerDetails.OPTIONS_ENCRYPTION_TRUST_STORE_PASSWORD) != null)
> {
> conSettings.setEncryptionKeyStorePassword(
> 
> getProperty(BrokerDetails.OPTIONS_ENCRYPTION_TRUST_STORE_PASSWORD));
> }
> {code}
> Method {{conSettings.setEncryptionTrustStorePassword}} should be invoked 
> instead. 
> The workaround for this issue is to set trust store password using JVM 
> property {{javax.net.ssl.trustStorePassword}}.



--
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-8255) [JMS AMQP 0-x] Connection failure with connection option 'client_cert_priv_key_path' and java 11

2019-05-10 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8255:
-
Fix Version/s: qpid-java-client-0-x-6.3.4
   qpid-java-client-0-x-6.4.0

> [JMS AMQP 0-x] Connection failure  with connection option 
> 'client_cert_priv_key_path' and java 11
> -
>
> Key: QPID-8255
> URL: https://issues.apache.org/jira/browse/QPID-8255
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.3
> Environment: java11
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.4, qpid-java-client-0-x-6.4.0
>
>
> Connection establishment fails with java 11 when connection option 
> 'client_cert_priv_key_path' is used:
> {noformat}
> javax.jms.JMSException: Error creating connection: Key protection  algorithm 
> not found: java.security.UnrecoverableKeyException: Encrypt Private Key 
> failed: getSecretKey failed: Password is not ASCII
>     at 
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:169)
>     at 
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:143)
>     at 
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:57)
>     at 
> org.apache.qpid.systests.QpidJmsClient0xConnectionBuilder.build(QpidJmsClient0xConnectionBuilder.java:270)
>     at 
> org.apache.qpid.systests.jms_1_1.extensions.tls.TlsTest.testCreateSSLWithCertFileAndPrivateKey(TlsTest.java:508)
>     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>     at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>     at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>     at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>     at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at 
> org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:84)
>     at 
> org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:28)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>     at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.apache.qpid.tests.utils.QpidTestRunner.run(QpidTestRunner.java:59)
>     at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
>     at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>     at 
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
>     at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
>     at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: org.apache.qpid.AMQConnectionFailureException: Key protection  
> algorithm not found: java.security.UnrecoverableKeyException: Encrypt Private 
> Key failed: getSecretKey failed: Password is not ASCII
>     at 
> org.apache.qpid.client.AMQConnection.makeConnection(AMQConnection.java:672)
>     at org.apache.qpid.client.AMQConnection.(AMQConnection.java:522)
>     at 
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:164)
>     ... 32 more
> Caused by: org.apache.qpid.transport.TransportException: Error creating SSL 
> Context
>     at 
> org.apache.qpid.transport.network.security.SecurityLayerFactory$SSLSecurityLayer.(SecurityLayerFactory.java:100)
>     at 
> 

[jira] [Updated] (QPID-8282) [JMS AMQP 0-x] Java 11 build/runtime failure due to use of javax.xml.bind.DatatypeConverter

2019-05-10 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8282:
-
Fix Version/s: qpid-java-client-0-x-6.4.0

> [JMS AMQP 0-x] Java 11 build/runtime failure due to use of 
> javax.xml.bind.DatatypeConverter
> ---
>
> Key: QPID-8282
> URL: https://issues.apache.org/jira/browse/QPID-8282
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.3
>Reporter: Robbie Gemmell
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.4, qpid-java-client-0-x-6.4.0
>
>
> In setting up a new system, I happened to make attempt to build the JMS AMQP 
> 0-x client using Java 11. It failed to compile due to use of 
> javax.xml.bind.DatatypeConverter for Base64 handling in the SCRAM-SHA 
> mechanisms. This prevents building on Java 11, and would break use of 
> SCRAM-SHA while running on Java 11 assuming nothing else stopped things 
> working.
> Although the 0-x client is essentially in maintenance/legacy mode at this 
> point, blockers as trivial as Base 64 handling would be nice to resolved if 
> it made using Java 11 possible, if only to simplify migrations later.



--
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-8282) [JMS AMQP 0-x] Java 11 build/runtime failure due to use of javax.xml.bind.DatatypeConverter

2019-05-10 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8282:


Assignee: Alex Rudyy

> [JMS AMQP 0-x] Java 11 build/runtime failure due to use of 
> javax.xml.bind.DatatypeConverter
> ---
>
> Key: QPID-8282
> URL: https://issues.apache.org/jira/browse/QPID-8282
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.3
>Reporter: Robbie Gemmell
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.4
>
>
> In setting up a new system, I happened to make attempt to build the JMS AMQP 
> 0-x client using Java 11. It failed to compile due to use of 
> javax.xml.bind.DatatypeConverter for Base64 handling in the SCRAM-SHA 
> mechanisms. This prevents building on Java 11, and would break use of 
> SCRAM-SHA while running on Java 11 assuming nothing else stopped things 
> working.
> Although the 0-x client is essentially in maintenance/legacy mode at this 
> point, blockers as trivial as Base 64 handling would be nice to resolved if 
> it made using Java 11 possible, if only to simplify migrations later.



--
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-8282) [JMS AMQP 0-x] Java 11 build/runtime failure due to use of javax.xml.bind.DatatypeConverter

2019-05-10 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8282:
-
Status: Reviewable  (was: In Progress)

> [JMS AMQP 0-x] Java 11 build/runtime failure due to use of 
> javax.xml.bind.DatatypeConverter
> ---
>
> Key: QPID-8282
> URL: https://issues.apache.org/jira/browse/QPID-8282
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.3
>Reporter: Robbie Gemmell
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.4
>
>
> In setting up a new system, I happened to make attempt to build the JMS AMQP 
> 0-x client using Java 11. It failed to compile due to use of 
> javax.xml.bind.DatatypeConverter for Base64 handling in the SCRAM-SHA 
> mechanisms. This prevents building on Java 11, and would break use of 
> SCRAM-SHA while running on Java 11 assuming nothing else stopped things 
> working.
> Although the 0-x client is essentially in maintenance/legacy mode at this 
> point, blockers as trivial as Base 64 handling would be nice to resolved if 
> it made using Java 11 possible, if only to simplify migrations later.



--
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-8255) [JMS AMQP 0-x] Connection failure with connection option 'client_cert_priv_key_path' and java 11

2019-05-10 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8255:
-
Status: Reviewable  (was: In Progress)

> [JMS AMQP 0-x] Connection failure  with connection option 
> 'client_cert_priv_key_path' and java 11
> -
>
> Key: QPID-8255
> URL: https://issues.apache.org/jira/browse/QPID-8255
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.3
> Environment: java11
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.4, qpid-java-client-0-x-6.4.0
>
>
> Connection establishment fails with java 11 when connection option 
> 'client_cert_priv_key_path' is used:
> {noformat}
> javax.jms.JMSException: Error creating connection: Key protection  algorithm 
> not found: java.security.UnrecoverableKeyException: Encrypt Private Key 
> failed: getSecretKey failed: Password is not ASCII
>     at 
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:169)
>     at 
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:143)
>     at 
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:57)
>     at 
> org.apache.qpid.systests.QpidJmsClient0xConnectionBuilder.build(QpidJmsClient0xConnectionBuilder.java:270)
>     at 
> org.apache.qpid.systests.jms_1_1.extensions.tls.TlsTest.testCreateSSLWithCertFileAndPrivateKey(TlsTest.java:508)
>     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>     at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>     at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>     at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>     at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at 
> org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:84)
>     at 
> org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:28)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>     at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.apache.qpid.tests.utils.QpidTestRunner.run(QpidTestRunner.java:59)
>     at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
>     at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>     at 
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
>     at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
>     at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: org.apache.qpid.AMQConnectionFailureException: Key protection  
> algorithm not found: java.security.UnrecoverableKeyException: Encrypt Private 
> Key failed: getSecretKey failed: Password is not ASCII
>     at 
> org.apache.qpid.client.AMQConnection.makeConnection(AMQConnection.java:672)
>     at org.apache.qpid.client.AMQConnection.(AMQConnection.java:522)
>     at 
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:164)
>     ... 32 more
> Caused by: org.apache.qpid.transport.TransportException: Error creating SSL 
> Context
>     at 
> org.apache.qpid.transport.network.security.SecurityLayerFactory$SSLSecurityLayer.(SecurityLayerFactory.java:100)
>     at 
> org.apache.qpid.transport.network.security.SecurityLayerFactory.newInstance(SecurityLayerFactory.java:59)
>     at 

[jira] [Assigned] (QPID-8255) [JMS AMQP 0-x] Connection failure with connection option 'client_cert_priv_key_path' and java 11

2019-05-10 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8255:


Assignee: Alex Rudyy

> [JMS AMQP 0-x] Connection failure  with connection option 
> 'client_cert_priv_key_path' and java 11
> -
>
> Key: QPID-8255
> URL: https://issues.apache.org/jira/browse/QPID-8255
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.3
> Environment: java11
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
>
> Connection establishment fails with java 11 when connection option 
> 'client_cert_priv_key_path' is used:
> {noformat}
> javax.jms.JMSException: Error creating connection: Key protection  algorithm 
> not found: java.security.UnrecoverableKeyException: Encrypt Private Key 
> failed: getSecretKey failed: Password is not ASCII
>     at 
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:169)
>     at 
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:143)
>     at 
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:57)
>     at 
> org.apache.qpid.systests.QpidJmsClient0xConnectionBuilder.build(QpidJmsClient0xConnectionBuilder.java:270)
>     at 
> org.apache.qpid.systests.jms_1_1.extensions.tls.TlsTest.testCreateSSLWithCertFileAndPrivateKey(TlsTest.java:508)
>     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>     at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>     at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>     at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>     at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at 
> org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:84)
>     at 
> org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:28)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>     at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.apache.qpid.tests.utils.QpidTestRunner.run(QpidTestRunner.java:59)
>     at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
>     at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>     at 
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
>     at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
>     at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: org.apache.qpid.AMQConnectionFailureException: Key protection  
> algorithm not found: java.security.UnrecoverableKeyException: Encrypt Private 
> Key failed: getSecretKey failed: Password is not ASCII
>     at 
> org.apache.qpid.client.AMQConnection.makeConnection(AMQConnection.java:672)
>     at org.apache.qpid.client.AMQConnection.(AMQConnection.java:522)
>     at 
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:164)
>     ... 32 more
> Caused by: org.apache.qpid.transport.TransportException: Error creating SSL 
> Context
>     at 
> org.apache.qpid.transport.network.security.SecurityLayerFactory$SSLSecurityLayer.(SecurityLayerFactory.java:100)
>     at 
> org.apache.qpid.transport.network.security.SecurityLayerFactory.newInstance(SecurityLayerFactory.java:59)
>     at 
> 

[jira] [Updated] (QPID-8311) [Broker-J][WMC] Allow setting replaceExistingArguments in UI for bind creation

2019-05-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8311:
-
Summary: [Broker-J][WMC] Allow setting replaceExistingArguments in UI for 
bind creation  (was: [Broker-J][WMC] Allow setting replaceExistingArguments in 
add bind UI)

> [Broker-J][WMC] Allow setting replaceExistingArguments in UI for bind creation
> --
>
> Key: QPID-8311
> URL: https://issues.apache.org/jira/browse/QPID-8311
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> Modify add binding UI to allow setting replaceExistingArguments in bind 
> operation



--
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-8307) [Broker-J] Document the virtualHostInitialConfiguration

2019-05-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8307:
-
Summary: [Broker-J] Document the virtualHostInitialConfiguration  (was: 
Broker-J - Document the virtualHostInitialConfiguration)

> [Broker-J] Document the virtualHostInitialConfiguration
> ---
>
> Key: QPID-8307
> URL: https://issues.apache.org/jira/browse/QPID-8307
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J, Java Documentation
>Affects Versions: qpid-java-broker-7.1.2
>Reporter: Tom Jordahl
>Assignee: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> There is no document of the virtualHostInitialConfiguration item in the JSON 
> initial configuration file.
> This is important for any automated configuration of the Qpid broker - for 
> instance a chef recipe configuration of a virtual host that wants a "Node 
> Creation Policy" defined at startup.
> In response to a question on Qpid-users (reference 
> [http://qpid.2158936.n2.nabble.com/Qpid-Broker-J-Configuring-nodeAutoCreationPolicies-for-an-BDB-HA-cluster-from-json-td7683530.html]
>  )
> On 5/1/19, 3:09 PM, "Oleksandr Rudyy"  wrote:
>  Hi Tom,
>     The node auto creation policies can be set on virtual host only, as it is
>     an attribute of virtual host. Adding policies into virtual host node
>     configuration does not have any effect. The settings are simply ignored 
> and
>     removed on configuration update.
>     If you need to have the policies in broker initial configuration, you can
>     add them into virtual host inital configuration. Though, at the moment,
>     virtualHostInitialConfigurati can only have string values. Thus, you need
>     to stringify your policy json.
>     For example,
>     ...
>     "virtualHostInitialConfiguration":
>     
> "\{\"type\":\"BDB_HA\",\"context\":{},\"name\":\"$parent.name\",\"nodeAutoCreationPolicies\":
>     [\{\"pattern\":\"*\",\"nodeType\":\"Queue\" ... }]}"
>     ...
>    Kind Regards,
>     Alex



--
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-8312) [Broker-J] Release Qpid Broker-J version 7.1.3

2019-05-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8312:


Assignee: Alex Rudyy

> [Broker-J] Release Qpid Broker-J version 7.1.3
> --
>
> Key: QPID-8312
> URL: https://issues.apache.org/jira/browse/QPID-8312
> Project: Qpid
>  Issue Type: Task
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.3
>
>
> Release Qpid Broker-J version 7.1.3 as per instructions at
> [https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J]



--
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-8312) [Broker-J] Release Qpid Broker-J version 7.1.3

2019-05-08 Thread Alex Rudyy (JIRA)
Alex Rudyy created QPID-8312:


 Summary: [Broker-J] Release Qpid Broker-J version 7.1.3
 Key: QPID-8312
 URL: https://issues.apache.org/jira/browse/QPID-8312
 Project: Qpid
  Issue Type: Task
Reporter: Alex Rudyy
 Fix For: qpid-java-broker-7.1.3


Release Qpid Broker-J version 7.1.3 as per instructions at
[https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J]



--
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-8307) Broker-J - Document the virtualHostInitialConfiguration

2019-05-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8307:
-
  Priority: Trivial  (was: Major)
Issue Type: Improvement  (was: Bug)

> Broker-J - Document the virtualHostInitialConfiguration
> ---
>
> Key: QPID-8307
> URL: https://issues.apache.org/jira/browse/QPID-8307
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J, Java Documentation
>Affects Versions: qpid-java-broker-7.1.2
>Reporter: Tom Jordahl
>Assignee: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> There is no document of the virtualHostInitialConfiguration item in the JSON 
> initial configuration file.
> This is important for any automated configuration of the Qpid broker - for 
> instance a chef recipe configuration of a virtual host that wants a "Node 
> Creation Policy" defined at startup.
> In response to a question on Qpid-users (reference 
> [http://qpid.2158936.n2.nabble.com/Qpid-Broker-J-Configuring-nodeAutoCreationPolicies-for-an-BDB-HA-cluster-from-json-td7683530.html]
>  )
> On 5/1/19, 3:09 PM, "Oleksandr Rudyy"  wrote:
>  Hi Tom,
>     The node auto creation policies can be set on virtual host only, as it is
>     an attribute of virtual host. Adding policies into virtual host node
>     configuration does not have any effect. The settings are simply ignored 
> and
>     removed on configuration update.
>     If you need to have the policies in broker initial configuration, you can
>     add them into virtual host inital configuration. Though, at the moment,
>     virtualHostInitialConfigurati can only have string values. Thus, you need
>     to stringify your policy json.
>     For example,
>     ...
>     "virtualHostInitialConfiguration":
>     
> "\{\"type\":\"BDB_HA\",\"context\":{},\"name\":\"$parent.name\",\"nodeAutoCreationPolicies\":
>     [\{\"pattern\":\"*\",\"nodeType\":\"Queue\" ... }]}"
>     ...
>    Kind Regards,
>     Alex



--
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-8305) [Broker-J][JDBC Message Store] Performance regression when increasing the number of queues linked to a topic

2019-05-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-8305.
--
Resolution: Fixed

> [Broker-J][JDBC Message Store] Performance regression when increasing the 
> number of queues linked to a topic
> 
>
> Key: QPID-8305
> URL: https://issues.apache.org/jira/browse/QPID-8305
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> When sending a message to a topic, if this message is routed to N queues then 
> we will do N+2 database inserts: 1 for the metadata, 1 for the content and 1 
> for each message/queue mapping (QPID_QUEUE_ENTRIES). The last N inserts could 
> be batched in a single operation.



--
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-8305) [Broker-J][JDBC Message Store] Performance regression when increasing the number of queues linked to a topic

2019-05-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8305:


Assignee: Alex Rudyy

> [Broker-J][JDBC Message Store] Performance regression when increasing the 
> number of queues linked to a topic
> 
>
> Key: QPID-8305
> URL: https://issues.apache.org/jira/browse/QPID-8305
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> When sending a message to a topic, if this message is routed to N queues then 
> we will do N+2 database inserts: 1 for the metadata, 1 for the content and 1 
> for each message/queue mapping (QPID_QUEUE_ENTRIES). The last N inserts could 
> be batched in a single operation.



--
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-8311) [Broker-J][WMC] Allow setting replaceExistingArguments in add bind UI

2019-05-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8311:
-
Status: Reviewable  (was: In Progress)

> [Broker-J][WMC] Allow setting replaceExistingArguments in add bind UI
> -
>
> Key: QPID-8311
> URL: https://issues.apache.org/jira/browse/QPID-8311
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> Modify add binding UI to allow setting replaceExistingArguments in bind 
> operation



--
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-8311) [Broker-J][WMC] Allow setting replaceExistingArguments in add bind UI

2019-05-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8311:


Assignee: Alex Rudyy

> [Broker-J][WMC] Allow setting replaceExistingArguments in add bind UI
> -
>
> Key: QPID-8311
> URL: https://issues.apache.org/jira/browse/QPID-8311
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> Modify add binding UI to allow setting replaceExistingArguments in bind 
> operation



--
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-8306) [Broker-J] Add ability to update TLS transport on AMQP port after changing keystore, trustores or other TLS related attributes

2019-05-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8306:
-
Fix Version/s: (was: qpid-java-broker-7.1.3)

> [Broker-J] Add ability to update TLS transport on AMQP port after changing 
> keystore, trustores or other TLS related attributes
> --
>
> Key: QPID-8306
> URL: https://issues.apache.org/jira/browse/QPID-8306
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
>
> Broker restart is required after changes to AMQP port TLS attributes, 
> keystore and trust stores. It should be possible to update TLS transport 
> without affecting existing AMQP connections.



--
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-8311) [Broker-J][WMC] Allow setting replaceExistingArguments in add bind UI

2019-05-08 Thread Alex Rudyy (JIRA)
Alex Rudyy created QPID-8311:


 Summary: [Broker-J][WMC] Allow setting replaceExistingArguments in 
add bind UI
 Key: QPID-8311
 URL: https://issues.apache.org/jira/browse/QPID-8311
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J
Reporter: Alex Rudyy
 Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3


Modify add binding UI to allow setting replaceExistingArguments in bind 
operation



--
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-8307) Broker-J - Document the virtualHostInitialConfiguration

2019-05-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8307:


Assignee: Alex Rudyy

> Broker-J - Document the virtualHostInitialConfiguration
> ---
>
> Key: QPID-8307
> URL: https://issues.apache.org/jira/browse/QPID-8307
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J, Java Documentation
>Affects Versions: qpid-java-broker-7.1.2
>Reporter: Tom Jordahl
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> There is no document of the virtualHostInitialConfiguration item in the JSON 
> initial configuration file.
> This is important for any automated configuration of the Qpid broker - for 
> instance a chef recipe configuration of a virtual host that wants a "Node 
> Creation Policy" defined at startup.
> In response to a question on Qpid-users (reference 
> [http://qpid.2158936.n2.nabble.com/Qpid-Broker-J-Configuring-nodeAutoCreationPolicies-for-an-BDB-HA-cluster-from-json-td7683530.html]
>  )
> On 5/1/19, 3:09 PM, "Oleksandr Rudyy"  wrote:
>  Hi Tom,
>     The node auto creation policies can be set on virtual host only, as it is
>     an attribute of virtual host. Adding policies into virtual host node
>     configuration does not have any effect. The settings are simply ignored 
> and
>     removed on configuration update.
>     If you need to have the policies in broker initial configuration, you can
>     add them into virtual host inital configuration. Though, at the moment,
>     virtualHostInitialConfigurati can only have string values. Thus, you need
>     to stringify your policy json.
>     For example,
>     ...
>     "virtualHostInitialConfiguration":
>     
> "\{\"type\":\"BDB_HA\",\"context\":{},\"name\":\"$parent.name\",\"nodeAutoCreationPolicies\":
>     [\{\"pattern\":\"*\",\"nodeType\":\"Queue\" ... }]}"
>     ...
>    Kind Regards,
>     Alex



--
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-8307) Broker-J - Document the virtualHostInitialConfiguration

2019-05-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8307:
-
Fix Version/s: qpid-java-broker-7.1.3
   qpid-java-broker-8.0.0

> Broker-J - Document the virtualHostInitialConfiguration
> ---
>
> Key: QPID-8307
> URL: https://issues.apache.org/jira/browse/QPID-8307
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J, Java Documentation
>Affects Versions: qpid-java-broker-7.1.2
>Reporter: Tom Jordahl
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> There is no document of the virtualHostInitialConfiguration item in the JSON 
> initial configuration file.
> This is important for any automated configuration of the Qpid broker - for 
> instance a chef recipe configuration of a virtual host that wants a "Node 
> Creation Policy" defined at startup.
> In response to a question on Qpid-users (reference 
> [http://qpid.2158936.n2.nabble.com/Qpid-Broker-J-Configuring-nodeAutoCreationPolicies-for-an-BDB-HA-cluster-from-json-td7683530.html]
>  )
> On 5/1/19, 3:09 PM, "Oleksandr Rudyy"  wrote:
>  Hi Tom,
>     The node auto creation policies can be set on virtual host only, as it is
>     an attribute of virtual host. Adding policies into virtual host node
>     configuration does not have any effect. The settings are simply ignored 
> and
>     removed on configuration update.
>     If you need to have the policies in broker initial configuration, you can
>     add them into virtual host inital configuration. Though, at the moment,
>     virtualHostInitialConfigurati can only have string values. Thus, you need
>     to stringify your policy json.
>     For example,
>     ...
>     "virtualHostInitialConfiguration":
>     
> "\{\"type\":\"BDB_HA\",\"context\":{},\"name\":\"$parent.name\",\"nodeAutoCreationPolicies\":
>     [\{\"pattern\":\"*\",\"nodeType\":\"Queue\" ... }]}"
>     ...
>    Kind Regards,
>     Alex



--
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-8307) Broker-J - Document the virtualHostInitialConfiguration

2019-05-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8307:
-
Status: Reviewable  (was: In Progress)

> Broker-J - Document the virtualHostInitialConfiguration
> ---
>
> Key: QPID-8307
> URL: https://issues.apache.org/jira/browse/QPID-8307
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J, Java Documentation
>Affects Versions: qpid-java-broker-7.1.2
>Reporter: Tom Jordahl
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> There is no document of the virtualHostInitialConfiguration item in the JSON 
> initial configuration file.
> This is important for any automated configuration of the Qpid broker - for 
> instance a chef recipe configuration of a virtual host that wants a "Node 
> Creation Policy" defined at startup.
> In response to a question on Qpid-users (reference 
> [http://qpid.2158936.n2.nabble.com/Qpid-Broker-J-Configuring-nodeAutoCreationPolicies-for-an-BDB-HA-cluster-from-json-td7683530.html]
>  )
> On 5/1/19, 3:09 PM, "Oleksandr Rudyy"  wrote:
>  Hi Tom,
>     The node auto creation policies can be set on virtual host only, as it is
>     an attribute of virtual host. Adding policies into virtual host node
>     configuration does not have any effect. The settings are simply ignored 
> and
>     removed on configuration update.
>     If you need to have the policies in broker initial configuration, you can
>     add them into virtual host inital configuration. Though, at the moment,
>     virtualHostInitialConfigurati can only have string values. Thus, you need
>     to stringify your policy json.
>     For example,
>     ...
>     "virtualHostInitialConfiguration":
>     
> "\{\"type\":\"BDB_HA\",\"context\":{},\"name\":\"$parent.name\",\"nodeAutoCreationPolicies\":
>     [\{\"pattern\":\"*\",\"nodeType\":\"Queue\" ... }]}"
>     ...
>    Kind Regards,
>     Alex



--
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-8309) [Broker-J] [AMQP 0-8..0-91] Concurrent transaction commit can fail with: Cannot commit transaction with state 'DISCHARGING'

2019-05-07 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8309:
-
Status: Reviewable  (was: In Progress)

> [Broker-J] [AMQP 0-8..0-91] Concurrent transaction commit can fail with: 
> Cannot commit transaction with state 'DISCHARGING'
> ---
>
> Key: QPID-8309
> URL: https://issues.apache.org/jira/browse/QPID-8309
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.1.1, 
> qpid-java-broker-7.1.2
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> Concurrent transaction commit can end-up in error: Cannot commit transaction 
> with state 'DISCHARGING'. The stack trace like the one below is reported into 
> Qpid broker logs:
> {noformat}
> 2019-05-06 03:32:05,960 WARN  [IO-/127.0.0.1:5672] 
> (o.a.q.s.p.v.AMQPConnection_0_8Impl) - Unexpected exception
> java.lang.IllegalStateException: Cannot commit transaction with state 
> 'DISCHARGING'
> at 
> org.apache.qpid.server.txn.LocalTransaction.commitAsync(LocalTransaction.java:427)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.commit(AMQChannel.java:1092)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveTxCommit(AMQChannel.java:3385)
> at 
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:230)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> {noformat}
> Transaction state checks added as part of QPID-7541 introduced a regression 
> for asynchronous way of committing transactions used for AMQP 0-8..0-91. The 
> asynchronous transaction needs to be synced before the state check is 
> performed.



--
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-8309) [Broker-J] [AMQP 0-8..0-91] Concurrent transaction commit can fail with: Cannot commit transaction with state 'DISCHARGING'

2019-05-07 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8309:


Assignee: Alex Rudyy

> [Broker-J] [AMQP 0-8..0-91] Concurrent transaction commit can fail with: 
> Cannot commit transaction with state 'DISCHARGING'
> ---
>
> Key: QPID-8309
> URL: https://issues.apache.org/jira/browse/QPID-8309
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.1.1, 
> qpid-java-broker-7.1.2
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.1.3
>
>
> Concurrent transaction commit can end-up in error: Cannot commit transaction 
> with state 'DISCHARGING'. The stack trace like the one below is reported into 
> Qpid broker logs:
> {noformat}
> 2019-05-06 03:32:05,960 WARN  [IO-/127.0.0.1:5672] 
> (o.a.q.s.p.v.AMQPConnection_0_8Impl) - Unexpected exception
> java.lang.IllegalStateException: Cannot commit transaction with state 
> 'DISCHARGING'
> at 
> org.apache.qpid.server.txn.LocalTransaction.commitAsync(LocalTransaction.java:427)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.commit(AMQChannel.java:1092)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveTxCommit(AMQChannel.java:3385)
> at 
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:230)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> {noformat}
> Transaction state checks added as part of QPID-7541 introduced a regression 
> for asynchronous way of committing transactions used for AMQP 0-8..0-91. The 
> asynchronous transaction needs to be synced before the state check is 
> performed.



--
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-8309) [Broker-J] [AMQP 0-8..0-91] Concurrent transaction commit can fail with: Cannot commit transaction with state 'DISCHARGING'

2019-05-07 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8309:
-
Fix Version/s: qpid-java-broker-8.0.0

> [Broker-J] [AMQP 0-8..0-91] Concurrent transaction commit can fail with: 
> Cannot commit transaction with state 'DISCHARGING'
> ---
>
> Key: QPID-8309
> URL: https://issues.apache.org/jira/browse/QPID-8309
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.1.1, 
> qpid-java-broker-7.1.2
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> Concurrent transaction commit can end-up in error: Cannot commit transaction 
> with state 'DISCHARGING'. The stack trace like the one below is reported into 
> Qpid broker logs:
> {noformat}
> 2019-05-06 03:32:05,960 WARN  [IO-/127.0.0.1:5672] 
> (o.a.q.s.p.v.AMQPConnection_0_8Impl) - Unexpected exception
> java.lang.IllegalStateException: Cannot commit transaction with state 
> 'DISCHARGING'
> at 
> org.apache.qpid.server.txn.LocalTransaction.commitAsync(LocalTransaction.java:427)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.commit(AMQChannel.java:1092)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveTxCommit(AMQChannel.java:3385)
> at 
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:230)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> {noformat}
> Transaction state checks added as part of QPID-7541 introduced a regression 
> for asynchronous way of committing transactions used for AMQP 0-8..0-91. The 
> asynchronous transaction needs to be synced before the state check is 
> performed.



--
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-8297) [Broker-J][JDBC Message Store][Oracle] QPID_MESSAGE_CONTENT reserved space keeps growing until it reaches the limit and crashes

2019-05-07 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8297:
-
Summary: [Broker-J][JDBC Message Store][Oracle] QPID_MESSAGE_CONTENT 
reserved space keeps growing until it reaches the limit and crashes  (was: 
[Broker-J][Oracle Message Store] QPID_MESSAGE_CONTENT reserved space keeps 
growing until it reaches the limit and crashes)

> [Broker-J][JDBC Message Store][Oracle] QPID_MESSAGE_CONTENT reserved space 
> keeps growing until it reaches the limit and crashes
> ---
>
> Key: QPID-8297
> URL: https://issues.apache.org/jira/browse/QPID-8297
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> Under a continuous high load, the Oracle message store crashes because the 
> reserved space for the table QPID_MESSAGE_CONTENT keeps on growing (even if 
> the table itself is empty since we consume as fast as we produce).
> This only happens for "big" messages (over 4KB) and comes from the way Oracle 
> handles the LOB types (content column is declared as a BLOB). For LOB values 
> over 4KB Oracle reserves some space in the table to handle the value but, by 
> default, it won't actually release it (even if the value is removed) before a 
> few hours.
> So when we have a high load of big messages that lasts a few hours we end up 
> reaching the max size of the tablespace and the database crashes...



--
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-8294) [Broker-J][JDBC Message Store][Oracle] Batch delete fails for more than 1000 messages

2019-05-07 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8294:
-
Summary: [Broker-J][JDBC Message Store][Oracle] Batch delete fails for more 
than 1000 messages  (was: [Broker-J][Oracle Message Store] Batch delete fails 
for more than 1000 messages)

> [Broker-J][JDBC Message Store][Oracle] Batch delete fails for more than 1000 
> messages
> -
>
> Key: QPID-8294
> URL: https://issues.apache.org/jira/browse/QPID-8294
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> When under high load, the Broker-J can end up having to delete more than 1000 
> messages in a single batch. But some databases (and Oracle in particular) put 
> a limit to the number of elements you can have in the IN clause. So we end up 
> with the following exception: ORA-01795: maximum number of expressions in a 
> list is 1000



--
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-8309) [Broker-J] [AMQP 0-8..0-91] Concurrent transaction commit can fail with: Cannot commit transaction with state 'DISCHARGING'

2019-05-07 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8309:
-
Description: 
Concurrent transaction commit can end-up in error: Cannot commit transaction 
with state 'DISCHARGING'. The stack trace like the one below is reported into 
Qpid broker logs:
{noformat}
2019-05-06 03:32:05,960 WARN  [IO-/127.0.0.1:5672] 
(o.a.q.s.p.v.AMQPConnection_0_8Impl) - Unexpected exception
java.lang.IllegalStateException: Cannot commit transaction with state 
'DISCHARGING'
at 
org.apache.qpid.server.txn.LocalTransaction.commitAsync(LocalTransaction.java:427)
at 
org.apache.qpid.server.protocol.v0_8.AMQChannel.commit(AMQChannel.java:1092)
at 
org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveTxCommit(AMQChannel.java:3385)
at 
org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:230)
at 
org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
at 
org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
at 
org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
{noformat}
Transaction state checks added as part of QPID-7541 introduced a regression for 
asynchronous way of committing transactions used for AMQP 0-8..0-91. The 
asynchronous transaction needs to be synced before the state check is performed.


  was:
Concurrent transaction commit can end-up in error: Cannot commit transaction 
with state 'DISCHARGING'. The stack trace like the one below is reported into 
Qpid broker logs:
{noformat}
2019-05-06 03:32:05,960 WARN  [IO-/127.0.0.1:5672] 
(o.a.q.s.p.v.AMQPConnection_0_8Impl) - Unexpected exception
java.lang.IllegalStateException: Cannot commit transaction with state 
'DISCHARGING'
at 
org.apache.qpid.server.txn.LocalTransaction.commitAsync(LocalTransaction.java:427)
at 
org.apache.qpid.server.protocol.v0_8.AMQChannel.commit(AMQChannel.java:1092)
at 
org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveTxCommit(AMQChannel.java:3385)
at 
org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:230)
at 
org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
at 
org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
at 
org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
{noformat}
Transaction state checks added as part of QPID-7541 introduced a regression for 
asynchronous way of committing transactions used for AMQP 0-8..0-91. The 
asynchronous transaction needs to be synced before state check is performed.



> [Broker-J] [AMQP 0-8..0-91] Concurrent transaction commit can fail with: 
> Cannot commit transaction with state 'DISCHARGING'
> ---
>
> Key: QPID-8309
> URL: https://issues.apache.org/jira/browse/QPID-8309
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.1.1, 
> qpid-java-broker-7.1.2
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.1.3
>
>
> Concurrent transaction commit can end-up in error: Cannot commit transaction 
> with state 'DISCHARGING'. The stack trace like the one below is reported into 
> Qpid broker logs:
> {noformat}
> 2019-05-06 03:32:05,960 WARN  [IO-/127.0.0.1:5672] 
> (o.a.q.s.p.v.AMQPConnection_0_8Impl) - Unexpected exception
> java.lang.IllegalStateException: Cannot commit transaction with state 
> 'DISCHARGING'
> at 
> 

[jira] [Created] (QPID-8309) [Broker-J] [AMQP 0-8..0-91] Concurrent transaction commit can fail with: Cannot commit transaction with state 'DISCHARGING'

2019-05-07 Thread Alex Rudyy (JIRA)
Alex Rudyy created QPID-8309:


 Summary: [Broker-J] [AMQP 0-8..0-91] Concurrent transaction commit 
can fail with: Cannot commit transaction with state 'DISCHARGING'
 Key: QPID-8309
 URL: https://issues.apache.org/jira/browse/QPID-8309
 Project: Qpid
  Issue Type: Bug
  Components: Broker-J
Affects Versions: qpid-java-broker-7.1.2, qpid-java-broker-7.1.1, 
qpid-java-broker-7.1.0
Reporter: Alex Rudyy
 Fix For: qpid-java-broker-7.1.3


Concurrent transaction commit can end-up in error: Cannot commit transaction 
with state 'DISCHARGING'. The stack trace like the one below is reported into 
Qpid broker logs:
{noformat}
2019-05-06 03:32:05,960 WARN  [IO-/127.0.0.1:5672] 
(o.a.q.s.p.v.AMQPConnection_0_8Impl) - Unexpected exception
java.lang.IllegalStateException: Cannot commit transaction with state 
'DISCHARGING'
at 
org.apache.qpid.server.txn.LocalTransaction.commitAsync(LocalTransaction.java:427)
at 
org.apache.qpid.server.protocol.v0_8.AMQChannel.commit(AMQChannel.java:1092)
at 
org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveTxCommit(AMQChannel.java:3385)
at 
org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:230)
at 
org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
at 
org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
at 
org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
{noformat}
Transaction state checks added as part of QPID-7541 introduced a regression for 
asynchronous way of committing transactions used for AMQP 0-8..0-91. The 
asynchronous transaction needs to be synced before state check is performed.




--
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-8304) [Broker-J][JDBC Message Store] Performance bottleneck at the level of the executor

2019-05-06 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8304:
-
Status: Reviewable  (was: In Progress)

> [Broker-J][JDBC Message Store] Performance bottleneck at the level of the 
> executor
> --
>
> Key: QPID-8304
> URL: https://issues.apache.org/jira/browse/QPID-8304
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>




--
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-8304) [Broker-J][JDBC Message Store] Performance bottleneck at the level of the executor

2019-05-06 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8304:


Assignee: Alex Rudyy

> [Broker-J][JDBC Message Store] Performance bottleneck at the level of the 
> executor
> --
>
> Key: QPID-8304
> URL: https://issues.apache.org/jira/browse/QPID-8304
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>




--
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-8303) [Broker-J][JDBC Message Store] Batch delete fails when deleting exactly 1000 messages

2019-05-06 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8303:
-
Fix Version/s: qpid-java-broker-7.1.3
   qpid-java-broker-8.0.0

> [Broker-J][JDBC Message Store] Batch delete fails when deleting exactly 1000 
> messages
> -
>
> Key: QPID-8303
> URL: https://issues.apache.org/jira/browse/QPID-8303
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> Following QPID-8294, when the batch delete has exactly IN_CLAUSE_MAX_SIZE 
> messages to handle, removeMessagesFromDatabase will be called twice and the 
> second time with an empty list.



--
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-8303) [Broker-J][JDBC Message Store] Batch delete fails when deleting exactly 1000 messages

2019-05-06 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8303:


Assignee: Alex Rudyy

> [Broker-J][JDBC Message Store] Batch delete fails when deleting exactly 1000 
> messages
> -
>
> Key: QPID-8303
> URL: https://issues.apache.org/jira/browse/QPID-8303
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Critical
>
> Following QPID-8294, when the batch delete has exactly IN_CLAUSE_MAX_SIZE 
> messages to handle, removeMessagesFromDatabase will be called twice and the 
> second time with an empty list.



--
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-8304) [Broker-J][JDBC Message Store] Performance bottleneck at the level of the executor

2019-05-06 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-8304.
--
Resolution: Fixed

> [Broker-J][JDBC Message Store] Performance bottleneck at the level of the 
> executor
> --
>
> Key: QPID-8304
> URL: https://issues.apache.org/jira/browse/QPID-8304
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>




--
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-8299) [Broker-J][JDBC Config Store] Possibility to customize the connection provider for the config of the Broker

2019-05-06 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8299:


Assignee: Alex Rudyy

> [Broker-J][JDBC Config Store] Possibility to customize the connection 
> provider for the config of the Broker
> ---
>
> Key: QPID-8299
> URL: https://issues.apache.org/jira/browse/QPID-8299
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Major
>
> Where the config of the Broker (not the Virtual Host) should be stored is 
> defined in the command line. Currently in the command line we can define 
> systemConfig.connectionUrl/username/password/tableNamePrefix but not 
> systemConfig.connectionPoolType



--
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-8305) [Broker-J][JDBC Message Store] Performance regression when increasing the number of queues linked to a topic

2019-05-06 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8305:
-
Fix Version/s: qpid-java-broker-7.1.3
   qpid-java-broker-8.0.0

> [Broker-J][JDBC Message Store] Performance regression when increasing the 
> number of queues linked to a topic
> 
>
> Key: QPID-8305
> URL: https://issues.apache.org/jira/browse/QPID-8305
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> When sending a message to a topic, if this message is routed to N queues then 
> we will do N+2 database inserts: 1 for the metadata, 1 for the content and 1 
> for each message/queue mapping (QPID_QUEUE_ENTRIES). The last N inserts could 
> be batched in a single operation.



--
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-8303) [Broker-J][JDBC Message Store] Batch delete fails when deleting exactly 1000 messages

2019-05-06 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8303:
-
Status: Reviewable  (was: In Progress)

> [Broker-J][JDBC Message Store] Batch delete fails when deleting exactly 1000 
> messages
> -
>
> Key: QPID-8303
> URL: https://issues.apache.org/jira/browse/QPID-8303
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> Following QPID-8294, when the batch delete has exactly IN_CLAUSE_MAX_SIZE 
> messages to handle, removeMessagesFromDatabase will be called twice and the 
> second time with an empty list.



--
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-8303) [Broker-J][JDBC Message Store] Batch delete fails when deleting exactly 1000 messages

2019-05-06 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-8303.
--
Resolution: Fixed

> [Broker-J][JDBC Message Store] Batch delete fails when deleting exactly 1000 
> messages
> -
>
> Key: QPID-8303
> URL: https://issues.apache.org/jira/browse/QPID-8303
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> Following QPID-8294, when the batch delete has exactly IN_CLAUSE_MAX_SIZE 
> messages to handle, removeMessagesFromDatabase will be called twice and the 
> second time with an empty list.



--
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-8304) [Broker-J][JDBC Message Store] Performance bottleneck at the level of the executor

2019-05-06 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8304:
-
Fix Version/s: qpid-java-broker-8.0.0

> [Broker-J][JDBC Message Store] Performance bottleneck at the level of the 
> executor
> --
>
> Key: QPID-8304
> URL: https://issues.apache.org/jira/browse/QPID-8304
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>




--
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-8299) [Broker-J][JDBC Config Store] Possibility to customize the connection provider for the config of the Broker

2019-05-06 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-8299.
--
Resolution: Fixed

> [Broker-J][JDBC Config Store] Possibility to customize the connection 
> provider for the config of the Broker
> ---
>
> Key: QPID-8299
> URL: https://issues.apache.org/jira/browse/QPID-8299
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> Where the config of the Broker (not the Virtual Host) should be stored is 
> defined in the command line. Currently in the command line we can define 
> systemConfig.connectionUrl/username/password/tableNamePrefix but not 
> systemConfig.connectionPoolType



--
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-8299) [Broker-J][JDBC Config Store] Possibility to customize the connection provider for the config of the Broker

2019-05-06 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8299:
-
Status: Reviewable  (was: In Progress)

> [Broker-J][JDBC Config Store] Possibility to customize the connection 
> provider for the config of the Broker
> ---
>
> Key: QPID-8299
> URL: https://issues.apache.org/jira/browse/QPID-8299
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> Where the config of the Broker (not the Virtual Host) should be stored is 
> defined in the command line. Currently in the command line we can define 
> systemConfig.connectionUrl/username/password/tableNamePrefix but not 
> systemConfig.connectionPoolType



--
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-8299) [Broker-J][JDBC Config Store] Possibility to customize the connection provider for the config of the Broker

2019-05-06 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8299:
-
Fix Version/s: qpid-java-broker-7.1.3
   qpid-java-broker-8.0.0

> [Broker-J][JDBC Config Store] Possibility to customize the connection 
> provider for the config of the Broker
> ---
>
> Key: QPID-8299
> URL: https://issues.apache.org/jira/browse/QPID-8299
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> Where the config of the Broker (not the Virtual Host) should be stored is 
> defined in the command line. Currently in the command line we can define 
> systemConfig.connectionUrl/username/password/tableNamePrefix but not 
> systemConfig.connectionPoolType



--
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-8302) [Broker-J] NonJavaKeystore does not validate private key and certificate matching on certificate update

2019-05-06 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8302:
-
Summary: [Broker-J] NonJavaKeystore does not validate private key and 
certificate matching on certificate update  (was: [Broker-J] 
NonKeystoreTrustore does not validate private key and certificate matching on 
certificate update)

> [Broker-J] NonJavaKeystore does not validate private key and certificate 
> matching on certificate update
> ---
>
> Key: QPID-8302
> URL: https://issues.apache.org/jira/browse/QPID-8302
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.2
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> NonJavaKeystore does not validate whether private key and certificate are 
> matching  on certificate update. In result of human error the certificate can 
> be updated to the wrong one and after broker restart the TLS stops working. 
> The validation should be improved to verify that private key matches the 
> certificate



--
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-8304) [Broker-J][JDBC Message Store] Performance bottleneck at the level of the executor

2019-05-06 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8304:
-
Fix Version/s: qpid-java-broker-7.1.3

> [Broker-J][JDBC Message Store] Performance bottleneck at the level of the 
> executor
> --
>
> Key: QPID-8304
> URL: https://issues.apache.org/jira/browse/QPID-8304
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Priority: Major
> Fix For: qpid-java-broker-7.1.3
>
>




--
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-8301) [Broker-J] Expose information about keystore certificate details

2019-05-01 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8301:
-
Status: Reviewable  (was: In Progress)

> [Broker-J] Expose information about keystore certificate details
> 
>
> Key: QPID-8301
> URL: https://issues.apache.org/jira/browse/QPID-8301
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> Keystore certificate details like issue, serial number and validity period 
> need to be exposed via management API and UI (similar the certificate details 
> available for trust stores). This should help to get the information about 
> intermediate certificates without the need to access broker configuration. It 
> could useful, when broker configuration is not accessible.



--
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-8302) [Broker-J] NonKeystoreTrustore does not validate private key and certificate matching on certificate update

2019-05-01 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8302:
-
Status: Reviewable  (was: In Progress)

> [Broker-J] NonKeystoreTrustore does not validate private key and certificate 
> matching on certificate update
> ---
>
> Key: QPID-8302
> URL: https://issues.apache.org/jira/browse/QPID-8302
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.2
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> NonJavaKeystore does not validate whether private key and certificate are 
> matching  on certificate update. In result of human error the certificate can 
> be updated to the wrong one and after broker restart the TLS stops working. 
> The validation should be improved to verify that private key matches the 
> certificate



--
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-8306) [Broker-J] Add ability to update TLS transport on AMQP port after changing keystore, trustores or other TLS related attributes

2019-04-30 Thread Alex Rudyy (JIRA)
Alex Rudyy created QPID-8306:


 Summary: [Broker-J] Add ability to update TLS transport on AMQP 
port after changing keystore, trustores or other TLS related attributes
 Key: QPID-8306
 URL: https://issues.apache.org/jira/browse/QPID-8306
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J
Reporter: Alex Rudyy
 Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3


Broker restart is required after changes to AMQP port TLS attributes, keystore 
and trust stores. It should be possible to update TLS transport without 
affecting existing AMQP connections.



--
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-8302) [Broker-J] NonKeystoreTrustore does not validate private key and certificate matching on certificate update

2019-04-27 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8302:
-
Description: NonJavaKeystore does not validate whether private key and 
certificate are matching  on certificate update. In result of human error the 
certificate can be updated to the wrong one and after broker restart the TLS 
stops working. The validation should be improved to verify that private key 
matches the certificate  (was: NonJavaTrustore does not validate whether 
private key and certificate are matching  on certificate update. In result of 
human error the certificate can be updated to the wrong one and after broker 
restart the TLS stops working. The validation should be improved to verify that 
private key matches the certificate)

> [Broker-J] NonKeystoreTrustore does not validate private key and certificate 
> matching on certificate update
> ---
>
> Key: QPID-8302
> URL: https://issues.apache.org/jira/browse/QPID-8302
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.2
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> NonJavaKeystore does not validate whether private key and certificate are 
> matching  on certificate update. In result of human error the certificate can 
> be updated to the wrong one and after broker restart the TLS stops working. 
> The validation should be improved to verify that private key matches the 
> certificate



--
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-8302) [Broker-J] NonKeystoreTrustore does not validate private key and certificate matching on certificate update

2019-04-27 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8302:


Assignee: Alex Rudyy

> [Broker-J] NonKeystoreTrustore does not validate private key and certificate 
> matching on certificate update
> ---
>
> Key: QPID-8302
> URL: https://issues.apache.org/jira/browse/QPID-8302
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.2
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> NonJavaKeystore does not validate whether private key and certificate are 
> matching  on certificate update. In result of human error the certificate can 
> be updated to the wrong one and after broker restart the TLS stops working. 
> The validation should be improved to verify that private key matches the 
> certificate



--
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-8302) [Broker-J] NonKeystoreTrustore does not validate private key and certificate matching on certificate update

2019-04-27 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8302:
-
Summary: [Broker-J] NonKeystoreTrustore does not validate private key and 
certificate matching on certificate update  (was: [Broker-J] NonJavaTrustore 
does not validate private key and certificate matching on certificate update)

> [Broker-J] NonKeystoreTrustore does not validate private key and certificate 
> matching on certificate update
> ---
>
> Key: QPID-8302
> URL: https://issues.apache.org/jira/browse/QPID-8302
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.2
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> NonJavaTrustore does not validate whether private key and certificate are 
> matching  on certificate update. In result of human error the certificate can 
> be updated to the wrong one and after broker restart the TLS stops working. 
> The validation should be improved to verify that private key matches the 
> certificate



--
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-8302) [Broker-J] NonJavaTrustore does not validate private key and certificate matching on certificate update

2019-04-27 Thread Alex Rudyy (JIRA)
Alex Rudyy created QPID-8302:


 Summary: [Broker-J] NonJavaTrustore does not validate private key 
and certificate matching on certificate update
 Key: QPID-8302
 URL: https://issues.apache.org/jira/browse/QPID-8302
 Project: Qpid
  Issue Type: Bug
  Components: Broker-J
Affects Versions: qpid-java-broker-7.1.2
Reporter: Alex Rudyy
 Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3


NonJavaTrustore does not validate whether private key and certificate are 
matching  on certificate update. In result of human error the certificate can 
be updated to the wrong one and after broker restart the TLS stops working. The 
validation should be improved to verify that private key matches the certificate



--
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-8301) [Broker-J] Expose information about keystore certificate details

2019-04-26 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8301:


Assignee: Alex Rudyy

> [Broker-J] Expose information about keystore certificate details
> 
>
> Key: QPID-8301
> URL: https://issues.apache.org/jira/browse/QPID-8301
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> Keystore certificate details like issue, serial number and validity period 
> need to be exposed via management API and UI (similar the certificate details 
> available for trust stores). This should help to get the information about 
> intermediate certificates without the need to access broker configuration. It 
> could useful, when broker configuration is not accessible.



--
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-8301) [Broker-J] Expose information about keystore certificate details

2019-04-26 Thread Alex Rudyy (JIRA)
Alex Rudyy created QPID-8301:


 Summary: [Broker-J] Expose information about keystore certificate 
details
 Key: QPID-8301
 URL: https://issues.apache.org/jira/browse/QPID-8301
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J
Reporter: Alex Rudyy
 Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3


Keystore certificate details like issue, serial number and validity period need 
to be exposed via management API and UI (similar the certificate details 
available for trust stores). This should help to get the information about 
intermediate certificates without the need to access broker configuration. It 
could useful, when broker configuration is not accessible.



--
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-8297) [Broker-J][Oracle Message Store] QPID_MESSAGE_CONTENT reserved space keeps growing until it reaches the limit and crashes

2019-04-10 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8297:
-
Status: Reviewable  (was: In Progress)

> [Broker-J][Oracle Message Store] QPID_MESSAGE_CONTENT reserved space keeps 
> growing until it reaches the limit and crashes
> -
>
> Key: QPID-8297
> URL: https://issues.apache.org/jira/browse/QPID-8297
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> Under a continuous high load, the Oracle message store crashes because the 
> reserved space for the table QPID_MESSAGE_CONTENT keeps on growing (even if 
> the table itself is empty since we consume as fast as we produce).
> This only happens for "big" messages (over 4KB) and comes from the way Oracle 
> handles the LOB types (content column is declared as a BLOB). For LOB values 
> over 4KB Oracle reserves some space in the table to handle the value but, by 
> default, it won't actually release it (even if the value is removed) before a 
> few hours.
> So when we have a high load of big messages that lasts a few hours we end up 
> reaching the max size of the tablespace and the database crashes...



--
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-8297) [Broker-J][Oracle Message Store] QPID_MESSAGE_CONTENT reserved space keeps growing until it reaches the limit and crashes

2019-04-10 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-8297.
--
Resolution: Fixed

> [Broker-J][Oracle Message Store] QPID_MESSAGE_CONTENT reserved space keeps 
> growing until it reaches the limit and crashes
> -
>
> Key: QPID-8297
> URL: https://issues.apache.org/jira/browse/QPID-8297
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> Under a continuous high load, the Oracle message store crashes because the 
> reserved space for the table QPID_MESSAGE_CONTENT keeps on growing (even if 
> the table itself is empty since we consume as fast as we produce).
> This only happens for "big" messages (over 4KB) and comes from the way Oracle 
> handles the LOB types (content column is declared as a BLOB). For LOB values 
> over 4KB Oracle reserves some space in the table to handle the value but, by 
> default, it won't actually release it (even if the value is removed) before a 
> few hours.
> So when we have a high load of big messages that lasts a few hours we end up 
> reaching the max size of the tablespace and the database crashes...



--
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-8297) [Broker-J][Oracle Message Store] QPID_MESSAGE_CONTENT reserved space keeps growing until it reaches the limit and crashes

2019-04-10 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8297:
-
Fix Version/s: qpid-java-broker-7.1.3
   qpid-java-broker-8.0.0

> [Broker-J][Oracle Message Store] QPID_MESSAGE_CONTENT reserved space keeps 
> growing until it reaches the limit and crashes
> -
>
> Key: QPID-8297
> URL: https://issues.apache.org/jira/browse/QPID-8297
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> Under a continuous high load, the Oracle message store crashes because the 
> reserved space for the table QPID_MESSAGE_CONTENT keeps on growing (even if 
> the table itself is empty since we consume as fast as we produce).
> This only happens for "big" messages (over 4KB) and comes from the way Oracle 
> handles the LOB types (content column is declared as a BLOB). For LOB values 
> over 4KB Oracle reserves some space in the table to handle the value but, by 
> default, it won't actually release it (even if the value is removed) before a 
> few hours.
> So when we have a high load of big messages that lasts a few hours we end up 
> reaching the max size of the tablespace and the database crashes...



--
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-8297) [Broker-J][Oracle Message Store] QPID_MESSAGE_CONTENT reserved space keeps growing until it reaches the limit and crashes

2019-04-10 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8297:


Assignee: Alex Rudyy

> [Broker-J][Oracle Message Store] QPID_MESSAGE_CONTENT reserved space keeps 
> growing until it reaches the limit and crashes
> -
>
> Key: QPID-8297
> URL: https://issues.apache.org/jira/browse/QPID-8297
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Critical
>
> Under a continuous high load, the Oracle message store crashes because the 
> reserved space for the table QPID_MESSAGE_CONTENT keeps on growing (even if 
> the table itself is empty since we consume as fast as we produce).
> This only happens for "big" messages (over 4KB) and comes from the way Oracle 
> handles the LOB types (content column is declared as a BLOB). For LOB values 
> over 4KB Oracle reserves some space in the table to handle the value but, by 
> default, it won't actually release it (even if the value is removed) before a 
> few hours.
> So when we have a high load of big messages that lasts a few hours we end up 
> reaching the max size of the tablespace and the database crashes...



--
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-8296) [JMS AMQP 0-x] Release 6.3.4 version of Qpid JMS client for AMQP 0-x

2019-04-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8296:
-
Summary: [JMS AMQP 0-x] Release 6.3.4 version of Qpid JMS client for AMQP 
0-x  (was: [JMS AMQP 0-x] Release 6.3.4 version of Qpid JMS client)

> [JMS AMQP 0-x] Release 6.3.4 version of Qpid JMS client for AMQP 0-x
> 
>
> Key: QPID-8296
> URL: https://issues.apache.org/jira/browse/QPID-8296
> Project: Qpid
>  Issue Type: Task
>  Components: JMS AMQP 0-x
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.4
>
>
> Release Qpid JMS AMQP 0-x client following instructions 
> [here|https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+JMS+AMQP+0-x]



--
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-8296) [JMS AMQP 0-x] Release 6.3.4 version of Qpid JMS client

2019-04-08 Thread Alex Rudyy (JIRA)
Alex Rudyy created QPID-8296:


 Summary: [JMS AMQP 0-x] Release 6.3.4 version of Qpid JMS client
 Key: QPID-8296
 URL: https://issues.apache.org/jira/browse/QPID-8296
 Project: Qpid
  Issue Type: Task
  Components: JMS AMQP 0-x
Reporter: Alex Rudyy
 Fix For: qpid-java-client-0-x-6.3.4


Release Qpid JMS AMQP 0-x client following instructions 
[here|https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+JMS+AMQP+0-x]



--
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-8282) [JMS AMQP 0-x] Java 11 build/runtime failure due to use of javax.xml.bind.DatatypeConverter

2019-04-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8282:
-
Fix Version/s: qpid-java-client-0-x-6.3.4

> [JMS AMQP 0-x] Java 11 build/runtime failure due to use of 
> javax.xml.bind.DatatypeConverter
> ---
>
> Key: QPID-8282
> URL: https://issues.apache.org/jira/browse/QPID-8282
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.3
>Reporter: Robbie Gemmell
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.4
>
>
> In setting up a new system, I happened to make attempt to build the JMS AMQP 
> 0-x client using Java 11. It failed to compile due to use of 
> javax.xml.bind.DatatypeConverter for Base64 handling in the SCRAM-SHA 
> mechanisms. This prevents building on Java 11, and would break use of 
> SCRAM-SHA while running on Java 11 assuming nothing else stopped things 
> working.
> Although the 0-x client is essentially in maintenance/legacy mode at this 
> point, blockers as trivial as Base 64 handling would be nice to resolved if 
> it made using Java 11 possible, if only to simplify migrations later.



--
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-8285) Deadlock during receiveMessage when broker connecton fails

2019-04-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8285:
-
Fix Version/s: qpid-java-client-0-x-6.3.4

> Deadlock during receiveMessage when broker connecton fails
> --
>
> Key: QPID-8285
> URL: https://issues.apache.org/jira/browse/QPID-8285
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
> Environment: * Java 1.8.0_20, 1.8.0_192, & 1.8.0_172
>  * Linux 4.9.0-4-amd64 & 3.10.0-327.13
>  * qpidd 1.39.0
>Reporter: Jonathan Beales
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.4
>
> Attachments: qpid_jms_deaklock.patch
>
>
> When a JMS MessageConsumer calls receiveMessage with a timeout, if no message 
> is received during the timeout, 
> BasicMessageConsumer_0_10.getMessageFromQueue() calls the syncDispatchQueue() 
> method.  As not the dispatcher thread, the consumer waits on a method local 
> CountDownLatch which should be decremented when the AMQSession.Dispatcher 
> thread calls dispatch().
> In the AMQSession.Dispatcher thread, the core loop will stop pulling from the 
> queue to dispatch messages when the connection to the broker is lost 
> (isClosing() becomes true).
> In this scenario, the receiveMessage call is waiting forever because the 
> Dispatcher will never call dispatch.  This also leaves the Dispatcher thread 
> in an infinite loop (using 100% CPU) waiting to be fully closed.
> This can fixed by allowing the AMQSession.Dispatcher to always dispatch 
> remaining queue content to ensure a consumer is not waiting forever (see 
> attached).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (QPID-8294) [Broker-J][Oracle Message Store] Batch delete fails for more than 1000 messages

2019-04-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8294:
-
Fix Version/s: qpid-java-broker-8.0.0

> [Broker-J][Oracle Message Store] Batch delete fails for more than 1000 
> messages
> ---
>
> Key: QPID-8294
> URL: https://issues.apache.org/jira/browse/QPID-8294
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.3
>
>
> When under high load, the Broker-J can end up having to delete more than 1000 
> messages in a single batch. But some databases (and Oracle in particular) put 
> a limit to the number of elements you can have in the IN clause. So we end up 
> with the following exception: ORA-01795: maximum number of expressions in a 
> list is 1000



--
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-8294) [Broker-J][Oracle Message Store] Batch delete fails for more than 1000 messages

2019-04-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-8294.
--
   Resolution: Fixed
Fix Version/s: qpid-java-broker-7.1.3

> [Broker-J][Oracle Message Store] Batch delete fails for more than 1000 
> messages
> ---
>
> Key: QPID-8294
> URL: https://issues.apache.org/jira/browse/QPID-8294
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.1.3
>
>
> When under high load, the Broker-J can end up having to delete more than 1000 
> messages in a single batch. But some databases (and Oracle in particular) put 
> a limit to the number of elements you can have in the IN clause. So we end up 
> with the following exception: ORA-01795: maximum number of expressions in a 
> list is 1000



--
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-8294) [Broker-J][Oracle Message Store] Batch delete fails for more than 1000 messages

2019-04-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8294:


Assignee: Alex Rudyy

> [Broker-J][Oracle Message Store] Batch delete fails for more than 1000 
> messages
> ---
>
> Key: QPID-8294
> URL: https://issues.apache.org/jira/browse/QPID-8294
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Critical
>
> When under high load, the Broker-J can end up having to delete more than 1000 
> messages in a single batch. But some databases (and Oracle in particular) put 
> a limit to the number of elements you can have in the IN clause. So we end up 
> with the following exception: ORA-01795: maximum number of expressions in a 
> list is 1000



--
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-8294) [Broker-J][Oracle Message Store] Batch delete fails for more than 1000 messages

2019-04-08 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8294:
-
Status: Reviewable  (was: In Progress)

> [Broker-J][Oracle Message Store] Batch delete fails for more than 1000 
> messages
> ---
>
> Key: QPID-8294
> URL: https://issues.apache.org/jira/browse/QPID-8294
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Olivier VERMEULEN
>Assignee: Alex Rudyy
>Priority: Critical
>
> When under high load, the Broker-J can end up having to delete more than 1000 
> messages in a single batch. But some databases (and Oracle in particular) put 
> a limit to the number of elements you can have in the IN clause. So we end up 
> with the following exception: ORA-01795: maximum number of expressions in a 
> list is 1000



--
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-8290) [Broker-J] Release Qpid Broker-J version 7.1.2

2019-04-05 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-8290.
--
Resolution: Fixed

> [Broker-J] Release Qpid Broker-J version 7.1.2
> --
>
> Key: QPID-8290
> URL: https://issues.apache.org/jira/browse/QPID-8290
> Project: Qpid
>  Issue Type: Task
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.2
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.2
>
>
> Release Qpid Broker-J version 7.1.2 following instructions at
> [https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J]



--
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-8281) [Broker-J] Regenerate test keystores and trustores containing RSA 1024bit keys

2019-04-05 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-8281.
--
Resolution: Fixed

> [Broker-J] Regenerate test keystores and trustores containing RSA 1024bit keys
> --
>
> Key: QPID-8281
> URL: https://issues.apache.org/jira/browse/QPID-8281
> Project: Qpid
>  Issue Type: Test
>  Components: Java Tests
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.2, 
> qpid-java-broker-7.0.8
>
>
> Unit and integration tests operating with pre-generated test key-stores are 
> failing with newer JDKs like openjdk-1.8.0.201.b09-2 due to deprecation of 
> RSA 1024bit keys:
> {noformat}
> Caused by: java.security.cert.CertPathValidatorException: Algorithm 
> constraints check failed on keysize limits. RSA 1024bit key used with 
> certificate: CN=MyRootCA, O=ACME, ST=Ontario, C=CA.  Usage was tls server
>   at 
> sun.security.util.DisabledAlgorithmConstraints$KeySizeConstraint.permits(DisabledAlgorithmConstraints.java:817)
>   at 
> sun.security.util.DisabledAlgorithmConstraints$Constraints.permits(DisabledAlgorithmConstraints.java:419)
>   at 
> sun.security.util.DisabledAlgorithmConstraints.permits(DisabledAlgorithmConstraints.java:167)
>   at 
> sun.security.provider.certpath.AlgorithmChecker.check(AlgorithmChecker.java:332)
>   at 
> sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1222)
> {noformat}
> Test kestores and key materials based on RSA 1024bit keys need to be 
> re-created with stronger RSA keys



--
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-8290) [Broker-J] Release Qpid Broker-J version 7.1.2

2019-04-05 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8290:
-
Status: Reviewable  (was: In Progress)

> [Broker-J] Release Qpid Broker-J version 7.1.2
> --
>
> Key: QPID-8290
> URL: https://issues.apache.org/jira/browse/QPID-8290
> Project: Qpid
>  Issue Type: Task
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.2
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.2
>
>
> Release Qpid Broker-J version 7.1.2 following instructions at
> [https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J]



--
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-8286) [Broker-J] Add operation into priority queue to change message priority

2019-04-05 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-8286.
--
Resolution: Fixed

> [Broker-J] Add operation into priority queue to change message priority
> ---
>
> Key: QPID-8286
> URL: https://issues.apache.org/jira/browse/QPID-8286
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.2
>
>
> The functionality to change message priority is required for some use case 
> scenarios involving priority queues. At the moment, in order to change the 
> priority, the messages need to be consumed (for example, using selector 
> 'JMSMessageID=ID:XYZ') and re-published with a different priority.  I 
> management operation can be introduced on the priority queue which can simply 
> dequeue the message and re-enqueue it with a provided priority.



--
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-8291) Inconsistent log level practices in source code

2019-03-31 Thread Alex Rudyy (JIRA)


[ 
https://issues.apache.org/jira/browse/QPID-8291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806273#comment-16806273
 ] 

Alex Rudyy commented on QPID-8291:
--

Thanks for reporting some inconsistency with logging of various exceptions in 
Qpid Broker-J and legacy JMS client for AMQP 0-x.  The Qpid Broker-J project 
source code should indeed have a more consistent exception logging.

As per your report #1  {{ReplicatedEnvironmentFacade}} has {{TimeoutException}} 
exception being reported with {{INFO}} log level in method 
{{ReplicatedEnvironmentFacade#submitEnvironmentTask}}. The method is used  to 
invoke operations on underlying instance of BDB JE {{Environment}}. Your 
pointed out that {{TimeoutException}} is logged with {{WARN}} level in method 
{{BDBHAVirtualHostNodeImpl#resolveFuture}} which is used to get  results for 
operations invoked on the same executor.  The handling of {{TimeoutException}} 
is indeed inconsistent here. Though, it might be more correct to re-throw the 
{{TimeoutException}} wrapped into business exception to let the caller know 
that operation has timed out. 

Your second report of inconsistency with logging of {{SQLException}} thrown 
from {{Connection#close}} is also valid. Though, log level {{WARN}} is more 
appropriate from my point of view, as broker does not need the connection being 
opened any-more. The broker closes it in order to release the resources 
associated with the connection on RDBMS side. The broker core functionality 
should not be affected and it can continue to operate. Though, it still would 
be useful to report the exception for further analysis using log level {{WARN}}.

In your third report I would prefer to use {{WARN}} log level on logging of 
exceptions thrown on various stream closes, as neither of those exceptions 
impacts broker or client core functionality.

The forth report is interesting. The exception {{InvalidNameException}} cannot 
be thrown in pointed code, as the name returned from {{X500Principal#getName()} 
is {{RFC2253}} compatible. It might be thrown if JVM is affected by the bug 
with generating of  RFC2253 compatible names. In this case, it would be better 
to upgrade or downgrade java to version not affected by the defect. Though, log 
level {{WARN}} looks more appropriate for me to use, as broker core 
functionality is not affected and it can continue to operate with plain non-TLS 
based connections.

Please note that you reported several orthogonal issues with inconsistent 
exception logging. Every of those issues deserves a separate JIRA. 

> Inconsistent log level practices in source code
> ---
>
> Key: QPID-8291
> URL: https://issues.apache.org/jira/browse/QPID-8291
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.7
>Reporter: Anuhan Torgonshar
>Priority: Major
>  Labels: easyfix
>
> Hi, 
> I found there are inconsistent log level practices in the Qpid project, and 
> we suspect some of them should be fixed.
> We select 4 problematic practices to report.
> The detail code as well as the modification suggestions are shown below.
> {code:java}
> * Report1 *
> the problematic snippet:
>  ReplicatedEnvironmentFacade.java ===
> file path: 
> qpid-java-6.1.7\bdbstore\src\main\java\org\apache\qpid\server\store\berkeleydb\replication\ReplicatedEnvironmentFacade.java
> logging statement line: 916
> modification suggestion: change log level to WARN
>  890 try
>  891 {
>  892 return future.get(timeout, TimeUnit.SECONDS);
>  893 }
>  894 catch (InterruptedException e)
>  895 {
>  896 Thread.currentThread().interrupt();
>  897 }
>  898 catch (ExecutionException e)
>  899 {
>  900 Throwable cause = e.getCause();
>  901 if (cause instanceof Error)
>  902 {
>  903 throw (Error) cause;
>  904 }
>  905 else if (cause instanceof RuntimeException)
>  906 {
>  907 throw (RuntimeException) cause;
>  908 }
>  909 else
>  910 {
>  911 throw new ConnectionScopedRuntimeException("Unexpected 
> exception while " + action, e);
>  912 }
>  913 }
>  914 catch (TimeoutException e)
>  915 {
>  916 LOGGER.info("{}  on {} timed out after {} seconds", action, 
> _prettyGroupNodeName, timeout);
>  917 }
> the similar snippet:
>  SelectorThread.java ===
> file path: 
> qpid-java-6.1.7\broker-core\src\main\java\org\apache\qpid\server\transport\SelectorThread.java
> logging statement line: 464
> 

[jira] [Assigned] (QPID-8290) [Broker-J] Release Qpid Broker-J version 7.1.2

2019-03-30 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8290:


Assignee: Alex Rudyy

> [Broker-J] Release Qpid Broker-J version 7.1.2
> --
>
> Key: QPID-8290
> URL: https://issues.apache.org/jira/browse/QPID-8290
> Project: Qpid
>  Issue Type: Task
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.2
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.2
>
>
> Release Qpid Broker-J version 7.1.2 following instructions at
> [https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J]



--
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-8281) [Broker-J] Regenerate test keystores and trustores containing RSA 1024bit keys

2019-03-29 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8281:
-
Status: Reviewable  (was: In Progress)

> [Broker-J] Regenerate test keystores and trustores containing RSA 1024bit keys
> --
>
> Key: QPID-8281
> URL: https://issues.apache.org/jira/browse/QPID-8281
> Project: Qpid
>  Issue Type: Test
>  Components: Java Tests
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.2, 
> qpid-java-broker-7.0.8
>
>
> Unit and integration tests operating with pre-generated test key-stores are 
> failing with newer JDKs like openjdk-1.8.0.201.b09-2 due to deprecation of 
> RSA 1024bit keys:
> {noformat}
> Caused by: java.security.cert.CertPathValidatorException: Algorithm 
> constraints check failed on keysize limits. RSA 1024bit key used with 
> certificate: CN=MyRootCA, O=ACME, ST=Ontario, C=CA.  Usage was tls server
>   at 
> sun.security.util.DisabledAlgorithmConstraints$KeySizeConstraint.permits(DisabledAlgorithmConstraints.java:817)
>   at 
> sun.security.util.DisabledAlgorithmConstraints$Constraints.permits(DisabledAlgorithmConstraints.java:419)
>   at 
> sun.security.util.DisabledAlgorithmConstraints.permits(DisabledAlgorithmConstraints.java:167)
>   at 
> sun.security.provider.certpath.AlgorithmChecker.check(AlgorithmChecker.java:332)
>   at 
> sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1222)
> {noformat}
> Test kestores and key materials based on RSA 1024bit keys need to be 
> re-created with stronger RSA keys



--
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-8290) [Broker-J] Release Qpid Broker-J version 7.1.2

2019-03-29 Thread Alex Rudyy (JIRA)
Alex Rudyy created QPID-8290:


 Summary: [Broker-J] Release Qpid Broker-J version 7.1.2
 Key: QPID-8290
 URL: https://issues.apache.org/jira/browse/QPID-8290
 Project: Qpid
  Issue Type: Task
  Components: Broker-J
Affects Versions: qpid-java-broker-7.1.2
Reporter: Alex Rudyy
 Fix For: qpid-java-broker-7.1.2


Release Qpid Broker-J version 7.1.2 following instructions at
[https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J]



--
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-8286) [Broker-J] Add operation into priority queue to change message priority

2019-03-29 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8286:
-
Status: Reviewable  (was: In Progress)

> [Broker-J] Add operation into priority queue to change message priority
> ---
>
> Key: QPID-8286
> URL: https://issues.apache.org/jira/browse/QPID-8286
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.2
>
>
> The functionality to change message priority is required for some use case 
> scenarios involving priority queues. At the moment, in order to change the 
> priority, the messages need to be consumed (for example, using selector 
> 'JMSMessageID=ID:XYZ') and re-published with a different priority.  I 
> management operation can be introduced on the priority queue which can simply 
> dequeue the message and re-enqueue it with a provided priority.



--
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-8286) [Broker-J] Add operation into priority queue to change message priority

2019-03-29 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8286:


Assignee: Alex Rudyy

> [Broker-J] Add operation into priority queue to change message priority
> ---
>
> Key: QPID-8286
> URL: https://issues.apache.org/jira/browse/QPID-8286
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.2
>
>
> The functionality to change message priority is required for some use case 
> scenarios involving priority queues. At the moment, in order to change the 
> priority, the messages need to be consumed (for example, using selector 
> 'JMSMessageID=ID:XYZ') and re-published with a different priority.  I 
> management operation can be introduced on the priority queue which can simply 
> dequeue the message and re-enqueue it with a provided priority.



--
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-8286) [Broker-J] Add operation into priority queue to change message priority

2019-03-26 Thread Alex Rudyy (JIRA)


[ 
https://issues.apache.org/jira/browse/QPID-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802327#comment-16802327
 ] 

Alex Rudyy commented on QPID-8286:
--

[~rgodfrey], I finally found some time to implement my ideas about changing 
message priority. In PR22 I added 2 operations into priority queue : 
{{reenqueueMessageForPriorityChange}} and 
{{reenqueueMessagesForPriorityChange}}. In both operations the messages(s) are 
replaced with new ones having given priority. I am planning to merge the 
changes into 7.1.x and spin 7.1.2 release.

> [Broker-J] Add operation into priority queue to change message priority
> ---
>
> Key: QPID-8286
> URL: https://issues.apache.org/jira/browse/QPID-8286
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.2
>
>
> The functionality to change message priority is required for some use case 
> scenarios involving priority queues. At the moment, in order to change the 
> priority, the messages need to be consumed (for example, using selector 
> 'JMSMessageID=ID:XYZ') and re-published with a different priority.  I 
> management operation can be introduced on the priority queue which can simply 
> dequeue the message and re-enqueue it with a provided priority.



--
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-8289) [Broker-J] Broker startup can fail due to ConcurrentModificationException

2019-03-26 Thread Alex Rudyy (JIRA)
Alex Rudyy created QPID-8289:


 Summary: [Broker-J] Broker startup can fail due to 
ConcurrentModificationException
 Key: QPID-8289
 URL: https://issues.apache.org/jira/browse/QPID-8289
 Project: Qpid
  Issue Type: Bug
  Components: Broker-J
Affects Versions: qpid-java-broker-7.1.1
Reporter: Alex Rudyy


The startup can fail with the following exception
{noformat}
ERROR [VirtualHostNode-default-Config] (o.a.q.s.m.AbstractConfiguredObject) - 
Failed to open object with name 'default'.  Object will be put into ERROR state.
org.apache.qpid.server.configuration.IllegalConfigurationException: Cannot open 
virtual host message store:null
at 
org.apache.qpid.server.virtualhost.AbstractVirtualHost.validateMessageStoreCreation(AbstractVirtualHost.java:563)
at 
org.apache.qpid.server.virtualhost.AbstractVirtualHost.onValidate(AbstractVirtualHost.java:398)
at 
org.apache.qpid.server.model.AbstractConfiguredObject.doValidation(AbstractConfiguredObject.java:1205)
at 
org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:589)
at 
org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:578)
at 
org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:639)
at 
org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:632)
at 
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:248)
at 
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:320)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at 
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper.call(TaskExecutorImpl.java:313)
at 
com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:125)
at 
com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:57)
at 
com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:78)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at 
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.util.ConcurrentModificationException: null
at java.util.Hashtable$Enumerator.next(Hashtable.java:1383)
at java.util.HashMap.putMapEntries(HashMap.java:512)
at java.util.HashMap.putAll(HashMap.java:785)
at 
org.apache.qpid.server.model.AbstractConfiguredObject.getContextKeys(AbstractConfiguredObject.java:3508)
at 
org.apache.qpid.server.store.berkeleydb.BDBUtils.getContextSettingsWithNameMatchingRegExpPattern(BDBUtils.java:130)
at 
org.apache.qpid.server.store.berkeleydb.BDBUtils.getEnvironmentConfigurationParameters(BDBUtils.java:119)
at 
org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacadeFactory$1.getParameters(StandardEnvironmentFacadeFactory.java:73)
at 
org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacade.(StandardEnvironmentFacade.java:116)
at 
org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacadeFactory.createEnvironmentFacade(StandardEnvironmentFacadeFactory.java:89)
at 
org.apache.qpid.server.store.berkeleydb.BDBMessageStore.doOpen(BDBMessageStore.java:57)
at 
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.openMessageStore(AbstractBDBMessageStore.java:131)
at 
org.apache.qpid.server.virtualhost.AbstractVirtualHost.validateMessageStoreCreation(AbstractVirtualHost.java:559)
... 18 common frames omitted
{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-8286) [Broker-J] Add operation into priority queue to change message priority

2019-03-15 Thread Alex Rudyy (JIRA)


[ 
https://issues.apache.org/jira/browse/QPID-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16793695#comment-16793695
 ] 

Alex Rudyy commented on QPID-8286:
--

[~rgodfrey], ideally, it is expected that new functionality should  allow to 
change message priority (increase it) in order to process it faster due to big 
backlog of messages waiting for processing. How it is implemented and what 
priority client would see, it is up to the implementation. Here are my thoughts 
how this can be achieved
* within virtualhost transaction
** find the message (either using selector or id)
** acquire the message to prevent its consumption (if message is already 
acquired by either consumer or other operation, abort the operation)
** dequeue the message
** create new message from original one but set priority to desired value
** enqueue new message
* commit transaction

Thus, the operation will remove the original message and enqueue a new one. 
Thus, the consumer would see completely new message with new priority, new 
message id and new message timestamp.
Perhaps, the operation would be better named 
{{replaceMessageWithNewOneHavingDifferentPriority}} :)

At the moment, the need for this functionality is in a process of discussion. 
As it would introduce a vendor locking to Qpid for the application. Though, 
ArtemisMQ, ActiveMQ already have operations for changing message priorities. 
RabbitMQ, Solace, IBM MQ do not have such functionality.


> [Broker-J] Add operation into priority queue to change message priority
> ---
>
> Key: QPID-8286
> URL: https://issues.apache.org/jira/browse/QPID-8286
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.2
>
>
> The functionality to change message priority is required for some use case 
> scenarios involving priority queues. At the moment, in order to change the 
> priority, the messages need to be consumed (for example, using selector 
> 'JMSMessageID=ID:XYZ') and re-published with a different priority.  I 
> management operation can be introduced on the priority queue which can simply 
> dequeue the message and re-enqueue it with a provided priority.



--
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-8286) [Broker-J] Add operation into priority queue to change message priority

2019-03-15 Thread Alex Rudyy (JIRA)
Alex Rudyy created QPID-8286:


 Summary: [Broker-J] Add operation into priority queue to change 
message priority
 Key: QPID-8286
 URL: https://issues.apache.org/jira/browse/QPID-8286
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J
Reporter: Alex Rudyy
 Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.2


The functionality to change message priority is required for some use case 
scenarios involving priority queues. At the moment, in order to change the 
priority, the messages need to be consumed (for example, using selector 
'JMSMessageID=ID:XYZ') and re-published with a different priority.  I 
management operation can be introduced on the priority queue which can simply 
dequeue the message and re-enqueue it with a provided priority.



--
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-8259) [Broker-J] Upgrade Jetty to version 9.4.12.v20180830

2019-03-11 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8259:
-
Fix Version/s: qpid-java-broker-7.0.7

> [Broker-J] Upgrade Jetty to version 9.4.12.v20180830
> 
>
> Key: QPID-8259
> URL: https://issues.apache.org/jira/browse/QPID-8259
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
>
> A number of security vulnerabilities have been reported against version in 
> use. See 
> [https://www.eclipse.org/jetty/documentation/9.4.x/security-reports.html]
> ||/mm/dd||ID  ||Exploitable|| Severity||  Affects||   
> Fixed Version|| Comment||
> |2018/06/25|CVE-2018-12538|High|High|>= 9.4.0, < = 9.4.8|9.4.9|HttpSessions 
> present specifically in the FileSystem’s storage could be hijacked/accessed 
> by an unauthorized user.|
> |2018/06/25|CVE-2018-12536|High|See CWE-202|< = 9.4.10|9.2.25, 9.3.24, 
> 9.4.11|InvalidPathException Message reveals webapp system path.|
> |2018/06/25|CVE-2017-7658|See CWE-444|See CWE-444|< = 9.4.10|9.2.25, 9.3.24, 
> 9.4.11|Too Tolerant Parser, Double Content-Length + Transfer-Encoding + 
> Whitespace.|
> |2018/06/25|CVE-2017-7657|See CWE-444|See CWE-444|< = 9.4.10|9.2.25, 9.3.24, 
> 9.4.11|HTTP/1.1 Request smuggling with carefully crafted body content (Does 
> not apply to HTTP/1.0 or HTTP/2).|
> |2018/06/25|CVE-2017-7656|See CWE-444|See CWE-444|< = 9.4.10|9.2.25, 9.3.24, 
> 9.4.11|HTTP Request Smuggling when used with invalid request headers (for 
> HTTP/0.9).|



--
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-8284) [Broker-J] Move remaining classes for AMQP protocols 0-8..0-91 from qpid-broker-core into plugin module qpid-broker-plugins-amqp-0-8-protocol

2019-03-07 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8284:
-
Status: Reviewable  (was: In Progress)

> [Broker-J] Move remaining classes for AMQP protocols 0-8..0-91 from 
> qpid-broker-core into plugin module qpid-broker-plugins-amqp-0-8-protocol
> -
>
> Key: QPID-8284
> URL: https://issues.apache.org/jira/browse/QPID-8284
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-broker-8.0.0
>
>
> A number of AMQP 0-8..0-91 specific classes (like FieldTable, FieldArray, 
> etc) are still present in the qpid-broker-core. They need to be moved into 
> corresponding protocol plugin module - qpid-broker-plugins-amqp-0-8-protocol.



--
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-8007) [Broker-J, WMC] Sometime the Buttons to create Dashboards and Queries stop working

2019-03-07 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8007:
-
Component/s: Broker-J

> [Broker-J, WMC] Sometime the Buttons to create Dashboards and Queries stop 
> working
> --
>
> Key: QPID-8007
> URL: https://issues.apache.org/jira/browse/QPID-8007
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Lorenz Quack
>Priority: Major
>
> So far I could not figure out the exact circumstances when this happens but 
> sometimes the Buttons in the Web management console to create new dashboards 
> and new queries stoip working. Clicking on them has no apparent effect. The 
> expected dialogue does not pop up and the browser's development tools show no 
> output on the console and no network activity. This happened on IE 11 and FF 
> 45.8.
> In one instance using the browser's debugger it appeared as if the code 
> inside the {{ready}} call in ConsoleHelper.js:94 was never executed (as if 
> the QueryCreateDialogForm DOM element never became ready).
> Reloading the page resolves the issue.



--
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-8235) [Broker-J] Broker should delay opening/closing connections to virtual hosts which are still activating

2019-03-07 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8235:
-
Component/s: Broker-J

> [Broker-J] Broker should delay opening/closing connections to virtual hosts 
> which are still activating
> --
>
> Key: QPID-8235
> URL: https://issues.apache.org/jira/browse/QPID-8235
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Rob Godfrey
>Priority: Major
>
> Currently when a client attempts to connect to a virtual host which is still 
> activating then the connection is immediately closed.  Instead the broker 
> should distinguish between hosts which are in the process of activating, and 
> those that are in a more long term non-active state.  Where the virtualhost 
> is still activating, the broker should not immediately respond, but instead 
> defer any further action until the activation has completed.



--
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-8284) [Broker-J] Move remaining classes for AMQP protocols 0-8..0-91 from qpid-broker-core into plugin module qpid-broker-plugins-amqp-0-8-protocol

2019-03-07 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-8284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8284:


Assignee: Alex Rudyy

> [Broker-J] Move remaining classes for AMQP protocols 0-8..0-91 from 
> qpid-broker-core into plugin module qpid-broker-plugins-amqp-0-8-protocol
> -
>
> Key: QPID-8284
> URL: https://issues.apache.org/jira/browse/QPID-8284
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-broker-8.0.0
>
>
> A number of AMQP 0-8..0-91 specific classes (like FieldTable, FieldArray, 
> etc) are still present in the qpid-broker-core. They need to be moved into 
> corresponding protocol plugin module - qpid-broker-plugins-amqp-0-8-protocol.



--
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-8284) [Broker-J] Move remaining classes for AMQP protocols 0-8..0-91 from qpid-broker-core into plugin module qpid-broker-plugins-amqp-0-8-protocol

2019-03-07 Thread Alex Rudyy (JIRA)
Alex Rudyy created QPID-8284:


 Summary: [Broker-J] Move remaining classes for AMQP protocols 
0-8..0-91 from qpid-broker-core into plugin module 
qpid-broker-plugins-amqp-0-8-protocol
 Key: QPID-8284
 URL: https://issues.apache.org/jira/browse/QPID-8284
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J
Reporter: Alex Rudyy
 Fix For: qpid-java-broker-8.0.0


A number of AMQP 0-8..0-91 specific classes (like FieldTable, FieldArray, etc) 
are still present in the qpid-broker-core. They need to be moved into 
corresponding protocol plugin module - qpid-broker-plugins-amqp-0-8-protocol.




--
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] [Closed] (QPID-7747) Logging: Depend only on slf4j and remove logback dependencies

2019-03-07 Thread Alex Rudyy (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy closed QPID-7747.

Resolution: Not A Problem

> Logging: Depend only on slf4j and remove logback dependencies
> -
>
> Key: QPID-7747
> URL: https://issues.apache.org/jira/browse/QPID-7747
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Tomas Klimavicius
>Priority: Major
> Attachments: embedded-broker-example.tar.gz
>
>
> Qpid is depending on logback as it's log implementation, but this makes it 
> horrible to use inside projects that already use log4j or slf4j-jdk14.
> It would be much easier for users if the source code would only depened on 
> slf4j. Now if we exclude logback and expect qpid to use our provided logger 
> the code does not compile since qpid actually depends on logback - 
> ch.qos.logback.classic.Logger logger = 
> (ch.qos.logback.classic.Logger)LoggerFactory.getLogger("ROOT");
> And if you use something else you get a class cast exception. 
> Also slf4j complains on every startup when you have multiple implementations 
> in your classpath



--
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



  1   2   3   4   5   6   7   8   9   10   >