[jira] [Commented] (DISPATCH-390) New pn_proactor-based IO driver

[Jiri Danek (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16007185#comment-16007185
 ] 

Jiri Danek commented on DISPATCH-390:
-

When I compiled Dispatch now, the unit-tests failed for me, in two cases it is 
on asserts in Proton (I have -DCMAKE_BUILD_TYPE=Debug for both qpid-proton 
build and qpid-dispatch build). The relevant logs are below

{noformat}
Errors while running CTest

91% tests passed, 3 tests failed out of 33

Total Test time (real) = 397.63 sec

The following tests FAILED:
 14 - system_tests_autolinks (Failed)
 19 - system_tests_protocol_family (Failed)
 23 - system_tests_sasl_plain (Failed)
The command '/bin/sh -c ctest -VV' returned a non-zero code: 8
{noformat}

{noformat}
14: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" "-m" 
"unittest" "-v" "system_tests_autolinks"
14: Test timeout computed to be: 1500
14: test_01_autolink_attach (system_tests_autolinks.AutolinkTest) ... ok
14: test_02_autolink_credit (system_tests_autolinks.AutolinkTest) ... FAIL
14: test_03_autolink_sender (system_tests_autolinks.AutolinkTest) ... ok
14: test_04_autolink_receiver (system_tests_autolinks.AutolinkTest) ... ok
14: test_05_inter_container_transfer (system_tests_autolinks.AutolinkTest) ... 
ok
14: test_06_manage_autolinks (system_tests_autolinks.AutolinkTest) ... 
ERROR:root:Connectivity to the peer container was lost
14: ERROR:root:Connectivity to the peer container was lost
14: ERROR:root:Connectivity to the peer container was lost
14: ERROR:root:Connectivity to the peer container was lost
14: ERROR:root:Connectivity to the peer container was lost
14: ok
14: test_07_autolink_attach_with_ext_addr (system_tests_autolinks.AutolinkTest) 
... ok
14: test_08_autolink_sender_with_ext_addr (system_tests_autolinks.AutolinkTest) 
... ok
14: test_09_autolink_receiver_with_ext_addr 
(system_tests_autolinks.AutolinkTest) ... ok
14: 
14: ==
14: FAIL: test_02_autolink_credit (system_tests_autolinks.AutolinkTest)
14: --
14: Traceback (most recent call last):
14:   File "/main/qpid-dispatch/tests/system_tests_autolinks.py", line 95, in 
test_02_autolink_credit
14: self.assertEqual(None, test.error)
14: AssertionError: None != 'Timeout Expired: last_action=Opened route 
connection'
14: 
14: --
14: Ran 9 tests in 60.721s
14: 
14: FAILED (failures=1)
14/33 Test #14: system_tests_autolinks ***Failed   60.77 sec
test 15
  Start 15: system_tests_drain
{noformat}

{noformat}
19: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" "-m" 
"unittest" "-v" "system_tests_protocol_family"
19: Test timeout computed to be: 1500
19: test_simple_pre_settled (system_tests_protocol_family.ProtocolFamilyTest) 
... ok
19: ERROR
19: 
19: ==
19: ERROR: tearDownClass (system_tests_protocol_family.ProtocolFamilyTest)
19: --
19: Traceback (most recent call last):
19:   File "/main/qpid-dispatch/tests/system_test.py", line 605, in 
tearDownClass
19: cls.tester.teardown()
19:   File "/main/qpid-dispatch/tests/system_test.py", line 543, in teardown
19: raise RuntimeError("Errors during teardown: \n\n%s" % 
"\n\n".join([str(e) for e in errors]))
19: RuntimeError: Errors during teardown: 
19: 
19: Process 274 error: exit code -6, expected -1
19: qdrouterd -c B.conf -I /main/qpid-dispatch/python
19: 
/main/qpid-dispatch/build/tests/system_test.dir/system_tests_protocol_family/ProtocolFamilyTest/setUpClass/B-2.cmd
19: 
19: qdrouterd: /main/qpid-proton/proton-c/src/proactor/epoll.c:169: 
ptimer_callback: Assertion `l == sizeof(uint64_t)' failed.
19: 
19: 
19: --
19: Ran 1 test in 180.492s
19: 
19: FAILED (errors=1)
19/33 Test #19: system_tests_protocol_family ..***Failed  180.54 sec
test 20
  Start 20: system_tests_protocol_settings
{noformat}

{noformat}
23: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" "-m" 
"unittest" "-v" "system_tests_sasl_plain"
23: Test timeout computed to be: 1500
23: test_inter_router_plain_exists 
(system_tests_sasl_plain.RouterTestPlainSasl) ... ok
23: test_qdstat_connect_sasl (system_tests_sasl_plain.RouterTestPlainSasl) ... 
ok
23: test_qdstat_connect_sasl_password_file 
(system_tests_sasl_plain.RouterTestPlainSasl) ... ok
23: test_aaa_qdstat_connect_sasl_over_ssl 
(system_tests_sasl_plain.RouterTestPlainSaslOverSsl) ... ok
23: test_inter_router_plain_over_ssl_exists 
(system_tests_sasl_plain.RouterTestPlainSaslOverSsl)
23: The setUpClass sets up two routers with 

[jira] [Commented] (DISPATCH-390) New pn_proactor-based IO driver

[Adel Boutros (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16007064#comment-16007064
 ] 

Adel Boutros commented on DISPATCH-390:
---

Great job!! Can't wait to test it :)

> New pn_proactor-based IO driver
> ---
>
> Key: DISPATCH-390
> URL: https://issues.apache.org/jira/browse/DISPATCH-390
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Container
>Affects Versions: 0.6.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 1.0.0
>
>
> Replace the current proton IO driver with a driver based on the pn_proactor 
> API. This will allow drop-in replacement of the IO layer for different 
> platforms.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (DISPATCH-390) New pn_proactor-based IO driver

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-390:
--
Fix Version/s: (was: 1.1.0)
   1.0.0

> New pn_proactor-based IO driver
> ---
>
> Key: DISPATCH-390
> URL: https://issues.apache.org/jira/browse/DISPATCH-390
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Container
>Affects Versions: 0.6.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 1.0.0
>
>
> Replace the current proton IO driver with a driver based on the pn_proactor 
> API. This will allow drop-in replacement of the IO layer for different 
> platforms.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (DISPATCH-390) New pn_proactor-based IO driver

[Alan Conway (JIRA)]

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

Alan Conway resolved DISPATCH-390.
--
   Resolution: Fixed
Fix Version/s: 1.1.0

> New pn_proactor-based IO driver
> ---
>
> Key: DISPATCH-390
> URL: https://issues.apache.org/jira/browse/DISPATCH-390
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Container
>Affects Versions: 0.6.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 1.1.0
>
>
> Replace the current proton IO driver with a driver based on the pn_proactor 
> API. This will allow drop-in replacement of the IO layer for different 
> platforms.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[GitHub] qpid-jms pull request #7: Client+Server class additions - updated

[gemmellr]

Github user gemmellr commented on a diff in the pull request:

https://github.com/apache/qpid-jms/pull/7#discussion_r116052679
  
--- Diff: 
qpid-jms-examples/src/main/java/org/apache/qpid/jms/example/Client.java ---
@@ -0,0 +1,106 @@
+/*
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ *
+ */
+package org.apache.qpid.jms.example;
+
+import javax.jms.Connection;
+import javax.jms.ConnectionFactory;
+import javax.jms.DeliveryMode;
+import javax.jms.Destination;
+import javax.jms.ExceptionListener;
+import javax.jms.JMSException;
+import javax.jms.Message;
+import javax.jms.MessageConsumer;
+import javax.jms.MessageProducer;
+import javax.jms.Session;
+import javax.jms.TemporaryQueue;
+import javax.jms.TextMessage;
+import javax.naming.Context;
+import javax.naming.InitialContext;
+
+public class Client {
+private static final int DELIVERY_MODE = DeliveryMode.NON_PERSISTENT;
+
+public static void main(String[] args) throws Exception {
+try {
+// The configuration for the Qpid InitialContextFactory has 
been supplied in
+// a jndi.properties file in the classpath, which results in 
it being picked
+// up automatically by the InitialContext constructor.
+Context context = new InitialContext();
+
+ConnectionFactory factory = (ConnectionFactory) 
context.lookup("myFactoryLookup");
+Destination queue = (Destination) 
context.lookup("myQueueLookup");
+
+Connection connection = 
factory.createConnection(System.getProperty("USER"), 
System.getProperty("PASSWORD"));
+connection.setExceptionListener(new MyExceptionListener());
+connection.start();
+
+Session session = connection.createSession(false, 
Session.AUTO_ACKNOWLEDGE);
+
+//Creates a message and temporary queue to send to and from.
+int random = (int) (Math.random()*3);
+TextMessage messageToBeSent;
+if (random == 0) {
+messageToBeSent = session.createTextMessage("first example 
message");
+} else if (random == 1) {
+messageToBeSent = session.createTextMessage("second 
example message");
+} else {
+messageToBeSent = session.createTextMessage("third example 
message");
+}
+
+TemporaryQueue tempQueue = session.createTemporaryQueue();
+messageToBeSent.setJMSReplyTo(tempQueue);
+MessageProducer messageProducer = 
session.createProducer(queue);
+
+//Send the message
+messageProducer.send(messageToBeSent, DELIVERY_MODE, 
Message.DEFAULT_PRIORITY, Message.DEFAULT_TIME_TO_LIVE);
+System.out.println("[CLIENT] The message with text \"" + 
messageToBeSent.getText() +"\" has been sent.");
+
+MessageConsumer messageConsumer = 
session.createConsumer(tempQueue);
+
+//Receive the server response
+TextMessage receivedMessage = (TextMessage) 
messageConsumer.receive(1000);
+if (receivedMessage != null) {
+System.out.println("[CLIENT] Response from server 
received.");
+} else {
+System.out.println("[CLIENT] Response not received within 
timeout, stopping.");
+}
+
+//Display response and close client.
+System.out.println("[CLIENT] Here is the interpreted 
message:\n" + receivedMessage.getText() + "\n[CLIENT] Quitting Client.");
+connection.close();
+System.exit(1);
--- End diff --

The exit call should be removed. It is signalling an error return code when 
everything actually went ok. The example will exit itself naturally once the 
connection is closed.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as 

[GitHub] qpid-jms pull request #7: Client+Server class additions - updated

[gemmellr]

Github user gemmellr commented on a diff in the pull request:

https://github.com/apache/qpid-jms/pull/7#discussion_r116064745
  
--- Diff: 
qpid-jms-examples/src/main/java/org/apache/qpid/jms/example/Server.java ---
@@ -0,0 +1,94 @@
+/*
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ *
+ */
+package org.apache.qpid.jms.example;
+
+import javax.jms.Connection;
+import javax.jms.ConnectionFactory;
+import javax.jms.DeliveryMode;
+import javax.jms.Destination;
+import javax.jms.ExceptionListener;
+import javax.jms.JMSException;
+import javax.jms.Message;
+import javax.jms.MessageConsumer;
+import javax.jms.MessageProducer;
+import javax.jms.Session;
+import javax.jms.TextMessage;
+import javax.jms.ObjectMessage;
+import javax.naming.Context;
+import javax.naming.InitialContext;
+import java.util.ArrayList;
+import java.util.Collections;
+
+public class Server {
+public static void main(String[] args) throws Exception {
+   try {
--- End diff --

The try block and its contents are indented an extra level than it should 
be. Your editor should be able to fix the indent. Feel free to grab me on IRC 
for assistance if needed.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] qpid-jms pull request #7: Client+Server class additions - updated

[gemmellr]

Github user gemmellr commented on a diff in the pull request:

https://github.com/apache/qpid-jms/pull/7#discussion_r116048356
  
--- Diff: 
qpid-jms-examples/src/main/java/org/apache/qpid/jms/example/Client.java ---
@@ -0,0 +1,106 @@
+/*
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ *
+ */
+package org.apache.qpid.jms.example;
+
+import javax.jms.Connection;
+import javax.jms.ConnectionFactory;
+import javax.jms.DeliveryMode;
+import javax.jms.Destination;
+import javax.jms.ExceptionListener;
+import javax.jms.JMSException;
+import javax.jms.Message;
+import javax.jms.MessageConsumer;
+import javax.jms.MessageProducer;
+import javax.jms.Session;
+import javax.jms.TemporaryQueue;
+import javax.jms.TextMessage;
+import javax.naming.Context;
+import javax.naming.InitialContext;
+
+public class Client {
+private static final int DELIVERY_MODE = DeliveryMode.NON_PERSISTENT;
+
+public static void main(String[] args) throws Exception {
+try {
+// The configuration for the Qpid InitialContextFactory has 
been supplied in
+// a jndi.properties file in the classpath, which results in 
it being picked
+// up automatically by the InitialContext constructor.
+Context context = new InitialContext();
+
+ConnectionFactory factory = (ConnectionFactory) 
context.lookup("myFactoryLookup");
+Destination queue = (Destination) 
context.lookup("myQueueLookup");
+
+Connection connection = 
factory.createConnection(System.getProperty("USER"), 
System.getProperty("PASSWORD"));
+connection.setExceptionListener(new MyExceptionListener());
+connection.start();
+
+Session session = connection.createSession(false, 
Session.AUTO_ACKNOWLEDGE);
+
+//Creates a message and temporary queue to send to and from.
+int random = (int) (Math.random()*3);
+TextMessage messageToBeSent;
+if (random == 0) {
+messageToBeSent = session.createTextMessage("first example 
message");
+} else if (random == 1) {
+messageToBeSent = session.createTextMessage("second 
example message");
+} else {
+messageToBeSent = session.createTextMessage("third example 
message");
+}
+
+TemporaryQueue tempQueue = session.createTemporaryQueue();
+messageToBeSent.setJMSReplyTo(tempQueue);
+MessageProducer messageProducer = 
session.createProducer(queue);
+
+//Send the message
+messageProducer.send(messageToBeSent, DELIVERY_MODE, 
Message.DEFAULT_PRIORITY, Message.DEFAULT_TIME_TO_LIVE);
+System.out.println("[CLIENT] The message with text \"" + 
messageToBeSent.getText() +"\" has been sent.");
+
+MessageConsumer messageConsumer = 
session.createConsumer(tempQueue);
+
+//Receive the server response
+TextMessage receivedMessage = (TextMessage) 
messageConsumer.receive(1000);
+if (receivedMessage != null) {
+System.out.println("[CLIENT] Response from server 
received.");
+} else {
+System.out.println("[CLIENT] Response not received within 
timeout, stopping.");
+}
+
+//Display response and close client.
+System.out.println("[CLIENT] Here is the interpreted 
message:\n" + receivedMessage.getText() + "\n[CLIENT] Quitting Client.");
--- End diff --

I'd probably just print a single line showing the response text, and 
optionally the request text. E.g. other exampels show a line with "\  --> \" style output.

I suggested a loop above to send multiple requests. You could also put the 
receive call in the loop, and that way it would act as more of a synchronous 
send-request ->receive-response 

[GitHub] qpid-jms pull request #7: Client+Server class additions - updated

[gemmellr]

Github user gemmellr commented on a diff in the pull request:

https://github.com/apache/qpid-jms/pull/7#discussion_r116053494
  
--- Diff: 
qpid-jms-examples/src/main/java/org/apache/qpid/jms/example/Client.java ---
@@ -0,0 +1,106 @@
+/*
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ *
+ */
+package org.apache.qpid.jms.example;
+
+import javax.jms.Connection;
+import javax.jms.ConnectionFactory;
+import javax.jms.DeliveryMode;
+import javax.jms.Destination;
+import javax.jms.ExceptionListener;
+import javax.jms.JMSException;
+import javax.jms.Message;
+import javax.jms.MessageConsumer;
+import javax.jms.MessageProducer;
+import javax.jms.Session;
+import javax.jms.TemporaryQueue;
+import javax.jms.TextMessage;
+import javax.naming.Context;
+import javax.naming.InitialContext;
+
+public class Client {
+private static final int DELIVERY_MODE = DeliveryMode.NON_PERSISTENT;
+
+public static void main(String[] args) throws Exception {
+try {
+// The configuration for the Qpid InitialContextFactory has 
been supplied in
+// a jndi.properties file in the classpath, which results in 
it being picked
+// up automatically by the InitialContext constructor.
+Context context = new InitialContext();
+
+ConnectionFactory factory = (ConnectionFactory) 
context.lookup("myFactoryLookup");
+Destination queue = (Destination) 
context.lookup("myQueueLookup");
+
+Connection connection = 
factory.createConnection(System.getProperty("USER"), 
System.getProperty("PASSWORD"));
+connection.setExceptionListener(new MyExceptionListener());
+connection.start();
+
+Session session = connection.createSession(false, 
Session.AUTO_ACKNOWLEDGE);
+
+//Creates a message and temporary queue to send to and from.
+int random = (int) (Math.random()*3);
+TextMessage messageToBeSent;
+if (random == 0) {
+messageToBeSent = session.createTextMessage("first example 
message");
+} else if (random == 1) {
+messageToBeSent = session.createTextMessage("second 
example message");
+} else {
+messageToBeSent = session.createTextMessage("third example 
message");
+}
+
+TemporaryQueue tempQueue = session.createTemporaryQueue();
+messageToBeSent.setJMSReplyTo(tempQueue);
+MessageProducer messageProducer = 
session.createProducer(queue);
+
+//Send the message
+messageProducer.send(messageToBeSent, DELIVERY_MODE, 
Message.DEFAULT_PRIORITY, Message.DEFAULT_TIME_TO_LIVE);
+System.out.println("[CLIENT] The message with text \"" + 
messageToBeSent.getText() +"\" has been sent.");
+
+MessageConsumer messageConsumer = 
session.createConsumer(tempQueue);
--- End diff --

It would be better to move creation of the consumer on the response queue 
up to before sending any request, to ensure there is a listener ready for the 
message. It often wont matter, but there are some select cases it does so its 
best to have the examples show that.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] qpid-jms pull request #7: Client+Server class additions - updated

[gemmellr]

Github user gemmellr commented on a diff in the pull request:

https://github.com/apache/qpid-jms/pull/7#discussion_r116057472
  
--- Diff: 
qpid-jms-examples/src/main/java/org/apache/qpid/jms/example/Client.java ---
@@ -0,0 +1,106 @@
+/*
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ *
+ */
+package org.apache.qpid.jms.example;
+
+import javax.jms.Connection;
+import javax.jms.ConnectionFactory;
+import javax.jms.DeliveryMode;
+import javax.jms.Destination;
+import javax.jms.ExceptionListener;
+import javax.jms.JMSException;
+import javax.jms.Message;
+import javax.jms.MessageConsumer;
+import javax.jms.MessageProducer;
+import javax.jms.Session;
+import javax.jms.TemporaryQueue;
+import javax.jms.TextMessage;
+import javax.naming.Context;
+import javax.naming.InitialContext;
+
+public class Client {
+private static final int DELIVERY_MODE = DeliveryMode.NON_PERSISTENT;
+
+public static void main(String[] args) throws Exception {
+try {
+// The configuration for the Qpid InitialContextFactory has 
been supplied in
+// a jndi.properties file in the classpath, which results in 
it being picked
+// up automatically by the InitialContext constructor.
+Context context = new InitialContext();
+
+ConnectionFactory factory = (ConnectionFactory) 
context.lookup("myFactoryLookup");
+Destination queue = (Destination) 
context.lookup("myQueueLookup");
+
+Connection connection = 
factory.createConnection(System.getProperty("USER"), 
System.getProperty("PASSWORD"));
+connection.setExceptionListener(new MyExceptionListener());
+connection.start();
+
+Session session = connection.createSession(false, 
Session.AUTO_ACKNOWLEDGE);
+
+//Creates a message and temporary queue to send to and from.
--- End diff --

Following the other examples would be better here, increasing consistency 
between them and serving to demonstrate sending multiple requests with the same 
producer as would typically be done. For example:
```
String[] requests = new String[] { "Twas brillig, and the slithy toves",
"Did gire and gymble in the wabe.",
"All mimsy were the borogroves,",
"And the mome raths outgrabe." };

for (String request : requests) {
TextMessage requestMessage = session.createTextMessage(request);
requestMessage.setJMSReplyTo(replyToQueue);

messageProducer.send(requestMessage, DeliveryMode.NON_PERSISTENT, 
Message.DEFAULT_PRIORITY, Message.DEFAULT_TIME_TO_LIVE);
}
```


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] qpid-jms pull request #7: Client+Server class additions - updated

[gemmellr]

Github user gemmellr commented on a diff in the pull request:

https://github.com/apache/qpid-jms/pull/7#discussion_r116069936
  
--- Diff: 
qpid-jms-examples/src/main/java/org/apache/qpid/jms/example/Server.java ---
@@ -0,0 +1,94 @@
+/*
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ *
+ */
+package org.apache.qpid.jms.example;
+
+import javax.jms.Connection;
+import javax.jms.ConnectionFactory;
+import javax.jms.DeliveryMode;
+import javax.jms.Destination;
+import javax.jms.ExceptionListener;
+import javax.jms.JMSException;
+import javax.jms.Message;
+import javax.jms.MessageConsumer;
+import javax.jms.MessageProducer;
+import javax.jms.Session;
+import javax.jms.TextMessage;
+import javax.jms.ObjectMessage;
+import javax.naming.Context;
+import javax.naming.InitialContext;
+import java.util.ArrayList;
+import java.util.Collections;
+
+public class Server {
+public static void main(String[] args) throws Exception {
+   try {
+   // The configuration for the Qpid InitialContextFactory has 
been supplied in
+   // a jndi.properties file in the classpath, which results 
in it being picked
+   // up automatically by the InitialContext constructor.
+   Context context = new InitialContext();
+   
+   ConnectionFactory factory = (ConnectionFactory) 
context.lookup("myFactoryLookup");
+   Destination queue = (Destination) 
context.lookup("myQueueLookup");
+   
+   Connection connection = 
factory.createConnection(System.getProperty("USER"), 
System.getProperty("PASSWORD"));
+   connection.setExceptionListener(new MyExceptionListener());
+   connection.start();
+   
+   Session session = connection.createSession(false, 
Session.AUTO_ACKNOWLEDGE);
+   
+   MessageConsumer messageConsumer = 
session.createConsumer(queue);
+   MessageProducer messageProducer = 
session.createProducer(null);
+   
+   while (true) {
+   System.out.println("[SERVER] Awaiting Message...");
--- End diff --

The lines below this are indented an extra level, they should all be at 
this level. I also think we can simplify this section and improve the output a 
little by doing something like:

```
while (true) {
TextMessage receivedMessage = (TextMessage) messageConsumer.receive();

System.out.println("[SERVER] Received: " + receivedMessage.getText());

TextMessage responseMessage = 
session.createTextMessage(receivedMessage.getText().toUpperCase());

messageProducer.send(receivedMessage.getJMSReplyTo(), responseMessage, 
DeliveryMode.NON_PERSISTENT, Message.DEFAULT_PRIORITY, 
Message.DEFAULT_TIME_TO_LIVE);
}
```


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Created] (PROTON-1477) Problem building qpid-proton 0.17.0 in Fedora rawhide

[Irina Boverman (JIRA)]

Irina Boverman created PROTON-1477:
--

 Summary: Problem building qpid-proton 0.17.0 in Fedora rawhide
 Key: PROTON-1477
 URL: https://issues.apache.org/jira/browse/PROTON-1477
 Project: Qpid Proton
  Issue Type: Bug
  Components: build
 Environment: x86_64
Reporter: Irina Boverman


[ 39%] Swig source
cd /builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl && 
/usr/bin/cmake -E make_directory 
/builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl
make[2]: Leaving directory '/builddir/build/BUILD/qpid-proton-0.17.0'
cd /builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl && 
/usr/bin/swig -perl -outdir 
/builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl -shadow 
-I/builddir/build/BUILD/qpid-proton-0.17.0/proton-c/src 
-I/builddir/build/BUILD/qpid-proton-0.17.0/proton-c/include -I/usr/include 
-I/usr/lib64/perl5/CORE -o 
/builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl/perlPERL_wrap.c 
/builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl/perl.i
make[2]: Leaving directory '/builddir/build/BUILD/qpid-proton-0.17.0'
cc1plus: error: -Wformat-security ignored without -Wformat 
[-Werror=format-security]
cc1plus: all warnings being treated as errors
make[2]: *** 
[proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/build.make:66: 
proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/src/binary.cpp.o] Error 1



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (PROTON-1476) C tests strict aliasing error on gcc 4.4.7

[Alan Conway (JIRA)]

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

Alan Conway resolved PROTON-1476.
-
Resolution: Fixed

> C tests strict aliasing error on gcc 4.4.7
> --
>
> Key: PROTON-1476
> URL: https://issues.apache.org/jira/browse/PROTON-1476
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> Fix strict aliasing errors on gcc 4.4.7, observed on RHEL6 in test_tools.h



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (PROTON-1476) C tests strict aliasing error on gcc 4.4.7

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16006771#comment-16006771
 ] 

ASF subversion and git services commented on PROTON-1476:
-

Commit 81ba5a3b38e450c7159caed1ffa82313d0df8409 in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=81ba5a3 ]

PROTON-1476: c and c++ example tests running on python 2.6

Using common exampletest.py library


> C tests strict aliasing error on gcc 4.4.7
> --
>
> Key: PROTON-1476
> URL: https://issues.apache.org/jira/browse/PROTON-1476
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> Fix strict aliasing errors on gcc 4.4.7, observed on RHEL6 in test_tools.h



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (PROTON-1476) C tests strict aliasing error on gcc 4.4.7

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16006770#comment-16006770
 ] 

ASF subversion and git services commented on PROTON-1476:
-

Commit beb38d21f430d421493188f70921c568668f51d1 in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=beb38d2 ]

PROTON-1476: fix strict-aliasing errors on gcc 4.4.7


> C tests strict aliasing error on gcc 4.4.7
> --
>
> Key: PROTON-1476
> URL: https://issues.apache.org/jira/browse/PROTON-1476
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> Fix strict aliasing errors on gcc 4.4.7, observed on RHEL6 in test_tools.h



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (QPID-7774) [Qpid JMS Client 0-x] [0-8..0-91] MessageConsumer#receiveNoWait() always returns null after a successful failover

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-7774:
-
Attachment: 0001-QPID-7774-Improve-locking-when-using-failover-latch.patch

Keith,
I reviewed the changes you made and would like to suggest further improvements 
to the code invoking failover latch. It seems when failover finishes 
successfully, in failover thread method 
{{AMQProtocolHandler#getFailoverLatch()}} is called. If {{receive()}} or 
{{receiveNoWait()}} are invoked from main thread, they might end-up in calling 
{{AMQProtocolHandler#blockUntilNotFailingOver}}, which holds the lock 
{{#_failoverLatchChange}} whilst calling {{_failoverLatch#await}}. As result, 
failover thread would be blocked for 30 seconds, as  
{{AMQProtocolHandler#getFailoverLatch()}} will not reurn until lock is 
released.  It seems that there is no need to call 
{{AMQProtocolHandler#getFailoverLatch()}} from the failover thread, as we 
already have reference to the failover latch. Additionally, holding  
{{#_failoverLatchChange}} whilst calling {{_failoverLatch#await}} looks 
redundant to me. I attached a patch making some changes to the code in order to 
fix the undesired behaviour. What do you think about applying the patch as part 
of this JIRA?

> [Qpid JMS Client 0-x] [0-8..0-91] MessageConsumer#receiveNoWait() always 
> returns null after a successful failover
> -
>
> Key: QPID-7774
> URL: https://issues.apache.org/jira/browse/QPID-7774
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: 0.22, 0.32, qpid-java-6.0.6, qpid-java-6.1.2
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-client-0-x-6.3.0, qpid-java-6.1.3
>
> Attachments: 
> 0001-QPID-7774-Improve-locking-when-using-failover-latch.patch
>
>
> If the client fails over when AMQP 0-8..0-91 is in use and the application is 
> using a synchronous message receiver calling #receiveNoWait(), the 
> application will always receive null.  The defect is longstanding.  It goes 
> back at least until 0.22.  Other synchronous receive calls and asynchronous 
> message listeners are unaffected.  The 0-10 path is unaffected too.
> The problem is {{org.apache.qpid.client.AMQConnection#isFailingOver}} and 
> org.apache.qpid.client.AMQProtocolHandler#startFailoverThread.   The former 
> assumes that the failover latch will be nullified after a successful failover 
> but {{startFailoverThread}} does not organise for this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (PROTON-1476) C tests strict aliasing error on gcc 4.4.7

[Alan Conway (JIRA)]

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

Alan Conway updated PROTON-1476:

Description: Fix strict aliasing errors on gcc 4.4.7, observed on RHEL6 in 
test_tools.h

> C tests strict aliasing error on gcc 4.4.7
> --
>
> Key: PROTON-1476
> URL: https://issues.apache.org/jira/browse/PROTON-1476
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> Fix strict aliasing errors on gcc 4.4.7, observed on RHEL6 in test_tools.h



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (PROTON-1476) C tests strict aliasing error on gcc 4.4.7

[Alan Conway (JIRA)]

Alan Conway created PROTON-1476:
---

 Summary: C tests strict aliasing error on gcc 4.4.7
 Key: PROTON-1476
 URL: https://issues.apache.org/jira/browse/PROTON-1476
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c
Affects Versions: 0.17.0
Reporter: Alan Conway
Assignee: Alan Conway
 Fix For: 0.18.0






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (QPID-7774) [Qpid JMS Client 0-x] [0-8..0-91] MessageConsumer#receiveNoWait() always returns null after a successful failover

[Keith Wall (JIRA)]

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

Keith Wall reassigned QPID-7774:


Assignee: Keith Wall

> [Qpid JMS Client 0-x] [0-8..0-91] MessageConsumer#receiveNoWait() always 
> returns null after a successful failover
> -
>
> Key: QPID-7774
> URL: https://issues.apache.org/jira/browse/QPID-7774
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: 0.22, 0.32, qpid-java-6.0.6, qpid-java-6.1.2
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-client-0-x-6.3.0, qpid-java-6.1.3
>
>
> If the client fails over when AMQP 0-8..0-91 is in use and the application is 
> using a synchronous message receiver calling #receiveNoWait(), the 
> application will always receive null.  The defect is longstanding.  It goes 
> back at least until 0.22.  Other synchronous receive calls and asynchronous 
> message listeners are unaffected.  The 0-10 path is unaffected too.
> The problem is {{org.apache.qpid.client.AMQConnection#isFailingOver}} and 
> org.apache.qpid.client.AMQProtocolHandler#startFailoverThread.   The former 
> assumes that the failover latch will be nullified after a successful failover 
> but {{startFailoverThread}} does not organise for this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7774) [Qpid JMS Client 0-x] [0-8..0-91] MessageConsumer#receiveNoWait() always returns null after a successful failover

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-7774:
---

Commit 948c341da7cf4a46ba62ea8ddebb711a4a636dc4 in qpid-jms-amqp-0-x's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=948c341 ]

QPID-7774: [AMQP 0-8..0-91] Ensure failover latch is nulled on all paths 
following a successful failover


> [Qpid JMS Client 0-x] [0-8..0-91] MessageConsumer#receiveNoWait() always 
> returns null after a successful failover
> -
>
> Key: QPID-7774
> URL: https://issues.apache.org/jira/browse/QPID-7774
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: 0.22, 0.32, qpid-java-6.0.6, qpid-java-6.1.2
>Reporter: Keith Wall
> Fix For: qpid-java-client-0-x-6.3.0, qpid-java-6.1.3
>
>
> If the client fails over when AMQP 0-8..0-91 is in use and the application is 
> using a synchronous message receiver calling #receiveNoWait(), the 
> application will always receive null.  The defect is longstanding.  It goes 
> back at least until 0.22.  Other synchronous receive calls and asynchronous 
> message listeners are unaffected.  The 0-10 path is unaffected too.
> The problem is {{org.apache.qpid.client.AMQConnection#isFailingOver}} and 
> org.apache.qpid.client.AMQProtocolHandler#startFailoverThread.   The former 
> assumes that the failover latch will be nullified after a successful failover 
> but {{startFailoverThread}} does not organise for this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[GitHub] qpid-jms pull request #7: Client+Server class additions - updated

[ageannopoulos]

GitHub user ageannopoulos opened a pull request:

https://github.com/apache/qpid-jms/pull/7

Client+Server class additions - updated

I made these classes more simplified but still demonstrative of JMS message 
interpretation, added the licenses, and cleaned up code. 

I also made the client generate messages that could have one of three 
messages to show that the server will reply to the correct client via the 
TemporaryQueue.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ageannopoulos/qpid-jms client_server_additions

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-jms/pull/7.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #7


commit 7bd681339e322b0b776684211fb1a26c70760ab3
Author: Austin Geannopoulos 
Date:   2017-05-08T17:35:08Z

Added two new example classes, Client and Server

commit 2474c859a757b475fba6e83afec6b18402dd9d4e
Author: Austin Geannopoulos 
Date:   2017-05-11T15:00:20Z

Updated the client+server examples to be more straightforward and cleaned 
up code




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (QPID-7739) [Java Broker] In AMQP 1.0 fix handling of channel Id > 2^15

[Lorenz Quack (JIRA)]

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

Lorenz Quack commented on QPID-7739:


There are more cases in the broker where we are not using the correct type.
For example {{deliveryId}} in Disposition is modeled as a {{UnsignedInteger}} 
but it should be a {{SequenceNumber}}.
In most places were the spec states a field is of type {{delivery-number}}, 
{{transfer-number}}, or {{sequence-number}} we are using {{UnsignedInteger}} 
instead of correct type.

This can cause problems with wrap around in {{compareTo}}.
For example {{UnsignedInteger(0) < UnsignedInteger(-1)}} whereas 
{{SequenceNumber(0) > SequenceNumber(-1)}}.

> [Java Broker] In AMQP 1.0 fix handling of channel Id > 2^15
> ---
>
> Key: QPID-7739
> URL: https://issues.apache.org/jira/browse/QPID-7739
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> In AMQP 1.0 the channel ID is an Unsigned Short, i.e. 0 <= x < 2^16
> However in the amqp 1.0 plugin the channel is modeled as a java short which 
> is signed and thus in the range -2^15 <= x < 2^15.
> This causes some problems if the channel id exceeds 2^15. Some issues are 
> minor like the error statement in {{AMQPConnection_1_0Impl#getSession}} 
> taking on a negative value but some will be more unfortunate like the 
> {{ArrayIndexOutOfBoundsException}} earlier in the same method (will fail the 
> session Begin and close the connection).
> There are several possible solutions:
>  * handle the unsigned short correctly (either as UnsignedShort or as int)
>  * enforce a max-channel of 2^15 - 1 on connection Open



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[GitHub] qpid-jms pull request #6: Added two new example classes, Client and Server.

[ageannopoulos]

Github user ageannopoulos closed the pull request at:

https://github.com/apache/qpid-jms/pull/6


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (DISPATCH-768) On topology page, show connections that go to more than one router

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16006563#comment-16006563
 ] 

ASF subversion and git services commented on DISPATCH-768:
--

Commit 0f0645592e13ecbf6e5ac58633a25cea25b078fc in qpid-dispatch's branch 
refs/heads/master from [~eallen]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=0f06455 ]

DISPATCH-768 Handle connections that go to more than one router


> On topology page, show connections that go to more than one router
> --
>
> Key: DISPATCH-768
> URL: https://issues.apache.org/jira/browse/DISPATCH-768
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 0.8.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>
> If the same connection.containerId appears on multiple routers, don't 
> duplicate the connection on the topology page. Instead, use a single circle 
> and draw links to both routers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (DISPATCH-769) Links popup on topology page only shows a single link

[Ernest Allen (JIRA)]

Ernest Allen created DISPATCH-769:
-

 Summary: Links popup on topology page only shows a single link
 Key: DISPATCH-769
 URL: https://issues.apache.org/jira/browse/DISPATCH-769
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Console
Affects Versions: 0.8.0
Reporter: Ernest Allen
Assignee: Ernest Allen


On the topology page for stand-alone, click on the console icon. A popup 
showing the links for that connection is displayed.
There are 2 links, however the table only show 1 link at a time. You need to 
scroll to see the other link.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Closed] (PROTON-1475) Body message with dirty characters

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell closed PROTON-1475.
--
Resolution: Not A Problem

At first glance that looks like the full payload of an AMQP encoded message, in 
which case its most likely an artifact of how the broker stores AMQP messages 
internally and its web console displays them, and not to do with the python 
binding having a bug which could be fixed. This would also help explain why 
there is no problem receiving them.

> Body message with dirty characters
> --
>
> Key: PROTON-1475
> URL: https://issues.apache.org/jira/browse/PROTON-1475
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.17.0
> Environment: Red Hat 7 and apache-activemq-5.14.3
>Reporter: Pier Paolo Panto
>Priority: Minor
>
> Hi,
> when I write a Message on a queue with command self.sender.send(msg) (msg is 
> Message object) In the body of the message strange characters are added 
> before my string and are visible in the MQ web interface in body field.
> But while reading the message then everything is fine.
> How do I remove them?
> Thanks.
> the characters are:
> Sp�BP@BRSs�&
> @@@�req��@R@Sw�



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (DISPATCH-761) Router crash on abrupt close of sender/receiver connections

[Ganesh Murthy (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16006500#comment-16006500
 ] 

Ganesh Murthy commented on DISPATCH-761:


After the upgrade to epoll proactor, this issue cannot be reproduced anymore

> Router crash on abrupt close of sender/receiver connections
> ---
>
> Key: DISPATCH-761
> URL: https://issues.apache.org/jira/browse/DISPATCH-761
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Reporter: Ganesh Murthy
>Assignee: Alan Conway
> Fix For: 1.0.0
>
> Attachments: test-app.tar.gz
>
>
> Attached is a file that contains the source. 
> Start the routers using the provided config files
> Start the senders and the receivers 
> Wait for 5 mins, the routers will crash.
> Following is the backtrace - 
> {noformat}
> (gdb) bt
> #0  pn_transport_closed (transport=0x0) at 
> /home/gmurthy/opensource/qpid-proton/proton-c/src/core/transport.c:3032
> #1  0x7f1a1d9539ed in pn_connection_driver_finished 
> (d=d@entry=0x7f19f23187e8) at 
> /home/gmurthy/opensource/qpid-proton/proton-c/src/core/connection_driver.c:141
> #2  0x7f1a1d73883f in leader_process_pconnection (pc=0x7f19f23187c0) at 
> /home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/libuv.c:865
> #3  leader_lead_lh (p=p@entry=0x159a7b0, mode=mode@entry=UV_RUN_ONCE) at 
> /home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/libuv.c:968
> #4  0x7f1a1d738cad in pn_proactor_wait (p=0x159a7b0) at 
> /home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/libuv.c:1022
> #5  0x7f1a1dbb69b9 in thread_run (arg=0x15b8980) at 
> /home/gmurthy/opensource/dispatch/src/server.c:817
> #6  0x7f1a1d51d6ca in start_thread () from /lib64/libpthread.so.0
> #7  0x7f1a1c849f7f in clone () from /lib64/libc.so.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (DISPATCH-768) On topology page, show connections that go to more than one router

[Ernest Allen (JIRA)]

Ernest Allen created DISPATCH-768:
-

 Summary: On topology page, show connections that go to more than 
one router
 Key: DISPATCH-768
 URL: https://issues.apache.org/jira/browse/DISPATCH-768
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Console
Affects Versions: 0.8.0
Reporter: Ernest Allen
Assignee: Ernest Allen


If the same connection.containerId appears on multiple routers, don't duplicate 
the connection on the topology page. Instead, use a single circle and draw 
links to both routers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Closed] (DISPATCH-761) Router crash on abrupt close of sender/receiver connections

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy closed DISPATCH-761.
--
Resolution: Fixed

> Router crash on abrupt close of sender/receiver connections
> ---
>
> Key: DISPATCH-761
> URL: https://issues.apache.org/jira/browse/DISPATCH-761
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Reporter: Ganesh Murthy
>Assignee: Alan Conway
> Fix For: 1.0.0
>
> Attachments: test-app.tar.gz
>
>
> Attached is a file that contains the source. 
> Start the routers using the provided config files
> Start the senders and the receivers 
> Wait for 5 mins, the routers will crash.
> Following is the backtrace - 
> {noformat}
> (gdb) bt
> #0  pn_transport_closed (transport=0x0) at 
> /home/gmurthy/opensource/qpid-proton/proton-c/src/core/transport.c:3032
> #1  0x7f1a1d9539ed in pn_connection_driver_finished 
> (d=d@entry=0x7f19f23187e8) at 
> /home/gmurthy/opensource/qpid-proton/proton-c/src/core/connection_driver.c:141
> #2  0x7f1a1d73883f in leader_process_pconnection (pc=0x7f19f23187c0) at 
> /home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/libuv.c:865
> #3  leader_lead_lh (p=p@entry=0x159a7b0, mode=mode@entry=UV_RUN_ONCE) at 
> /home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/libuv.c:968
> #4  0x7f1a1d738cad in pn_proactor_wait (p=0x159a7b0) at 
> /home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/libuv.c:1022
> #5  0x7f1a1dbb69b9 in thread_run (arg=0x15b8980) at 
> /home/gmurthy/opensource/dispatch/src/server.c:817
> #6  0x7f1a1d51d6ca in start_thread () from /lib64/libpthread.so.0
> #7  0x7f1a1c849f7f in clone () from /lib64/libc.so.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (PROTON-1475) Body message with dirty characters

[Pier Paolo Panto (JIRA)]

Pier Paolo Panto created PROTON-1475:


 Summary: Body message with dirty characters
 Key: PROTON-1475
 URL: https://issues.apache.org/jira/browse/PROTON-1475
 Project: Qpid Proton
  Issue Type: Bug
  Components: python-binding
Affects Versions: 0.17.0
 Environment: Red Hat 7 and apache-activemq-5.14.3
Reporter: Pier Paolo Panto
Priority: Minor


Hi,
when I write a Message on a queue with command self.sender.send(msg) (msg is 
Message object) In the body of the message strange characters are added before 
my string and are visible in the MQ web interface in body field.
But while reading the message then everything is fine.
How do I remove them?
Thanks.

the characters are:
Sp�BP@BRSs�&
@@@�req��@R@Sw�



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7748) [Java Broker] In AMQP 1.0 ensure we send Flow echo in a timely fashion

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-7748:
---

Commit c94d60e31817a68413905b398f03a4d4cc9adec5 in qpid-broker-j's branch 
refs/heads/master from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=c94d60e ]

Revert "QPID-7748: [Java Broker] Remove superfluous SequenceNumber"

This reverts commit 5017eb060c30a1b6d265defa17ad7b798c2f2f12.
The difference in the compareTo method between SequenceNumber and
UnsignedInteger prohibits the removal of the former.


> [Java Broker] In AMQP 1.0 ensure we send Flow echo in a timely fashion
> --
>
> Key: QPID-7748
> URL: https://issues.apache.org/jira/browse/QPID-7748
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> Currently, it seems that when the broker receives a AMQP 1.0 Flow 
> performative with {{echo=True}} we are not always sending back a Flow 
> performantive in a timely fashion.
> The spec says (2.7.4)
> bq. If set to true then the receiver SHOULD send its state at the earliest 
> convenient opportunity.
> This was braught out by the Protocol test 
> {{org.apache.qpid.tests.protocol.v1_0.transport.link.FlowTest#echoFlow}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (QPID-7774) [Qpid JMS Client 0-x] [0-8..0-91] MessageConsumer#receiveNoWait() always returns null after a successful failover

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7774:
-
Description: 
If the client fails over when AMQP 0-8..0-91 is in use and the application is 
using a synchronous message receiver calling #receiveNoWait(), the application 
will always receive null.  The defect is longstanding.  It goes back at least 
until 0.22.  Other synchronous receive calls and asynchronous message listeners 
are unaffected.  The 0-10 path is unaffected too.

The problem is {{org.apache.qpid.client.AMQConnection#isFailingOver}} and 
org.apache.qpid.client.AMQProtocolHandler#startFailoverThread.   The former 
assumes that the failover latch will be nullified after a successful failover 
but {{startFailoverThread}} does not organise for this.


  was:
If the client fails over when AMQP 0-8..0-91 is in use and the application is 
using a synchronous message receiver calling #receiveNoWait(), the application 
will always receive null.  The defect is longstanding.  It goes back at least 
until 0.22.  Other synchronous receive calls, asynchronous message listeners 
are unaffected.  The 0-10 path is unaffected too.

The problem is {{org.apache.qpid.client.AMQConnection#isFailingOver}} and 
org.apache.qpid.client.AMQProtocolHandler#startFailoverThread.   The former 
assumes that the failover latch will be nullified after a successful failover 
but {{startFailoverThread}} does not organise for this.



> [Qpid JMS Client 0-x] [0-8..0-91] MessageConsumer#receiveNoWait() always 
> returns null after a successful failover
> -
>
> Key: QPID-7774
> URL: https://issues.apache.org/jira/browse/QPID-7774
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: 0.22, 0.32, qpid-java-6.0.6, qpid-java-6.1.2
>Reporter: Keith Wall
> Fix For: qpid-java-client-0-x-6.3.0, qpid-java-6.1.3
>
>
> If the client fails over when AMQP 0-8..0-91 is in use and the application is 
> using a synchronous message receiver calling #receiveNoWait(), the 
> application will always receive null.  The defect is longstanding.  It goes 
> back at least until 0.22.  Other synchronous receive calls and asynchronous 
> message listeners are unaffected.  The 0-10 path is unaffected too.
> The problem is {{org.apache.qpid.client.AMQConnection#isFailingOver}} and 
> org.apache.qpid.client.AMQProtocolHandler#startFailoverThread.   The former 
> assumes that the failover latch will be nullified after a successful failover 
> but {{startFailoverThread}} does not organise for this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (QPID-7774) [Qpid JMS Client 0-x] [0-8..0-91] MessageConsumer#receiveNoWait() always returns null after a successful failover

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7774:
-
Fix Version/s: qpid-java-6.1.3
   qpid-java-client-0-x-6.3.0

> [Qpid JMS Client 0-x] [0-8..0-91] MessageConsumer#receiveNoWait() always 
> returns null after a successful failover
> -
>
> Key: QPID-7774
> URL: https://issues.apache.org/jira/browse/QPID-7774
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: 0.22, 0.32, qpid-java-6.0.6, qpid-java-6.1.2
>Reporter: Keith Wall
> Fix For: qpid-java-client-0-x-6.3.0, qpid-java-6.1.3
>
>
> If the client fails over when AMQP 0-8..0-91 is in use and the application is 
> using a synchronous message receiver calling #receiveNoWait(), the 
> application will always receive null.  The defect is longstanding.  It goes 
> back at least until 0.22.  Other synchronous receive calls, asynchronous 
> message listeners are unaffected.  The 0-10 path is unaffected too.
> The problem is {{org.apache.qpid.client.AMQConnection#isFailingOver}} and 
> org.apache.qpid.client.AMQProtocolHandler#startFailoverThread.   The former 
> assumes that the failover latch will be nullified after a successful failover 
> but {{startFailoverThread}} does not organise for this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7634) [Java Broker,amqp 1.0] Broker does not respond to Flow command with drain=true if queue is empty and prefetch is 0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-7634:
---

Commit 01beffa6bc323c009b5ee55bce835e82f9570f08 in qpid-broker-j's branch 
refs/heads/master from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=01beffa ]

QPID-7634: [Java Broker] Ensure consumer is processed after receiving 
Flow.drain=true even when queue is empty


> [Java Broker,amqp 1.0] Broker does not respond to Flow command with 
> drain=true if queue is empty and prefetch is 0
> --
>
> Key: QPID-7634
> URL: https://issues.apache.org/jira/browse/QPID-7634
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> When AMQP 1.0 client sends the Flow command with drain=true and queue is 
> empty the Broker does not respond if prefetch is 0.
> The following snippet reproduces the issue
> {code}
> Connection connection = factory.createConnection(username, password);
> connection.start();
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> MessageConsumer messageConsumer = session.createConsumer(queue);
> TextMessage receivedMessage = (TextMessage) messageConsumer.receiveNoWait(); 
> // <-- times out
> {code}
> The broker logs
> {noformat}
> 2017-01-24 11:05:56,471 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - 
> RECV[/127.0.0.1:51108|1] : 
> Attach{name=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,handle=1,role=receiver,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{address=queue,durable=none,expiryPolicy=link-detach,timeout=0,dynamic=false,defaultOutcome=Modified{deliveryFailed=true},outcomes=[amqp:accepted:list,
>  amqp:rejected:list, amqp:released:list, 
> amqp:modified:list],capabilities=[queue, global]},target=Target{}}
> 2017-01-24 11:05:56,474 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Performing Task['add consumer' on 'queue' 
> with arguments 
> 'target=ConsumerTarget_1_0[linkSession=[con:7(admin@/127.0.0.1:51108/default)/ch:1]
>  ], 
> consumerName=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  optionSet=[ACQUIRES, SEES_REQUEUES]']
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER, returing 
> default: ALLOWED
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Performing Task['open' on 
> 'Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
> name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  type=Consumer]']
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Task['open' on 
> 'Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
> name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  type=Consumer]'] performed successfully with result: null
> 2017-01-24 11:05:56,476 INFO  [VirtualHostNode-default-Config] (q.m.s.create) 
> - [con:7(admin@/127.0.0.1:51108/default)/ch:1] [sub:7(vh(/default)/qu(queue)] 
> SUB-1001 : Create
> 2017-01-24 11:05:56,476 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Task['add consumer' on 'queue' with 
> arguments 
> 'target=ConsumerTarget_1_0[linkSession=[con:7(admin@/127.0.0.1:51108/default)/ch:1]
>  ], 
> consumerName=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  optionSet=[ACQUIRES, SEES_REQUEUES]'] performed successfully with result: 
> Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
> name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  type=Consumer]
> 2017-01-24 11:05:56,477 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - 
> SEND[/127.0.0.1:51108|1] : 
> Attach{name=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,handle=1,role=sender,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{address=queue,durable=none,expiryPolicy=link-detach,timeout=0,dynamic=false,defaultOutcome=Modified{deliveryFailed=true},outcomes=[amqp:accepted:list,
>  amqp:rejected:list, amqp:released:list, 
> amqp:modified:list],capabilities=[queue]},target=Target{},initialDeliveryCount=0,offeredCapabilities=[SHARED-SUBS],properties={}}
> 2017-01-24 11:05:56,477 DEBUG [IO-/127.0.0.1:51108] 
> (o.a.q.s.t.NonBlockingConnection) - Written 251 bytes
> 

[jira] [Commented] (QPID-7634) [Java Broker,amqp 1.0] Broker does not respond to Flow command with drain=true if queue is empty and prefetch is 0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-7634:
---

Commit 12f92eddc99c92001103431d379af078eb6f0010 in qpid-broker-j's branch 
refs/heads/master from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=12f92ed ]

Revert: QPID-7634: [Java Broker] Ensure flow is sent after receiving 
Flow.drain=true

Keep the test


> [Java Broker,amqp 1.0] Broker does not respond to Flow command with 
> drain=true if queue is empty and prefetch is 0
> --
>
> Key: QPID-7634
> URL: https://issues.apache.org/jira/browse/QPID-7634
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> When AMQP 1.0 client sends the Flow command with drain=true and queue is 
> empty the Broker does not respond if prefetch is 0.
> The following snippet reproduces the issue
> {code}
> Connection connection = factory.createConnection(username, password);
> connection.start();
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> MessageConsumer messageConsumer = session.createConsumer(queue);
> TextMessage receivedMessage = (TextMessage) messageConsumer.receiveNoWait(); 
> // <-- times out
> {code}
> The broker logs
> {noformat}
> 2017-01-24 11:05:56,471 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - 
> RECV[/127.0.0.1:51108|1] : 
> Attach{name=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,handle=1,role=receiver,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{address=queue,durable=none,expiryPolicy=link-detach,timeout=0,dynamic=false,defaultOutcome=Modified{deliveryFailed=true},outcomes=[amqp:accepted:list,
>  amqp:rejected:list, amqp:released:list, 
> amqp:modified:list],capabilities=[queue, global]},target=Target{}}
> 2017-01-24 11:05:56,474 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Performing Task['add consumer' on 'queue' 
> with arguments 
> 'target=ConsumerTarget_1_0[linkSession=[con:7(admin@/127.0.0.1:51108/default)/ch:1]
>  ], 
> consumerName=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  optionSet=[ACQUIRES, SEES_REQUEUES]']
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER, returing 
> default: ALLOWED
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Performing Task['open' on 
> 'Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
> name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  type=Consumer]']
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Task['open' on 
> 'Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
> name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  type=Consumer]'] performed successfully with result: null
> 2017-01-24 11:05:56,476 INFO  [VirtualHostNode-default-Config] (q.m.s.create) 
> - [con:7(admin@/127.0.0.1:51108/default)/ch:1] [sub:7(vh(/default)/qu(queue)] 
> SUB-1001 : Create
> 2017-01-24 11:05:56,476 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Task['add consumer' on 'queue' with 
> arguments 
> 'target=ConsumerTarget_1_0[linkSession=[con:7(admin@/127.0.0.1:51108/default)/ch:1]
>  ], 
> consumerName=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  optionSet=[ACQUIRES, SEES_REQUEUES]'] performed successfully with result: 
> Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
> name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  type=Consumer]
> 2017-01-24 11:05:56,477 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - 
> SEND[/127.0.0.1:51108|1] : 
> Attach{name=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,handle=1,role=sender,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{address=queue,durable=none,expiryPolicy=link-detach,timeout=0,dynamic=false,defaultOutcome=Modified{deliveryFailed=true},outcomes=[amqp:accepted:list,
>  amqp:rejected:list, amqp:released:list, 
> amqp:modified:list],capabilities=[queue]},target=Target{},initialDeliveryCount=0,offeredCapabilities=[SHARED-SUBS],properties={}}
> 2017-01-24 11:05:56,477 DEBUG [IO-/127.0.0.1:51108] 
> (o.a.q.s.t.NonBlockingConnection) - Written 251 bytes
> 2017-01-24 

[jira] [Updated] (QPID-7777) [AMQP 1.0] NPE during consumer target delivery path

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-:
-
Priority: Blocker  (was: Major)

> [AMQP 1.0] NPE during consumer target delivery path 
> 
>
> Key: QPID-
> URL: https://issues.apache.org/jira/browse/QPID-
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Blocker
> Fix For: qpid-java-broker-7.0.0
>
>
> The following NPE was encountered during a performance test run.   The logs 
> showed that the Broker was flowing messages to disk at the time.
> {noformat}
> java.lang.NullPointerException: null
> at 
> org.apache.qpid.server.protocol.v1_0.type.messaging.AbstractSection.getEncodedForm(AbstractSection.java:78)
> at 
> org.apache.qpid.server.protocol.v1_0.ConsumerTarget_1_0.doSend(ConsumerTarget_1_0.java:157)
> at 
> org.apache.qpid.server.consumer.AbstractConsumerTarget.send(AbstractConsumerTarget.java:206)
> at 
> org.apache.qpid.server.consumer.AbstractConsumerTarget.sendNextMessage(AbstractConsumerTarget.java:247)
> at 
> org.apache.qpid.server.consumer.AbstractConsumerTarget.processPending(AbstractConsumerTarget.java:142)
> at 
> org.apache.qpid.server.session.AbstractAMQPSession.processPending(AbstractAMQPSession.java:391)
> at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl$ProcessPendingIterator$3.run(AMQPConnection_1_0Impl.java:1755)
> at 
> org.apache.qpid.server.transport.NonBlockingConnection.processPending(NonBlockingConnection.java:356)
> at 
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:264)
> at 
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:124)
> at 
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:563)
> at 
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.run(SelectorThread.java:551)
> at 
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (QPID-7777) [AMQP 1.0] NPE during consumer target delivery path

[Keith Wall (JIRA)]

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

Keith Wall edited comment on QPID- at 5/11/17 1:01 PM:
---

This problem can only occur on master. 6.1.x is not affected.

We have a race between flowToDisk and a consumer target.

# Flow to disk calls {{MessageMetaData_1_0#clearEncodedForm}}, which internally 
calls {{MessageMetaData_1_0#dispose}}!  This calls dispose on all the sections.
# Meanwhile, a consumer executes {{ConsumerTarget_1_0#doSend}} which gets the 
{{HeaderSection}} from the MMD.  The HeaderSection it gets belongs to the 
{{MessageMetaData_1_0 }} (same object).  The ConsumerTarget then NPEs when it 
calls payload.addAll(headerSection.getEncodedForm()).

I see three problems:

# {{MessageMetaData_1_0#clearEncodedForm}} should be asking the Sections to 
clearEncodedForm, not dispose (we are not done with them yet).
# {{Sections}} needs to be prepared to recreate the encoded form (like their 
AMQP 0-9 counterparts). 
# {{MessageMetaData_1_0.getHeader}} should not expose its own {{HeaderSection}} 
but a copy instead.  The caller needs to #dispose of it once he’s done.



was (Author: k-wall):
This problem can only occur on master. 6.1.x is not affected.

We have a race between flowToDisk and a consumer target.

# Flow to disk calls MessageMetaData_1_0#clearEncodedForm, which internally 
calls MessageMetaData_1_0#dispose!  This calls dispose on all the sections.
# Meanwhile, a consumer executes ConsumerTarget_1_0#doSend which gets the 
HeaderSection from the MMD.  The HeaderSection it gets belongs to the 
MessageMetaData_1_0  (same object).  The ConsumerTarget then NPEs when it calls 
payload.addAll(headerSection.getEncodedForm()).

I see three problems:

# MessageMetaData_1_0#clearEncodedForm should be asking the Sections to 
clearEncodedForm, not dispose (we are not done with them yet).
# Sections needs to be prepared to recreate the encoded form (like their AMQP 
0-9 counterparts). 
# MessageMetaData_1_0.getHeader should not expose its own HeaderSection but a 
copy.  The caller needs to dispose of it once he’s done.


> [AMQP 1.0] NPE during consumer target delivery path 
> 
>
> Key: QPID-
> URL: https://issues.apache.org/jira/browse/QPID-
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The following NPE was encountered during a performance test run.   The logs 
> showed that the Broker was flowing messages to disk at the time.
> {noformat}
> java.lang.NullPointerException: null
> at 
> org.apache.qpid.server.protocol.v1_0.type.messaging.AbstractSection.getEncodedForm(AbstractSection.java:78)
> at 
> org.apache.qpid.server.protocol.v1_0.ConsumerTarget_1_0.doSend(ConsumerTarget_1_0.java:157)
> at 
> org.apache.qpid.server.consumer.AbstractConsumerTarget.send(AbstractConsumerTarget.java:206)
> at 
> org.apache.qpid.server.consumer.AbstractConsumerTarget.sendNextMessage(AbstractConsumerTarget.java:247)
> at 
> org.apache.qpid.server.consumer.AbstractConsumerTarget.processPending(AbstractConsumerTarget.java:142)
> at 
> org.apache.qpid.server.session.AbstractAMQPSession.processPending(AbstractAMQPSession.java:391)
> at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl$ProcessPendingIterator$3.run(AMQPConnection_1_0Impl.java:1755)
> at 
> org.apache.qpid.server.transport.NonBlockingConnection.processPending(NonBlockingConnection.java:356)
> at 
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:264)
> at 
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:124)
> at 
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:563)
> at 
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.run(SelectorThread.java:551)
> at 
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7777) [AMQP 1.0] NPE during consumer target delivery path

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-:
--

This problem can only occur on master. 6.1.x is not affected.

We have a race between flowToDisk and a consumer target.

# Flow to disk calls MessageMetaData_1_0#clearEncodedForm, which internally 
calls MessageMetaData_1_0#dispose!  This calls dispose on all the sections.
# Meanwhile, a consumer executes ConsumerTarget_1_0#doSend which gets the 
HeaderSection from the MMD.  The HeaderSection it gets belongs to the 
MessageMetaData_1_0  (same object).  The ConsumerTarget then NPEs when it calls 
payload.addAll(headerSection.getEncodedForm()).

I see three problems:

# MessageMetaData_1_0#clearEncodedForm should be asking the Sections to 
clearEncodedForm, not dispose (we are not done with them yet).
# Sections needs to be prepared to recreate the encoded form (like their AMQP 
0-9 counterparts). 
# MessageMetaData_1_0.getHeader should not expose its own HeaderSection but a 
copy.  The caller needs to dispose of it once he’s done.


> [AMQP 1.0] NPE during consumer target delivery path 
> 
>
> Key: QPID-
> URL: https://issues.apache.org/jira/browse/QPID-
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The following NPE was encountered during a performance test run.   The logs 
> showed that the Broker was flowing messages to disk at the time.
> {noformat}
> java.lang.NullPointerException: null
> at 
> org.apache.qpid.server.protocol.v1_0.type.messaging.AbstractSection.getEncodedForm(AbstractSection.java:78)
> at 
> org.apache.qpid.server.protocol.v1_0.ConsumerTarget_1_0.doSend(ConsumerTarget_1_0.java:157)
> at 
> org.apache.qpid.server.consumer.AbstractConsumerTarget.send(AbstractConsumerTarget.java:206)
> at 
> org.apache.qpid.server.consumer.AbstractConsumerTarget.sendNextMessage(AbstractConsumerTarget.java:247)
> at 
> org.apache.qpid.server.consumer.AbstractConsumerTarget.processPending(AbstractConsumerTarget.java:142)
> at 
> org.apache.qpid.server.session.AbstractAMQPSession.processPending(AbstractAMQPSession.java:391)
> at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl$ProcessPendingIterator$3.run(AMQPConnection_1_0Impl.java:1755)
> at 
> org.apache.qpid.server.transport.NonBlockingConnection.processPending(NonBlockingConnection.java:356)
> at 
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:264)
> at 
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:124)
> at 
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:563)
> at 
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.run(SelectorThread.java:551)
> at 
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (QPID-7777) [AMQP 1.0] NPE during consumer target delivery path

[Keith Wall (JIRA)]

Keith Wall created QPID-:


 Summary: [AMQP 1.0] NPE during consumer target delivery path 
 Key: QPID-
 URL: https://issues.apache.org/jira/browse/QPID-
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Affects Versions: qpid-java-broker-7.0.0
Reporter: Keith Wall
 Fix For: qpid-java-broker-7.0.0


The following NPE was encountered during a performance test run.   The logs 
showed that the Broker was flowing messages to disk at the time.

{noformat}
java.lang.NullPointerException: null
at 
org.apache.qpid.server.protocol.v1_0.type.messaging.AbstractSection.getEncodedForm(AbstractSection.java:78)
at 
org.apache.qpid.server.protocol.v1_0.ConsumerTarget_1_0.doSend(ConsumerTarget_1_0.java:157)
at 
org.apache.qpid.server.consumer.AbstractConsumerTarget.send(AbstractConsumerTarget.java:206)
at 
org.apache.qpid.server.consumer.AbstractConsumerTarget.sendNextMessage(AbstractConsumerTarget.java:247)
at 
org.apache.qpid.server.consumer.AbstractConsumerTarget.processPending(AbstractConsumerTarget.java:142)
at 
org.apache.qpid.server.session.AbstractAMQPSession.processPending(AbstractAMQPSession.java:391)
at 
org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl$ProcessPendingIterator$3.run(AMQPConnection_1_0Impl.java:1755)
at 
org.apache.qpid.server.transport.NonBlockingConnection.processPending(NonBlockingConnection.java:356)
at 
org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:264)
at 
org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:124)
at 
org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:563)
at 
org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.run(SelectorThread.java:551)
at 
org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7634) [Java Broker,amqp 1.0] Broker does not respond to Flow command with drain=true if queue is empty and prefetch is 0

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell commented on QPID-7634:
--

{quote}
An interesting question is whether the "issue" identified is actually an issue 
at all. The client issues a drain on a link with zero credit... which means 
that the delivery count is already advanced.
{quote}

Just clarifying here for others and for later, as discusssed elsewhere the 
trace shows the client actually did flow a single credit while draining, so it 
should indeed get either a message or a 'drain response' flow actioning the 
delivery count advancement from the broker.

> [Java Broker,amqp 1.0] Broker does not respond to Flow command with 
> drain=true if queue is empty and prefetch is 0
> --
>
> Key: QPID-7634
> URL: https://issues.apache.org/jira/browse/QPID-7634
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> When AMQP 1.0 client sends the Flow command with drain=true and queue is 
> empty the Broker does not respond if prefetch is 0.
> The following snippet reproduces the issue
> {code}
> Connection connection = factory.createConnection(username, password);
> connection.start();
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> MessageConsumer messageConsumer = session.createConsumer(queue);
> TextMessage receivedMessage = (TextMessage) messageConsumer.receiveNoWait(); 
> // <-- times out
> {code}
> The broker logs
> {noformat}
> 2017-01-24 11:05:56,471 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - 
> RECV[/127.0.0.1:51108|1] : 
> Attach{name=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,handle=1,role=receiver,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{address=queue,durable=none,expiryPolicy=link-detach,timeout=0,dynamic=false,defaultOutcome=Modified{deliveryFailed=true},outcomes=[amqp:accepted:list,
>  amqp:rejected:list, amqp:released:list, 
> amqp:modified:list],capabilities=[queue, global]},target=Target{}}
> 2017-01-24 11:05:56,474 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Performing Task['add consumer' on 'queue' 
> with arguments 
> 'target=ConsumerTarget_1_0[linkSession=[con:7(admin@/127.0.0.1:51108/default)/ch:1]
>  ], 
> consumerName=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  optionSet=[ACQUIRES, SEES_REQUEUES]']
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER, returing 
> default: ALLOWED
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Performing Task['open' on 
> 'Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
> name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  type=Consumer]']
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Task['open' on 
> 'Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
> name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  type=Consumer]'] performed successfully with result: null
> 2017-01-24 11:05:56,476 INFO  [VirtualHostNode-default-Config] (q.m.s.create) 
> - [con:7(admin@/127.0.0.1:51108/default)/ch:1] [sub:7(vh(/default)/qu(queue)] 
> SUB-1001 : Create
> 2017-01-24 11:05:56,476 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Task['add consumer' on 'queue' with 
> arguments 
> 'target=ConsumerTarget_1_0[linkSession=[con:7(admin@/127.0.0.1:51108/default)/ch:1]
>  ], 
> consumerName=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  optionSet=[ACQUIRES, SEES_REQUEUES]'] performed successfully with result: 
> Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
> name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  type=Consumer]
> 2017-01-24 11:05:56,477 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - 
> SEND[/127.0.0.1:51108|1] : 
> Attach{name=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,handle=1,role=sender,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{address=queue,durable=none,expiryPolicy=link-detach,timeout=0,dynamic=false,defaultOutcome=Modified{deliveryFailed=true},outcomes=[amqp:accepted:list,
>  amqp:rejected:list, amqp:released:list, 
> 

[jira] [Commented] (QPID-7767) Unknown endpoint Transfer issue on AMQP Connection

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell commented on QPID-7767:
--

This old thread on the Qpid Users mailing list might be informative: 
https://lists.apache.org/thread.html/d2a49fb0c3e8b5501c82fe683f7227ace3552eb6c0cb010a618e98a1@%3Cusers.qpid.apache.org%3E

Incidentally, the users list is where most questions should go, see 
http://qpid.apache.org/discussion.html for details.

> Unknown endpoint Transfer issue on AMQP Connection
> --
>
> Key: QPID-7767
> URL: https://issues.apache.org/jira/browse/QPID-7767
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: 0.32
> Environment: AMQP Client  - Qpid 0.32 runs on Java run time 1.7 on 
> Linux box  on softLayer
> AMQP Server -   Azure Service bus on Public cloud
>Reporter: Kapila Arora
>Priority: Critical
> Attachments: 
> apacheQpidJMS0.11.1_protocolLog_withDelivery34_DataMasking.log, 
> Qpid_error_log.txt
>
>
> Getting Errors in the AMQP Client 
> 2017-05-03 06:45:15.048212 Unknown endpoint 
> Transfer{handle=0,deliveryId=2,deliveryTag=\xf3\x99\x90\x5cL\xb1\xdeF\x9da\xa3o\xb0\x5cdm,messageFormat=0,more=true,batchable=true}
> Data Packets 
> Unknown endpoint 
> Transfer{handle=0,deliveryId=2,deliveryTag=\xf3\x99\x90\x5cL\xb1\xdeF\x9da\xa3o\xb0\x5cdm,messageFormat=0,more=true,batchable=true}
> 2017-05-03 06:45:15.396212 Unknown endpoint Transfer{handle=0,more=false}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPID-7753) Sparsely occupied message buffers may lead to java.lang.OutOfMemoryError: Direct buffer memory

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-7753:
---

Commit 17ce2e38430fc8a45e9b3d135f0d304115da944e in qpid-broker-j's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=17ce2e3 ]

QPID-7753: Avoid possibility of RejectedExecutionException during shutdown


> Sparsely occupied message buffers may lead to java.lang.OutOfMemoryError: 
> Direct buffer memory
> --
>
> Key: QPID-7753
> URL: https://issues.apache.org/jira/browse/QPID-7753
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: flow-to-disk-based-on-used-direct-memory-6-0-x.diff
>
>
> Some Broker usage patterns can lead to the Broker failing with a 
> "java.lang.OutOfMemoryError: Direct buffer memory" error.
> For the condition to manifest a producing application needs to use a single 
> connection for the production of messages. Some messages need to be consumed 
> quickly whilst others remain on the Broker. This pattern might result from:
> # the consuming application using message selectors to selectively consume 
> some messages whilst leaving others on the Broker.
> # the use of 'out of order' queue types (priority/sorted etc) where lower 
> priority items are left of the Broker.
> # the producing application routing messages to multiple queues and the 
> consuming application draining some queues but not others.
> The problem arises owing to the buffering strategy under the IO layer.
> {{NonBlockingConnection}} allocates a {{netInputBuffer}} from pooled direct 
> memory of size 256K.  This buffer is used for all network reads until the 
> space remaining in the buffer is less than the amount required to complete 
> the AMQP frame that is currently being read, in which case a new 
> netInputBuffer is allocated. The protocol layers identify the message 
> payload/message headers as part of AMQP frame parsing and create a 
> byte-buffer *views* onto the original input byte buffer.  This byte buffer is 
> retained by the store until the message is consumed.   In the usage pattern 
> described above, a single long lived message amongst a stream of shorted 
> lived messages causes an entire 256K buffer chunk to be retained.  Qpid 
> cannot dispose or reuse the buffer until it is entirely unoccupied.
> The flow to disk feature is designed to prevent excessive direct memory use 
> by flushing messages to disk if thresholds are breached.  Flow to disk does 
> not help the scenario described above because it considers the total payloads 
> of live messages.  Its algorithm does not consider direct memory occupancy.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (QPIDJMS-292) consumers may buffer vastly more messages than expected for their 'prefetch' value

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved QPIDJMS-292.

Resolution: Fixed

> consumers may buffer vastly more messages than expected for their 'prefetch' 
> value
> --
>
> Key: QPIDJMS-292
> URL: https://issues.apache.org/jira/browse/QPIDJMS-292
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.22.0
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.23.0
>
>
> Consumers may buffer vastly more messages than expected for their 'prefetch' 
> value.
> The consumer link credit handling is toggled via the 'prefetch' settings, 
> which aims to limit the number of messages locally buffered for the consumer, 
> protecting the consumer and enabling the server to better distribute between 
> multiple consumers as and when appropriate, particularly ones that arrive 
> later than others.
> The link credit handling however has not been correctly accounting for 
> already buffered but not yet consumed messages, but rather only the credit 
> itself at the point of inspection. As a result, if the credit is sufficiently 
> (>=70%) utilised between processing of messages, more link credit is granted 
> to top up to the 'prefetch' value, This potentially allows it to buffer more 
> than  messages, and also grant more credit even after it has 
> already done so. If there is a signficant backlog of messages available and 
> the broker can feed them to the client quickly enough, and consumption does 
> not similarly keep up, this can repeat to the extent of buffering as many 
> messages as are available.
> The only obvious workarounds would be reducing the prefetch to 0 or 1.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (QPIDJMS-292) consumers may buffer vastly more messages than expected for their 'prefetch' value

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated QPIDJMS-292:
---
Affects Version/s: 0.22.0

> consumers may buffer vastly more messages than expected for their 'prefetch' 
> value
> --
>
> Key: QPIDJMS-292
> URL: https://issues.apache.org/jira/browse/QPIDJMS-292
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.22.0
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.23.0
>
>
> Consumers may buffer vastly more messages than expected for their 'prefetch' 
> value.
> The consumer link credit handling is toggled via the 'prefetch' settings, 
> which aims to limit the number of messages locally buffered for the consumer, 
> protecting the consumer and enabling the server to better distribute between 
> multiple consumers as and when appropriate, particularly ones that arrive 
> later than others.
> The link credit handling however has not been correctly accounting for 
> already buffered but not yet consumed messages, but rather only the credit 
> itself at the point of inspection. As a result, if the credit is sufficiently 
> (>=70%) utilised between processing of messages, more link credit is granted 
> to top up to the 'prefetch' value, This potentially allows it to buffer more 
> than  messages, and also grant more credit even after it has 
> already done so. If there is a signficant backlog of messages available and 
> the broker can feed them to the client quickly enough, and consumption does 
> not similarly keep up, this can repeat to the extent of buffering as many 
> messages as are available.
> The only obvious workarounds would be reducing the prefetch to 0 or 1.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (QPIDJMS-292) consumers may buffer vastly more messages than expected for their 'prefetch' value

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDJMS-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16006221#comment-16006221
 ] 

ASF subversion and git services commented on QPIDJMS-292:
-

Commit b0b554d752f1f0320d73c7645ec89bb51677e5e6 in qpid-jms's branch 
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=b0b554d ]

QPIDJMS-292: ensure credit handling accounts for buffered messages correctly to 
prevent prefetching more than the expected number of messages


> consumers may buffer vastly more messages than expected for their 'prefetch' 
> value
> --
>
> Key: QPIDJMS-292
> URL: https://issues.apache.org/jira/browse/QPIDJMS-292
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.23.0
>
>
> Consumers may buffer vastly more messages than expected for their 'prefetch' 
> value.
> The consumer link credit handling is toggled via the 'prefetch' settings, 
> which aims to limit the number of messages locally buffered for the consumer, 
> protecting the consumer and enabling the server to better distribute between 
> multiple consumers as and when appropriate, particularly ones that arrive 
> later than others.
> The link credit handling however has not been correctly accounting for 
> already buffered but not yet consumed messages, but rather only the credit 
> itself at the point of inspection. As a result, if the credit is sufficiently 
> (>=70%) utilised between processing of messages, more link credit is granted 
> to top up to the 'prefetch' value, This potentially allows it to buffer more 
> than  messages, and also grant more credit even after it has 
> already done so. If there is a signficant backlog of messages available and 
> the broker can feed them to the client quickly enough, and consumption does 
> not similarly keep up, this can repeat to the extent of buffering as many 
> messages as are available.
> The only obvious workarounds would be reducing the prefetch to 0 or 1.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (QPIDJMS-292) consumers may buffer vastly more messages than expected for their 'prefetch' value

[Robbie Gemmell (JIRA)]

Robbie Gemmell created QPIDJMS-292:
--

 Summary: consumers may buffer vastly more messages than expected 
for their 'prefetch' value
 Key: QPIDJMS-292
 URL: https://issues.apache.org/jira/browse/QPIDJMS-292
 Project: Qpid JMS
  Issue Type: Bug
  Components: qpid-jms-client
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
 Fix For: 0.23.0


Consumers may buffer vastly more messages than expected for their 'prefetch' 
value.

The consumer link credit handling is toggled via the 'prefetch' settings, which 
aims to limit the number of messages locally buffered for the consumer, 
protecting the consumer and enabling the server to better distribute between 
multiple consumers as and when appropriate, particularly ones that arrive later 
than others.

The link credit handling however has not been correctly accounting for already 
buffered but not yet consumed messages, but rather only the credit itself at 
the point of inspection. As a result, if the credit is sufficiently (>=70%) 
utilised between processing of messages, more link credit is granted to top up 
to the 'prefetch' value, This potentially allows it to buffer more than 
 messages, and also grant more credit even after it has already done 
so. If there is a signficant backlog of messages available and the broker can 
feed them to the client quickly enough, and consumption does not similarly keep 
up, this can repeat to the extent of buffering as many messages as are 
available.

The only obvious workarounds would be reducing the prefetch to 0 or 1.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (QPID-7776) Add flow to disk queue policy

[Keith Wall (JIRA)]

Keith Wall created QPID-7776:


 Summary: Add flow to disk queue policy
 Key: QPID-7776
 URL: https://issues.apache.org/jira/browse/QPID-7776
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Keith Wall
 Fix For: qpid-java-broker-7.0.0


It should be possible to configure a queue so that enqueues are always flowed 
to disk, or are flowed to disk when the queue reaches a certain length or depth.

A common use case for this would be a user who has one queue that is used 
_store and forward_ (say for an end of day batch) whilst other queues are used 
'live'.  It will make sense for such a user for to mark the batch's queue flow 
to disk.  That way the messages on the batch queue don't needlessly clog the 
Broker's memory leaving it free for intraday work.

The C++ Broker already has an analogous feature.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (QPID-7775) Flow to disk should consider the size of the resident messages in memory.

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7775:
-
Description: 
Our current algorithm for triggering flow to disk has some shortcomings.

* the algorithm does not account for memory returned by flow to disk.
The decision to flow a message a newly arriving message to disk
considers only the queue's target size and queue's depth.  Once a
queue depth is over its target, all messages will go to disk even if
all messages have actually been flowed to disk.  The same is true
after recovery: flow to disk will be enabled even though there are no
messages in RAM.

* the fact that a queue's target size is assigned by periodically by
housekeeping means that the queues target size can be wrong for most
of the time.  This is very apparent if a queue is growing; you
actually see *most* messages flowing to disk even when there is ample
memory.  The target size is periodically recomputed but only remains
correct for an instant, the queue returns to the flow to disk state as
more messages are added.   We see this during perf test runs.

We will change the MessageStore so that it tracks the size of the messages that 
are held resident in memory.The flow to disk algorithm will be change to by 
triggered when the resident memory exceeds the virtual host's target size.

This work is likely to fully replace the recent work done on QPID-7770.


  was:
Our current algorithm for triggering flow to disk has some shortcomings.

* the algorithm does not account for memory returned by flow to disk.
The decision to flow a message a newly arriving message to disk
considers only the queue's target size and queue's depth.  Once a
queue depth is over its target, all messages will go to disk even if
all messages have actually been flowed to disk.  The same is true
after recovery: flow to disk will be enabled even though there are no
messages in RAM.

* the fact that a queue's target size is assigned by periodically by
housekeeping means that the queues target size can be wrong for most
of the time.  This is very apparent if a queue is growing; you
actually see *most* messages flowing to disk even when there is ample
memory.  The target size is periodically recomputed but only remains
correct for an instant, the queue returns to the flow to disk state as
more messages are added.   We see this during perf test runs.

We will change the MessageStore so that it tracks the size of the messages that 
are held resident in memory.The flow to disk algorithm will be change to by 
triggered when the resident memory exceeds the virtual host's target size.


> Flow to disk should consider the size of the resident messages in memory.
> -
>
> Key: QPID-7775
> URL: https://issues.apache.org/jira/browse/QPID-7775
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Our current algorithm for triggering flow to disk has some shortcomings.
> * the algorithm does not account for memory returned by flow to disk.
> The decision to flow a message a newly arriving message to disk
> considers only the queue's target size and queue's depth.  Once a
> queue depth is over its target, all messages will go to disk even if
> all messages have actually been flowed to disk.  The same is true
> after recovery: flow to disk will be enabled even though there are no
> messages in RAM.
> * the fact that a queue's target size is assigned by periodically by
> housekeeping means that the queues target size can be wrong for most
> of the time.  This is very apparent if a queue is growing; you
> actually see *most* messages flowing to disk even when there is ample
> memory.  The target size is periodically recomputed but only remains
> correct for an instant, the queue returns to the flow to disk state as
> more messages are added.   We see this during perf test runs.
> We will change the MessageStore so that it tracks the size of the messages 
> that are held resident in memory.The flow to disk algorithm will be 
> change to by triggered when the resident memory exceeds the virtual host's 
> target size.
> This work is likely to fully replace the recent work done on QPID-7770.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (QPID-7775) Flow to disk should consider the size of the resident messages in memory.

[Keith Wall (JIRA)]

Keith Wall created QPID-7775:


 Summary: Flow to disk should consider the size of the resident 
messages in memory.
 Key: QPID-7775
 URL: https://issues.apache.org/jira/browse/QPID-7775
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Keith Wall
 Fix For: qpid-java-broker-7.0.0


Our current algorithm for triggering flow to disk has some shortcomings.

* the algorithm does not account for memory returned by flow to disk.
The decision to flow a message a newly arriving message to disk
considers only the queue's target size and queue's depth.  Once a
queue depth is over its target, all messages will go to disk even if
all messages have actually been flowed to disk.  The same is true
after recovery: flow to disk will be enabled even though there are no
messages in RAM.

* the fact that a queue's target size is assigned by periodically by
housekeeping means that the queues target size can be wrong for most
of the time.  This is very apparent if a queue is growing; you
actually see *most* messages flowing to disk even when there is ample
memory.  The target size is periodically recomputed but only remains
correct for an instant, the queue returns to the flow to disk state as
more messages are added.   We see this during perf test runs.

We will change the MessageStore so that it tracks the size of the messages that 
are held resident in memory.The flow to disk algorithm will be change to by 
triggered when the resident memory exceeds the virtual host's target size.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Reopened] (QPID-7634) [Java Broker,amqp 1.0] Broker does not respond to Flow command with drain=true if queue is empty and prefetch is 0

[Rob Godfrey (JIRA)]

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

Rob Godfrey reopened QPID-7634:
---

> [Java Broker,amqp 1.0] Broker does not respond to Flow command with 
> drain=true if queue is empty and prefetch is 0
> --
>
> Key: QPID-7634
> URL: https://issues.apache.org/jira/browse/QPID-7634
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> When AMQP 1.0 client sends the Flow command with drain=true and queue is 
> empty the Broker does not respond if prefetch is 0.
> The following snippet reproduces the issue
> {code}
> Connection connection = factory.createConnection(username, password);
> connection.start();
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> MessageConsumer messageConsumer = session.createConsumer(queue);
> TextMessage receivedMessage = (TextMessage) messageConsumer.receiveNoWait(); 
> // <-- times out
> {code}
> The broker logs
> {noformat}
> 2017-01-24 11:05:56,471 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - 
> RECV[/127.0.0.1:51108|1] : 
> Attach{name=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,handle=1,role=receiver,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{address=queue,durable=none,expiryPolicy=link-detach,timeout=0,dynamic=false,defaultOutcome=Modified{deliveryFailed=true},outcomes=[amqp:accepted:list,
>  amqp:rejected:list, amqp:released:list, 
> amqp:modified:list],capabilities=[queue, global]},target=Target{}}
> 2017-01-24 11:05:56,474 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Performing Task['add consumer' on 'queue' 
> with arguments 
> 'target=ConsumerTarget_1_0[linkSession=[con:7(admin@/127.0.0.1:51108/default)/ch:1]
>  ], 
> consumerName=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  optionSet=[ACQUIRES, SEES_REQUEUES]']
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER, returing 
> default: ALLOWED
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Performing Task['open' on 
> 'Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
> name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  type=Consumer]']
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Task['open' on 
> 'Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
> name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  type=Consumer]'] performed successfully with result: null
> 2017-01-24 11:05:56,476 INFO  [VirtualHostNode-default-Config] (q.m.s.create) 
> - [con:7(admin@/127.0.0.1:51108/default)/ch:1] [sub:7(vh(/default)/qu(queue)] 
> SUB-1001 : Create
> 2017-01-24 11:05:56,476 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Task['add consumer' on 'queue' with 
> arguments 
> 'target=ConsumerTarget_1_0[linkSession=[con:7(admin@/127.0.0.1:51108/default)/ch:1]
>  ], 
> consumerName=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  optionSet=[ACQUIRES, SEES_REQUEUES]'] performed successfully with result: 
> Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
> name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  type=Consumer]
> 2017-01-24 11:05:56,477 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - 
> SEND[/127.0.0.1:51108|1] : 
> Attach{name=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,handle=1,role=sender,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{address=queue,durable=none,expiryPolicy=link-detach,timeout=0,dynamic=false,defaultOutcome=Modified{deliveryFailed=true},outcomes=[amqp:accepted:list,
>  amqp:rejected:list, amqp:released:list, 
> amqp:modified:list],capabilities=[queue]},target=Target{},initialDeliveryCount=0,offeredCapabilities=[SHARED-SUBS],properties={}}
> 2017-01-24 11:05:56,477 DEBUG [IO-/127.0.0.1:51108] 
> (o.a.q.s.t.NonBlockingConnection) - Written 251 bytes
> 2017-01-24 11:05:56,477 DEBUG [IO-/127.0.0.1:51108] 
> (o.a.q.s.t.NonBlockingConnection) - Read 0 byte(s)
> 2017-01-24 11:05:56,487 DEBUG [IO-/127.0.0.1:51108] 
> (o.a.q.s.t.NonBlockingConnection) - Read 34 byte(s)
> 2017-01-24 11:05:56,487 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - 
> RECV[/127.0.0.1:51108|1] : 
> 

[jira] [Commented] (QPID-7634) [Java Broker,amqp 1.0] Broker does not respond to Flow command with drain=true if queue is empty and prefetch is 0

[Rob Godfrey (JIRA)]

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

Rob Godfrey commented on QPID-7634:
---

I don't believe this change is correct.

The change seems to make the assumption that the flow(drain=true) should be 
treated like a synchronous request/response action… when it really should be an 
asynchronous/state modification thing, where the broker eventually tells the 
client when its state has changed.  This causes an issue where a drain is 
issued with a remaining link credit of X, and there are at least X messages 
available to be sent on the link, but the session does not have sufficient 
session credit to transfer all those messages.  In this case the broker should 
send as many transfers as it currently can and then wait until it receives more 
session credit.  Only if the queue becomes empty should the delivery count 
actually be advanced.

An interesting question is whether the "issue" identified is actually an issue 
at all.  The client issues a drain on a link with zero credit... which means 
that the delivery count is already advanced.  In this case I do not believe it 
should be necessary for the server to echo a drain back, however the wording of 
the spec does not seem to take this case into account... so perhaps we should 
simply treat this case as an "echo" request. 

> [Java Broker,amqp 1.0] Broker does not respond to Flow command with 
> drain=true if queue is empty and prefetch is 0
> --
>
> Key: QPID-7634
> URL: https://issues.apache.org/jira/browse/QPID-7634
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> When AMQP 1.0 client sends the Flow command with drain=true and queue is 
> empty the Broker does not respond if prefetch is 0.
> The following snippet reproduces the issue
> {code}
> Connection connection = factory.createConnection(username, password);
> connection.start();
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> MessageConsumer messageConsumer = session.createConsumer(queue);
> TextMessage receivedMessage = (TextMessage) messageConsumer.receiveNoWait(); 
> // <-- times out
> {code}
> The broker logs
> {noformat}
> 2017-01-24 11:05:56,471 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - 
> RECV[/127.0.0.1:51108|1] : 
> Attach{name=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,handle=1,role=receiver,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{address=queue,durable=none,expiryPolicy=link-detach,timeout=0,dynamic=false,defaultOutcome=Modified{deliveryFailed=true},outcomes=[amqp:accepted:list,
>  amqp:rejected:list, amqp:released:list, 
> amqp:modified:list],capabilities=[queue, global]},target=Target{}}
> 2017-01-24 11:05:56,474 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Performing Task['add consumer' on 'queue' 
> with arguments 
> 'target=ConsumerTarget_1_0[linkSession=[con:7(admin@/127.0.0.1:51108/default)/ch:1]
>  ], 
> consumerName=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  optionSet=[ACQUIRES, SEES_REQUEUES]']
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER, returing 
> default: ALLOWED
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Performing Task['open' on 
> 'Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
> name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  type=Consumer]']
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Task['open' on 
> 'Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
> name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  type=Consumer]'] performed successfully with result: null
> 2017-01-24 11:05:56,476 INFO  [VirtualHostNode-default-Config] (q.m.s.create) 
> - [con:7(admin@/127.0.0.1:51108/default)/ch:1] [sub:7(vh(/default)/qu(queue)] 
> SUB-1001 : Create
> 2017-01-24 11:05:56,476 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Task['add consumer' on 'queue' with 
> arguments 
> 'target=ConsumerTarget_1_0[linkSession=[con:7(admin@/127.0.0.1:51108/default)/ch:1]
>  ], 
> consumerName=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  optionSet=[ACQUIRES, SEES_REQUEUES]'] performed successfully with result: 
> 

[jira] [Commented] (QPID-7767) Unknown endpoint Transfer issue on AMQP Connection

[Kapila Arora (JIRA)]

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

Kapila Arora commented on QPID-7767:


Thanks Rob for helping us on raised issue. I know , We still have some issues 
with re-delivered messages with Azure Service Bus Peek-Lock and QPID JMS 0.11.1 
communication and many messages are moving in the Azure service bus 
deadletterqueue as well. Looking some help on this one .

> Unknown endpoint Transfer issue on AMQP Connection
> --
>
> Key: QPID-7767
> URL: https://issues.apache.org/jira/browse/QPID-7767
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: 0.32
> Environment: AMQP Client  - Qpid 0.32 runs on Java run time 1.7 on 
> Linux box  on softLayer
> AMQP Server -   Azure Service bus on Public cloud
>Reporter: Kapila Arora
>Priority: Critical
> Attachments: 
> apacheQpidJMS0.11.1_protocolLog_withDelivery34_DataMasking.log, 
> Qpid_error_log.txt
>
>
> Getting Errors in the AMQP Client 
> 2017-05-03 06:45:15.048212 Unknown endpoint 
> Transfer{handle=0,deliveryId=2,deliveryTag=\xf3\x99\x90\x5cL\xb1\xdeF\x9da\xa3o\xb0\x5cdm,messageFormat=0,more=true,batchable=true}
> Data Packets 
> Unknown endpoint 
> Transfer{handle=0,deliveryId=2,deliveryTag=\xf3\x99\x90\x5cL\xb1\xdeF\x9da\xa3o\xb0\x5cdm,messageFormat=0,more=true,batchable=true}
> 2017-05-03 06:45:15.396212 Unknown endpoint Transfer{handle=0,more=false}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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