[jira] [Commented] (DISPATCH-89) Model the legacy topic exchange behavior of qpidd

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-89:


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

https://github.com/apache/qpid-dispatch/pull/244#discussion_r161905217
  
--- Diff: tests/system_tests_exchange_bindings.py ---
@@ -0,0 +1,676 @@
+#
+# 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.
+#
+
+import ast
+import unittest2 as unittest
+from threading import Thread
+from time import sleep
+from subprocess import PIPE, STDOUT
+
+try:
+import Queue as Queue   # 2.7
+except ImportError:
+import queue as Queue   # 3.x
+
+from system_test import TestCase, Qdrouterd, main_module, TIMEOUT, Process
+from proton import Message, Timeout
+from proton.reactor import AtMostOnce, AtLeastOnce
+from proton.utils import BlockingConnection, SendException
+
+# TIMEOUT=5
+_EXCHANGE_TYPE = "org.apache.qpid.dispatch.router.config.exchange"
+_BINDING_TYPE  = "org.apache.qpid.dispatch.router.config.binding"
+
+
+class _AsyncReceiver(object):
+def __init__(self, address, source, credit=100, timeout=0.1):
+super(_AsyncReceiver, self).__init__()
+self.conn = BlockingConnection(address)
+self.rcvr = self.conn.create_receiver(address=source, 
credit=credit)
+self.thread = Thread(target=self._poll)
+self.queue = Queue.Queue()
+self._run = True
+self._timeout = timeout
+self.thread.start()
+
+def _poll(self):
+while self._run:
+try:
+msg = self.rcvr.receive(timeout=self._timeout)
+except Timeout:
+continue
+try:
+self.rcvr.accept()
+except IndexError:
+# PROTON-1743
+pass
+self.queue.put(msg)
+self.rcvr.close()
+self.conn.close()
+
+def stop(self):
+self._run = False
+self.thread.join(timeout=TIMEOUT)
+
+
+class ExchangeBindingsTest(TestCase):
+"""
+Tests the exchange/bindings of the dispatch router.
+"""
+def _create_router(self, name, config):
+
+config = [
+('router',   {'mode': 'standalone', 'id': 'QDR.%s'%name}),
+('listener', {'role': 'normal', 'host': '0.0.0.0',
+  'port': self.tester.get_port(),
+  'saslMechanisms':'ANONYMOUS'})
+] + config
+return self.tester.qdrouterd(name, Qdrouterd.Config(config))
+
+def run_qdmanage(self, router, cmd, input=None, 
expect=Process.EXIT_OK):
+p = self.popen(
+['qdmanage'] + cmd.split(' ')
++ ['--bus', router.addresses[0], '--indent=-1', '--timeout', 
str(TIMEOUT)],
+stdin=PIPE, stdout=PIPE, stderr=STDOUT, expect=expect)
+out = p.communicate(input)[0]
+try:
+p.teardown()
+except Exception, e:
+raise Exception("%s\n%s" % (e, out))
+return out
+
+def _validate_entity(self, name, kind, entities, expected):
+for entity in entities:
+if "name" in entity and entity["name"] == name:
+for k,v in expected.items():
+self.assertTrue(k in entity)
+self.assertEqual(v, entity[k])
+return;
--- End diff --

Heh.  One a C coder, always a C coder...


> Model the legacy topic exchange behavior of qpidd
> -
>
> Key: DISPATCH-89
> URL: https://issues.apache.org/jira/browse/DISPATCH-89
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Routing 

[GitHub] qpid-dispatch pull request #244: DISPATCH-89: Exchange Binding forwarder (ex...

[kgiusti]

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

https://github.com/apache/qpid-dispatch/pull/244#discussion_r161905217
  
--- Diff: tests/system_tests_exchange_bindings.py ---
@@ -0,0 +1,676 @@
+#
+# 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.
+#
+
+import ast
+import unittest2 as unittest
+from threading import Thread
+from time import sleep
+from subprocess import PIPE, STDOUT
+
+try:
+import Queue as Queue   # 2.7
+except ImportError:
+import queue as Queue   # 3.x
+
+from system_test import TestCase, Qdrouterd, main_module, TIMEOUT, Process
+from proton import Message, Timeout
+from proton.reactor import AtMostOnce, AtLeastOnce
+from proton.utils import BlockingConnection, SendException
+
+# TIMEOUT=5
+_EXCHANGE_TYPE = "org.apache.qpid.dispatch.router.config.exchange"
+_BINDING_TYPE  = "org.apache.qpid.dispatch.router.config.binding"
+
+
+class _AsyncReceiver(object):
+def __init__(self, address, source, credit=100, timeout=0.1):
+super(_AsyncReceiver, self).__init__()
+self.conn = BlockingConnection(address)
+self.rcvr = self.conn.create_receiver(address=source, 
credit=credit)
+self.thread = Thread(target=self._poll)
+self.queue = Queue.Queue()
+self._run = True
+self._timeout = timeout
+self.thread.start()
+
+def _poll(self):
+while self._run:
+try:
+msg = self.rcvr.receive(timeout=self._timeout)
+except Timeout:
+continue
+try:
+self.rcvr.accept()
+except IndexError:
+# PROTON-1743
+pass
+self.queue.put(msg)
+self.rcvr.close()
+self.conn.close()
+
+def stop(self):
+self._run = False
+self.thread.join(timeout=TIMEOUT)
+
+
+class ExchangeBindingsTest(TestCase):
+"""
+Tests the exchange/bindings of the dispatch router.
+"""
+def _create_router(self, name, config):
+
+config = [
+('router',   {'mode': 'standalone', 'id': 'QDR.%s'%name}),
+('listener', {'role': 'normal', 'host': '0.0.0.0',
+  'port': self.tester.get_port(),
+  'saslMechanisms':'ANONYMOUS'})
+] + config
+return self.tester.qdrouterd(name, Qdrouterd.Config(config))
+
+def run_qdmanage(self, router, cmd, input=None, 
expect=Process.EXIT_OK):
+p = self.popen(
+['qdmanage'] + cmd.split(' ')
++ ['--bus', router.addresses[0], '--indent=-1', '--timeout', 
str(TIMEOUT)],
+stdin=PIPE, stdout=PIPE, stderr=STDOUT, expect=expect)
+out = p.communicate(input)[0]
+try:
+p.teardown()
+except Exception, e:
+raise Exception("%s\n%s" % (e, out))
+return out
+
+def _validate_entity(self, name, kind, entities, expected):
+for entity in entities:
+if "name" in entity and entity["name"] == name:
+for k,v in expected.items():
+self.assertTrue(k in entity)
+self.assertEqual(v, entity[k])
+return;
--- End diff --

Heh.  One a C coder, always a C coder...


---

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

[GitHub] qpid-dispatch pull request #244: DISPATCH-89: Exchange Binding forwarder (ex...

[kgiusti]

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

https://github.com/apache/qpid-dispatch/pull/244#discussion_r161904967
  
--- Diff: src/router_core/exchange_bindings.c ---
@@ -0,0 +1,1336 @@
+/*
+ * 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.
+ */
+#include 
+#include 
+#include 
+#include "router_core_private.h"
+#include "exchange_bindings.h"
+
+
+// next_hop_t
+// Describes the destination of a forwarded message
+// May be shared by different bindings
+//
+typedef struct next_hop_t next_hop_t;
+struct next_hop_t
+{
+// per-exchange list of all next hops
+DEQ_LINKS_N(exchange_list, next_hop_t);
+// when hooked to the transmit list
+DEQ_LINKS_N(transmit_list, next_hop_t);
+
+int  ref_count;  // binding references
+int  phase;
+bool on_xmit_list;
+qdr_exchange_t  *exchange;
+qd_iterator_t   *next_hop;
+unsigned char   *next_hop_str;
+qdr_address_t   *qdr_addr;
+};
+
+ALLOC_DECLARE(next_hop_t);
+ALLOC_DEFINE(next_hop_t);
+DEQ_DECLARE(next_hop_t, next_hop_list_t);
+
+// qdr_binding_t
+// Represents a subject key --> next hop mapping
+// A binding is uniquely identified by the tuple (pattern, nextHop, 
phase).  No
+// two bindings with the same tuple value can exist on an exchange.
+// The binding is implemented using two classes: qdr_binding_t and
+// next_hop_t. The qdr_binding_t holds the pattern and points to the
+// next_hop_t.  This allows different patterns to share the same nextHop.
+// Since there is only one next_hop_t instance for each (nextHop, phase) 
value,
+// we guarantee only 1 copy of a message is forwarded to a given 
nextHop+phase
+// even if multiple distinct patterns are matched. Ex: a message with a
+// value of "a.b" will match two distict binding keys "+.b" and "a.+".  If
+// both these patterns share the same next_hop_t only 1 copy of the message
+// will be forwarded.
+typedef struct qdr_binding qdr_binding_t;
+struct qdr_binding
+{
+// per-exchange list of all bindings
+DEQ_LINKS_N(exchange_list, qdr_binding_t);
+// parse tree node's list of bindings sharing the same pattern
+DEQ_LINKS_N(tree_list, qdr_binding_t);
+
+qd_iterator_t   *name;
+unsigned char   *name_str;
+uint64_t identity;
+qdr_exchange_t  *exchange;
+
+// the routing key
+qd_iterator_t   *key;
+unsigned char   *key_str;
+next_hop_t  *next_hop;
+
+uint64_t msgs_matched;
+};
+
+ALLOC_DECLARE(qdr_binding_t);
+ALLOC_DEFINE(qdr_binding_t);
+DEQ_DECLARE(qdr_binding_t, qdr_binding_list_t);
+
+
+struct qdr_exchange {
+DEQ_LINKS(qdr_exchange_t);  // for core->exchanges
+qdr_core_t *core;
+uint64_tidentity;
+qd_iterator_t  *name;
+unsigned char  *name_str;
+qd_iterator_t  *address;
+unsigned char  *address_str;
+int phase;
+qd_parse_tree_t*parse_tree;
+qdr_address_t  *qdr_addr;
+next_hop_t *alternate;
+qdr_binding_list_t  bindings;
+next_hop_list_t next_hops;
+
+uint64_t msgs_received;
+uint64_t msgs_dropped;
+uint64_t msgs_routed;
+uint64_t msgs_alternate;
+};
+
+ALLOC_DECLARE(qdr_exchange_t);
+ALLOC_DEFINE(qdr_exchange_t);
+
+static void qdr_exchange_free(qdr_exchange_t *ex);
+static qdr_exchange_t *qdr_exchange(qdr_core_t*core,
+qd_iterator_t *name,
+qd_iterator_t *address,
+intphase,
+qd_iterator_t *alternate,
+int

[jira] [Updated] (DISPATCH-915) connection rhost not calculated soon enough

[Chuck Rolke (JIRA)]

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

Chuck Rolke updated DISPATCH-915:
-
Summary: connection rhost  not calculated soon enough  (was: connectoin 
rhost  not calculated soon enough)

> connection rhost  not calculated soon enough
> 
>
> Key: DISPATCH-915
> URL: https://issues.apache.org/jira/browse/DISPATCH-915
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Policy Engine
>Affects Versions: 1.1.0
> Environment: Fedora 25
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
>
> In DISPATCH-912 the rhost extraction was done earlier so that self tests 
> would pass. The extraction needs to be done even earlier so that the policy 
> engine properly accounts for connection life cycles. As-is there is most 
> likely a memory leak. In 0.8.x connections are created and destroyed under 
> the same name. In current master they are created with blank name and 
> destroyed with a non-blank name.
> {noformat}
> 0.8.x
> =
> 2018-01-16 15:52:15.367634 -0500 POLICY (trace) ALLOW Connection 
> '10.18.96.1:60660' based on global connection count. nConnections= 1 
> (/home/chug/git/qpid-dispatch/src/policy.c:197)
> 2018-01-16 15:52:15.369923 -0500 POLICY (trace) ALLOW AMQP Open lookup_user: 
> anonymous, rhost: 10.18.96.1, vhost: 10.3.116.250, connection: 
> 10.18.96.1:60660. Usergroup: '$default' 
> (/home/chug/git/qpid-dispatch/src/policy.c:356)
> 2018-01-16 15:52:15.372801 -0500 POLICY (trace) ALLOW AMQP Begin Session. 
> user: anonymous, rhost: 10.18.96.1, vhost: 10.3.116.250 
> (/home/chug/git/qpid-dispatch/src/policy.c:411)
> 2018-01-16 15:52:15.374975 -0500 POLICY (trace) ALLOW AMQP Attach receiver 
> link 'q1' for user 'anonymous', rhost '10.18.96.1', vhost '10.3.116.250' 
> based on link source name (/home/chug/git/qpid-dispatch/src/policy.c:665)
> 2018-01-16 15:52:15.378168 -0500 POLICY (trace) ALLOW AMQP Attach sender link 
> 'q1' for user 'anonymous', rhost '10.18.96.1', vhost '10.3.116.250' based on 
> link target name (/home/chug/git/qpid-dispatch/src/policy.c:603)
> 2018-01-16 15:52:16.596565 -0500 POLICY (debug) Connection '10.18.96.1:60660' 
> closed with resources n_sessions=0, n_senders=0, n_receivers=0. nConnections= 
> 0. (/home/chug/git/qpid-dispatch/src/policy.c:244)
> master (3c403)
> ==
> 2018-01-16 15:47:28.992716 -0500 POLICY (trace) ALLOW Connection '' based on 
> global connection count. nConnections= 1 
> (/home/chug/git/qpid-dispatch/src/policy.c:193)
> 2018-01-16 15:47:29.20329 -0500 POLICY (trace) ALLOW AMQP Open lookup_user: 
> anonymous, rhost: 10.18.96.1, vhost: 10.3.116.250, connection: 
> 10.18.96.1:60622. Usergroup: '$default' 
> (/home/chug/git/qpid-dispatch/src/policy.c:351)
> 2018-01-16 15:47:29.35062 -0500 POLICY (trace) ALLOW AMQP Begin Session. 
> user: anonymous, rhost: 10.18.96.1, vhost: 10.3.116.250 
> (/home/chug/git/qpid-dispatch/src/policy.c:406)
> 2018-01-16 15:47:29.37329 -0500 POLICY (trace) ALLOW AMQP Attach receiver 
> link 'q1' for user 'anonymous', rhost '10.18.96.1', vhost '10.3.116.250' 
> based on link source name (/home/chug/git/qpid-dispatch/src/policy.c:659)
> 2018-01-16 15:47:29.38853 -0500 POLICY (trace) ALLOW AMQP Attach sender link 
> 'q1' for user 'anonymous', rhost '10.18.96.1', vhost '10.3.116.250' based on 
> link target name (/home/chug/git/qpid-dispatch/src/policy.c:597)
> 2018-01-16 15:47:30.20830 -0500 POLICY (debug) Connection '10.18.96.1:60622' 
> closed with resources n_sessions=0, n_senders=0, n_receivers=0. nConnections= 
> 0. (/home/chug/git/qpid-dispatch/src/policy.c:238){noformat}



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

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

[jira] [Created] (DISPATCH-915) connectoin rhost not calculated soon enough

[Chuck Rolke (JIRA)]

Chuck Rolke created DISPATCH-915:


 Summary: connectoin rhost  not calculated soon enough
 Key: DISPATCH-915
 URL: https://issues.apache.org/jira/browse/DISPATCH-915
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Policy Engine
Affects Versions: 1.1.0
 Environment: Fedora 25
Reporter: Chuck Rolke
Assignee: Chuck Rolke


In DISPATCH-912 the rhost extraction was done earlier so that self tests would 
pass. The extraction needs to be done even earlier so that the policy engine 
properly accounts for connection life cycles. As-is there is most likely a 
memory leak. In 0.8.x connections are created and destroyed under the same 
name. In current master they are created with blank name and destroyed with a 
non-blank name.
{noformat}
0.8.x
=
2018-01-16 15:52:15.367634 -0500 POLICY (trace) ALLOW Connection 
'10.18.96.1:60660' based on global connection count. nConnections= 1 
(/home/chug/git/qpid-dispatch/src/policy.c:197)
2018-01-16 15:52:15.369923 -0500 POLICY (trace) ALLOW AMQP Open lookup_user: 
anonymous, rhost: 10.18.96.1, vhost: 10.3.116.250, connection: 
10.18.96.1:60660. Usergroup: '$default' 
(/home/chug/git/qpid-dispatch/src/policy.c:356)
2018-01-16 15:52:15.372801 -0500 POLICY (trace) ALLOW AMQP Begin Session. user: 
anonymous, rhost: 10.18.96.1, vhost: 10.3.116.250 
(/home/chug/git/qpid-dispatch/src/policy.c:411)
2018-01-16 15:52:15.374975 -0500 POLICY (trace) ALLOW AMQP Attach receiver link 
'q1' for user 'anonymous', rhost '10.18.96.1', vhost '10.3.116.250' based on 
link source name (/home/chug/git/qpid-dispatch/src/policy.c:665)
2018-01-16 15:52:15.378168 -0500 POLICY (trace) ALLOW AMQP Attach sender link 
'q1' for user 'anonymous', rhost '10.18.96.1', vhost '10.3.116.250' based on 
link target name (/home/chug/git/qpid-dispatch/src/policy.c:603)
2018-01-16 15:52:16.596565 -0500 POLICY (debug) Connection '10.18.96.1:60660' 
closed with resources n_sessions=0, n_senders=0, n_receivers=0. nConnections= 
0. (/home/chug/git/qpid-dispatch/src/policy.c:244)

master (3c403)
==
2018-01-16 15:47:28.992716 -0500 POLICY (trace) ALLOW Connection '' based on 
global connection count. nConnections= 1 
(/home/chug/git/qpid-dispatch/src/policy.c:193)
2018-01-16 15:47:29.20329 -0500 POLICY (trace) ALLOW AMQP Open lookup_user: 
anonymous, rhost: 10.18.96.1, vhost: 10.3.116.250, connection: 
10.18.96.1:60622. Usergroup: '$default' 
(/home/chug/git/qpid-dispatch/src/policy.c:351)
2018-01-16 15:47:29.35062 -0500 POLICY (trace) ALLOW AMQP Begin Session. user: 
anonymous, rhost: 10.18.96.1, vhost: 10.3.116.250 
(/home/chug/git/qpid-dispatch/src/policy.c:406)
2018-01-16 15:47:29.37329 -0500 POLICY (trace) ALLOW AMQP Attach receiver link 
'q1' for user 'anonymous', rhost '10.18.96.1', vhost '10.3.116.250' based on 
link source name (/home/chug/git/qpid-dispatch/src/policy.c:659)
2018-01-16 15:47:29.38853 -0500 POLICY (trace) ALLOW AMQP Attach sender link 
'q1' for user 'anonymous', rhost '10.18.96.1', vhost '10.3.116.250' based on 
link target name (/home/chug/git/qpid-dispatch/src/policy.c:597)
2018-01-16 15:47:30.20830 -0500 POLICY (debug) Connection '10.18.96.1:60622' 
closed with resources n_sessions=0, n_senders=0, n_receivers=0. nConnections= 
0. (/home/chug/git/qpid-dispatch/src/policy.c:238){noformat}



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

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

[jira] [Commented] (DISPATCH-89) Model the legacy topic exchange behavior of qpidd

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-89:


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

https://github.com/apache/qpid-dispatch/pull/244#discussion_r161897073
  
--- Diff: tests/system_tests_exchange_bindings.py ---
@@ -0,0 +1,676 @@
+#
+# 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.
+#
+
+import ast
+import unittest2 as unittest
+from threading import Thread
+from time import sleep
+from subprocess import PIPE, STDOUT
+
+try:
+import Queue as Queue   # 2.7
+except ImportError:
+import queue as Queue   # 3.x
+
+from system_test import TestCase, Qdrouterd, main_module, TIMEOUT, Process
+from proton import Message, Timeout
+from proton.reactor import AtMostOnce, AtLeastOnce
+from proton.utils import BlockingConnection, SendException
+
+# TIMEOUT=5
+_EXCHANGE_TYPE = "org.apache.qpid.dispatch.router.config.exchange"
+_BINDING_TYPE  = "org.apache.qpid.dispatch.router.config.binding"
+
+
+class _AsyncReceiver(object):
+def __init__(self, address, source, credit=100, timeout=0.1):
+super(_AsyncReceiver, self).__init__()
+self.conn = BlockingConnection(address)
+self.rcvr = self.conn.create_receiver(address=source, 
credit=credit)
+self.thread = Thread(target=self._poll)
+self.queue = Queue.Queue()
+self._run = True
+self._timeout = timeout
+self.thread.start()
+
+def _poll(self):
+while self._run:
+try:
+msg = self.rcvr.receive(timeout=self._timeout)
+except Timeout:
+continue
+try:
+self.rcvr.accept()
+except IndexError:
+# PROTON-1743
+pass
+self.queue.put(msg)
+self.rcvr.close()
+self.conn.close()
+
+def stop(self):
+self._run = False
+self.thread.join(timeout=TIMEOUT)
+
+
+class ExchangeBindingsTest(TestCase):
+"""
+Tests the exchange/bindings of the dispatch router.
+"""
+def _create_router(self, name, config):
+
+config = [
+('router',   {'mode': 'standalone', 'id': 'QDR.%s'%name}),
+('listener', {'role': 'normal', 'host': '0.0.0.0',
+  'port': self.tester.get_port(),
+  'saslMechanisms':'ANONYMOUS'})
+] + config
+return self.tester.qdrouterd(name, Qdrouterd.Config(config))
+
+def run_qdmanage(self, router, cmd, input=None, 
expect=Process.EXIT_OK):
+p = self.popen(
+['qdmanage'] + cmd.split(' ')
++ ['--bus', router.addresses[0], '--indent=-1', '--timeout', 
str(TIMEOUT)],
+stdin=PIPE, stdout=PIPE, stderr=STDOUT, expect=expect)
+out = p.communicate(input)[0]
+try:
+p.teardown()
+except Exception, e:
+raise Exception("%s\n%s" % (e, out))
+return out
+
+def _validate_entity(self, name, kind, entities, expected):
+for entity in entities:
+if "name" in entity and entity["name"] == name:
+for k,v in expected.items():
+self.assertTrue(k in entity)
+self.assertEqual(v, entity[k])
+return;
--- End diff --

No semi colon here


> Model the legacy topic exchange behavior of qpidd
> -
>
> Key: DISPATCH-89
> URL: https://issues.apache.org/jira/browse/DISPATCH-89
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Routing Engine
>Affects 

[GitHub] qpid-dispatch pull request #244: DISPATCH-89: Exchange Binding forwarder (ex...

[ganeshmurthy]

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

https://github.com/apache/qpid-dispatch/pull/244#discussion_r161897073
  
--- Diff: tests/system_tests_exchange_bindings.py ---
@@ -0,0 +1,676 @@
+#
+# 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.
+#
+
+import ast
+import unittest2 as unittest
+from threading import Thread
+from time import sleep
+from subprocess import PIPE, STDOUT
+
+try:
+import Queue as Queue   # 2.7
+except ImportError:
+import queue as Queue   # 3.x
+
+from system_test import TestCase, Qdrouterd, main_module, TIMEOUT, Process
+from proton import Message, Timeout
+from proton.reactor import AtMostOnce, AtLeastOnce
+from proton.utils import BlockingConnection, SendException
+
+# TIMEOUT=5
+_EXCHANGE_TYPE = "org.apache.qpid.dispatch.router.config.exchange"
+_BINDING_TYPE  = "org.apache.qpid.dispatch.router.config.binding"
+
+
+class _AsyncReceiver(object):
+def __init__(self, address, source, credit=100, timeout=0.1):
+super(_AsyncReceiver, self).__init__()
+self.conn = BlockingConnection(address)
+self.rcvr = self.conn.create_receiver(address=source, 
credit=credit)
+self.thread = Thread(target=self._poll)
+self.queue = Queue.Queue()
+self._run = True
+self._timeout = timeout
+self.thread.start()
+
+def _poll(self):
+while self._run:
+try:
+msg = self.rcvr.receive(timeout=self._timeout)
+except Timeout:
+continue
+try:
+self.rcvr.accept()
+except IndexError:
+# PROTON-1743
+pass
+self.queue.put(msg)
+self.rcvr.close()
+self.conn.close()
+
+def stop(self):
+self._run = False
+self.thread.join(timeout=TIMEOUT)
+
+
+class ExchangeBindingsTest(TestCase):
+"""
+Tests the exchange/bindings of the dispatch router.
+"""
+def _create_router(self, name, config):
+
+config = [
+('router',   {'mode': 'standalone', 'id': 'QDR.%s'%name}),
+('listener', {'role': 'normal', 'host': '0.0.0.0',
+  'port': self.tester.get_port(),
+  'saslMechanisms':'ANONYMOUS'})
+] + config
+return self.tester.qdrouterd(name, Qdrouterd.Config(config))
+
+def run_qdmanage(self, router, cmd, input=None, 
expect=Process.EXIT_OK):
+p = self.popen(
+['qdmanage'] + cmd.split(' ')
++ ['--bus', router.addresses[0], '--indent=-1', '--timeout', 
str(TIMEOUT)],
+stdin=PIPE, stdout=PIPE, stderr=STDOUT, expect=expect)
+out = p.communicate(input)[0]
+try:
+p.teardown()
+except Exception, e:
+raise Exception("%s\n%s" % (e, out))
+return out
+
+def _validate_entity(self, name, kind, entities, expected):
+for entity in entities:
+if "name" in entity and entity["name"] == name:
+for k,v in expected.items():
+self.assertTrue(k in entity)
+self.assertEqual(v, entity[k])
+return;
--- End diff --

No semi colon here


---

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

[GitHub] qpid-dispatch pull request #244: DISPATCH-89: Exchange Binding forwarder (ex...

[ganeshmurthy]

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

https://github.com/apache/qpid-dispatch/pull/244#discussion_r161883427
  
--- Diff: src/router_core/exchange_bindings.c ---
@@ -0,0 +1,1336 @@
+/*
+ * 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.
+ */
+#include 
+#include 
+#include 
+#include "router_core_private.h"
+#include "exchange_bindings.h"
+
+
+// next_hop_t
+// Describes the destination of a forwarded message
+// May be shared by different bindings
+//
+typedef struct next_hop_t next_hop_t;
+struct next_hop_t
+{
+// per-exchange list of all next hops
+DEQ_LINKS_N(exchange_list, next_hop_t);
+// when hooked to the transmit list
+DEQ_LINKS_N(transmit_list, next_hop_t);
+
+int  ref_count;  // binding references
+int  phase;
+bool on_xmit_list;
+qdr_exchange_t  *exchange;
+qd_iterator_t   *next_hop;
+unsigned char   *next_hop_str;
+qdr_address_t   *qdr_addr;
+};
+
+ALLOC_DECLARE(next_hop_t);
+ALLOC_DEFINE(next_hop_t);
+DEQ_DECLARE(next_hop_t, next_hop_list_t);
+
+// qdr_binding_t
+// Represents a subject key --> next hop mapping
+// A binding is uniquely identified by the tuple (pattern, nextHop, 
phase).  No
+// two bindings with the same tuple value can exist on an exchange.
+// The binding is implemented using two classes: qdr_binding_t and
+// next_hop_t. The qdr_binding_t holds the pattern and points to the
+// next_hop_t.  This allows different patterns to share the same nextHop.
+// Since there is only one next_hop_t instance for each (nextHop, phase) 
value,
+// we guarantee only 1 copy of a message is forwarded to a given 
nextHop+phase
+// even if multiple distinct patterns are matched. Ex: a message with a
+// value of "a.b" will match two distict binding keys "+.b" and "a.+".  If
+// both these patterns share the same next_hop_t only 1 copy of the message
+// will be forwarded.
+typedef struct qdr_binding qdr_binding_t;
+struct qdr_binding
+{
+// per-exchange list of all bindings
+DEQ_LINKS_N(exchange_list, qdr_binding_t);
+// parse tree node's list of bindings sharing the same pattern
+DEQ_LINKS_N(tree_list, qdr_binding_t);
+
+qd_iterator_t   *name;
+unsigned char   *name_str;
+uint64_t identity;
+qdr_exchange_t  *exchange;
+
+// the routing key
+qd_iterator_t   *key;
+unsigned char   *key_str;
+next_hop_t  *next_hop;
+
+uint64_t msgs_matched;
+};
+
+ALLOC_DECLARE(qdr_binding_t);
+ALLOC_DEFINE(qdr_binding_t);
+DEQ_DECLARE(qdr_binding_t, qdr_binding_list_t);
+
+
+struct qdr_exchange {
+DEQ_LINKS(qdr_exchange_t);  // for core->exchanges
+qdr_core_t *core;
+uint64_tidentity;
+qd_iterator_t  *name;
+unsigned char  *name_str;
+qd_iterator_t  *address;
+unsigned char  *address_str;
+int phase;
+qd_parse_tree_t*parse_tree;
+qdr_address_t  *qdr_addr;
+next_hop_t *alternate;
+qdr_binding_list_t  bindings;
+next_hop_list_t next_hops;
+
+uint64_t msgs_received;
+uint64_t msgs_dropped;
+uint64_t msgs_routed;
+uint64_t msgs_alternate;
+};
+
+ALLOC_DECLARE(qdr_exchange_t);
+ALLOC_DEFINE(qdr_exchange_t);
+
+static void qdr_exchange_free(qdr_exchange_t *ex);
+static qdr_exchange_t *qdr_exchange(qdr_core_t*core,
+qd_iterator_t *name,
+qd_iterator_t *address,
+intphase,
+qd_iterator_t *alternate,
+int

[jira] [Created] (PROTON-1744) bug in c-proactor-tests

[Cliff Jansen (JIRA)]

Cliff Jansen created PROTON-1744:


 Summary: bug in c-proactor-tests
 Key: PROTON-1744
 URL: https://issues.apache.org/jira/browse/PROTON-1744
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: proton-c-0.19.0
Reporter: Cliff Jansen


Tests assume strict ordering of interleaved events from 2 separate proactor 
instances.  Valid proactor implementations may produce a different order, 
especially on connection tear-down.

 

See trial epoll proactor at

 

  https://github.com/cliffjansen/qpid-proton/tree/less_writes



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

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

[jira] [Commented] (DISPATCH-878) qdrouterd should log real port if port 0 was specified for the listener port property in qdrouterd.conf

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy commented on DISPATCH-878:


If you want to have two listeners on port: 0, give those listeners different 
names. For example -

 
{noformat}

listener {
    name: listener1
    host: 0.0.0.0
    port: 0
    authenticatePeer: no
    saslMechanisms: ANONYMOUS
}

listener {
    name: listener2
    host: 0.0.0.0
    port: 0
    authenticatePeer: no
    saslMechanisms: ANONYMOUS
}{noformat}

> qdrouterd should log real port if port 0 was specified for the listener port 
> property in qdrouterd.conf
> ---
>
> Key: DISPATCH-878
> URL: https://issues.apache.org/jira/browse/DISPATCH-878
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
> Environment: OS: Red Hat Linux Server release 6.4
> Dispatch version: 0.7.0
>Reporter: Jeremy
>Assignee: Ganesh Murthy
>Priority: Major
>
> For such a qdrouterd.conf configuration:
> {noformat}
> router {
> mode: standalone
> id: Router.A
> }
> listener {
> host: 0.0.0.0
> *port: 5673*
> authenticatePeer: no
> saslMechanisms: ANONYMOUS
> }
> {noformat}
> qdrouterd logs the port as such:
> {noformat}
> CONN_MGR (info) Configured Listener: 0.0.0.0:5673 proto=any, role=normal
> {noformat}
> When specifying port 0, so that the dispatch router runs on a random 
> available port, the log is as such:
> {noformat}
> CONN_MGR (info) Configured Listener: 0.0.0.0:0 proto=any, role=normal
> {noformat}
> qdrouterd process can log instead the real port that was randomly chosen.



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

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

[jira] [Commented] (DISPATCH-878) qdrouterd should log real port if port 0 was specified for the listener port property in qdrouterd.conf

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-878:
-

GitHub user ganeshmurthy opened a pull request:

https://github.com/apache/qpid-dispatch/pull/245

DISPATCH-878 - Added code to display the actual listening port if 0(z…

…ero) is set as the listening port

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

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-878

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

https://github.com/apache/qpid-dispatch/pull/245.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 #245


commit 6c6c68b09807236460088c2e92660e4e50bd3a76
Author: Ganesh Murthy 
Date:   2018-01-16T18:49:53Z

DISPATCH-878 - Added code to display the actual listening port if 0(zero) 
is set as the listening port




> qdrouterd should log real port if port 0 was specified for the listener port 
> property in qdrouterd.conf
> ---
>
> Key: DISPATCH-878
> URL: https://issues.apache.org/jira/browse/DISPATCH-878
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
> Environment: OS: Red Hat Linux Server release 6.4
> Dispatch version: 0.7.0
>Reporter: Jeremy
>Assignee: Ganesh Murthy
>Priority: Major
>
> For such a qdrouterd.conf configuration:
> {noformat}
> router {
> mode: standalone
> id: Router.A
> }
> listener {
> host: 0.0.0.0
> *port: 5673*
> authenticatePeer: no
> saslMechanisms: ANONYMOUS
> }
> {noformat}
> qdrouterd logs the port as such:
> {noformat}
> CONN_MGR (info) Configured Listener: 0.0.0.0:5673 proto=any, role=normal
> {noformat}
> When specifying port 0, so that the dispatch router runs on a random 
> available port, the log is as such:
> {noformat}
> CONN_MGR (info) Configured Listener: 0.0.0.0:0 proto=any, role=normal
> {noformat}
> qdrouterd process can log instead the real port that was randomly chosen.



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

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

[GitHub] qpid-dispatch pull request #245: DISPATCH-878 - Added code to display the ac...

[ganeshmurthy]

GitHub user ganeshmurthy opened a pull request:

https://github.com/apache/qpid-dispatch/pull/245

DISPATCH-878 - Added code to display the actual listening port if 0(z…

…ero) is set as the listening port

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

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-878

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

https://github.com/apache/qpid-dispatch/pull/245.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 #245


commit 6c6c68b09807236460088c2e92660e4e50bd3a76
Author: Ganesh Murthy 
Date:   2018-01-16T18:49:53Z

DISPATCH-878 - Added code to display the actual listening port if 0(zero) 
is set as the listening port




---

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

[jira] [Resolved] (QPID-8079) [Broker-J] If the future associated with an AsyncCommand completes abnormally, the associated action is not rolled-back

[Alex Rudyy (JIRA)]

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

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

Changes look good to me

> [Broker-J] If the future associated with an AsyncCommand completes 
> abnormally, the associated action is not rolled-back
> ---
>
> Key: QPID-8079
> URL: https://issues.apache.org/jira/browse/QPID-8079
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> The protocol layers currently use AsyncCommands to organise for work to be 
> completed after an async auto-commit transaction competes.  When 
> {{AsyncCommand#complete}} is invoked, it awaits completion of the future then 
> calls underlying action.  The code currently fails to call \{{onRollback}} in 
> the failure case.



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

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

[jira] [Commented] (DISPATCH-89) Model the legacy topic exchange behavior of qpidd

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-89:


GitHub user kgiusti opened a pull request:

https://github.com/apache/qpid-dispatch/pull/244

DISPATCH-89: Exchange Binding forwarder (experimental)

Adds a forwarder that models the pre AMQP 1.0 model of exchanges and
bindings.  Exchanges can be added via management and bound to outgoing
target addresses.  MQTT wildcard patterns are also supported.

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

$ git pull https://github.com/kgiusti/dispatch DISPATCH-89

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

https://github.com/apache/qpid-dispatch/pull/244.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 #244


commit 81756bb89bf9d86427555492e298ffcf365c1f7b
Author: Kenneth Giusti 
Date:   2017-01-03T18:14:19Z

DISPATCH-89: Exchange Binding forwarder

Adds a forwarder that models the pre AMQP 1.0 model of exchanges and
bindings.  Exchanges can be added via management and bound to outgoing
target addresses.  MQTT wildcard patterns are also supported.




> Model the legacy topic exchange behavior of qpidd
> -
>
> Key: DISPATCH-89
> URL: https://issues.apache.org/jira/browse/DISPATCH-89
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Routing Engine
>Affects Versions: 0.2
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
>
> With Qpidd, a user can define a binding from an Exchange to a target queue.  
> The binding uses a key that is compared to a message's subject field.  If the 
> key matches, the message is routed to the target queue for that binding.
> It should be possible to emulate this behavior using the dispatch router.
> Example:
> User defines a mappings from a target address (the 'exchange') to a different 
> target address(es) (the 'queue').  These mappings (the 'bindings') are driven 
> by a pattern match against the inbound message's subject field.
> Messages arriving at the router from any link whose target address has 
> bindings defined are not immediately routed.  Prior to routing, the message's 
> subject field is extracted and compared against each binding defined for the 
> target.  A list of new target addresses is created containing the target 
> address from each binding that satisfied the pattern match.  The message is 
> then routed to each new target address.
> The pattern syntax should be the same 'dotted string' notation from qpidd, 
> including '*' and "#' wildcarding.



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

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

[GitHub] qpid-dispatch pull request #244: DISPATCH-89: Exchange Binding forwarder (ex...

[kgiusti]

GitHub user kgiusti opened a pull request:

https://github.com/apache/qpid-dispatch/pull/244

DISPATCH-89: Exchange Binding forwarder (experimental)

Adds a forwarder that models the pre AMQP 1.0 model of exchanges and
bindings.  Exchanges can be added via management and bound to outgoing
target addresses.  MQTT wildcard patterns are also supported.

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

$ git pull https://github.com/kgiusti/dispatch DISPATCH-89

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

https://github.com/apache/qpid-dispatch/pull/244.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 #244


commit 81756bb89bf9d86427555492e298ffcf365c1f7b
Author: Kenneth Giusti 
Date:   2017-01-03T18:14:19Z

DISPATCH-89: Exchange Binding forwarder

Adds a forwarder that models the pre AMQP 1.0 model of exchanges and
bindings.  Exchanges can be added via management and bound to outgoing
target addresses.  MQTT wildcard patterns are also supported.




---

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

[jira] [Assigned] (DISPATCH-878) qdrouterd should log real port if port 0 was specified for the listener port property in qdrouterd.conf

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy reassigned DISPATCH-878:
--

Assignee: Ganesh Murthy

> qdrouterd should log real port if port 0 was specified for the listener port 
> property in qdrouterd.conf
> ---
>
> Key: DISPATCH-878
> URL: https://issues.apache.org/jira/browse/DISPATCH-878
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
> Environment: OS: Red Hat Linux Server release 6.4
> Dispatch version: 0.7.0
>Reporter: Jeremy
>Assignee: Ganesh Murthy
>Priority: Major
>
> For such a qdrouterd.conf configuration:
> {noformat}
> router {
> mode: standalone
> id: Router.A
> }
> listener {
> host: 0.0.0.0
> *port: 5673*
> authenticatePeer: no
> saslMechanisms: ANONYMOUS
> }
> {noformat}
> qdrouterd logs the port as such:
> {noformat}
> CONN_MGR (info) Configured Listener: 0.0.0.0:5673 proto=any, role=normal
> {noformat}
> When specifying port 0, so that the dispatch router runs on a random 
> available port, the log is as such:
> {noformat}
> CONN_MGR (info) Configured Listener: 0.0.0.0:0 proto=any, role=normal
> {noformat}
> qdrouterd process can log instead the real port that was randomly chosen.



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

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

[jira] [Resolved] (QPID-8070) Qpid java broker is unable to reconnect to database after kill -9 then restart

[Alex Rudyy (JIRA)]

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

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

> Qpid java broker is unable to reconnect to database after kill -9 then restart
> --
>
> Key: QPID-8070
> URL: https://issues.apache.org/jira/browse/QPID-8070
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.4, qpid-java-6.1.5
>Reporter: Rabih Mourad
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.1, qpid-java-6.1.6
>
>
> Hello,
> We are using Qpid java broker version 6.1.4.
> Our test case:
> We have a JMS client sending messages continuously in autoAck mode to a 
> messaging cluster. The cluster is composed of 1 dispatch router and 2 java 
> brokers which are connected to an Oracle Db.
> At some point, the test kills a broker using kill -9 and then attempts to 
> restart it.
> Randomly, we have a NullPointerException while the broker is restarting and 
> connecting to the virtual host node (the full error stack is at the end of 
> the email).
> Do you have any idea why this is happening? is there a chance that a kill
> -9 on a broker leaves the Db in an unstable state?
> Best regards,
> Rabih
> 2018-01-03 17:16:45,930 INFO  [VirtualHostNode-default-Config]
> (q.m.t.recovery_start) - [Broker]
> [vh(/default)/ms(GenericJDBCMessageStore)] TXN-1004 : Recovery Start
> 2018-01-03 17:16:45,938 WARN  [VirtualHostNode-default-Config]
> (o.a.q.s.v.SynchronousMessageStoreRecoverer) - Message id 1 in log references 
> queue with id 0b2a06aa-6d46-49aa-885f-63f3cd73108d which is not in the 
> configuration, entry will be discarded
> 2018-01-03 17:16:45,946 ERROR [VirtualHostNode-default-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name 
> 'default'.  Object will be put into ERROR state.
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.commitTranAsync(AbstractJDBCMessageStore.java:826)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.access$600(AbstractJDBCMessageStore.java:59)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCTransaction.commitTranAsync(AbstractJDBCMessageStore.java:1205)
> at
> org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.commitTranAsync(GenericAbstractJDBCMessageStore.java:142)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer$MessageInstanceVisitor.handle(SynchronousMessageStoreRecoverer.java:219)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCMessageStoreReader.visitMessageInstances(AbstractJDBCMessageStore.java:1911)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer.recover(SynchronousMessageStoreRecoverer.java:82)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.postCreateDefaultExchangeTasks(AbstractVirtualHost.java:2581)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:2563)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1482)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1461)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1035)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1029)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2609)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2605)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2604)
> at
> com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:404)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:187)
> at
> 

[jira] [Commented] (QPID-8062) [Broker-J][AMQP 1.0] When a pre-settled message published over "anonymous relay" is rejected by the destination, the Broker should detach the link for non-transactional

[Alex Rudyy (JIRA)]

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

Alex Rudyy commented on QPID-8062:
--

Here is the link to a discussion preceding raising of the issue 
[https://www.mail-archive.com/users@qpid.apache.org/msg17226.html]

> [Broker-J][AMQP 1.0] When a pre-settled message published over "anonymous 
> relay" is rejected by the destination, the Broker should detach the link for 
> non-transactional case or mark the publishing transaction as "rollback only"
> ---
>
> Key: QPID-8062
> URL: https://issues.apache.org/jira/browse/QPID-8062
> Project: Qpid
>  Issue Type: Bug
>Reporter: Alex Rudyy
>Priority: Major
>
> As per section "2.2.2 Routing Errors" of "Using the Anonymous Terminus for 
> Message Routing Version 1.0":
> {quote}
> If the source of the link does not support the rejected outcome, or the 
> message has already been settled by the sender, then the routing node MUST 
> detach the link with an error. The error sent by the routing node MUST 
> contain the error which would have been communicated in the detach sent on 
> attempting to link directly to the address in the message’s to field. 
> Additionally the info field of error MUST contain an entry with symbolic key 
> delivery-tag and binary value of the delivery-tag of the message which caused 
> the failure.
> {quote}
> The Broker-J does not handle the case when message is sent pre-settled and is 
> rejected by the destination. We need to add the support for this behaviour.  
> Additionally, if a pre-settled message is published within a transaction and 
> cannot be fully processed by a queue/exchange/whatever then have the 
> transactional resource (queue / exchange / whatever) logically mark the 
> transaction as"rollback only" (i.e. failed), and then reject any attempt to 
> commit such a transaction.



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

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

[jira] [Assigned] (DISPATCH-911) New management call to return overall router network statistics

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy reassigned DISPATCH-911:
--

Assignee: Ganesh Murthy

> New management call to return overall router network statistics
> ---
>
> Key: DISPATCH-911
> URL: https://issues.apache.org/jira/browse/DISPATCH-911
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 1.0.0
>Reporter: Ernest Allen
>Assignee: Ganesh Murthy
>Priority: Major
>
> We need overview charts that display:
>   - the throughput rate for the router network
>   - network load
>   - average latency
> For the throughput rate:
> This is derived from the sum of router.address.deliveriesEgress for all 
> addresses on all routers in the network.
> For network load:
> This is derived from the sum of the router.link.undeliveredCount and 
> router.link.unsettledCount for all endpoint links on the network.
> For the average latency:
> A new attribute needs to be created. Each ingress message needs to be 
> annotated with an ingress timestamp. When the message egresses the network, 
> the total time 'in-flight' needs to be calculated and accumulated in the 
> egress router's new router.address.deliveriesEgressDuration attribute. 
> Average latency can be calculated using this statistic and the throughput 
> statistic.
> Add a new management action of "SUM" that recognizes a new 
> application_proptery of filter. The SUM action sums the given attribute(s) 
> from all routers. The filter determines which records are included.
> To calculate load, the request looks like:
> {
> body: ['undeliveredCount', 'unsettledCount'],
> application_properties: {
> operation: 'SUM',
> type: 'org.apache.qpid.dispatch.router.link',
> filter: {'linkType': 'endpoint'}
> }
> }
> This would return:
> {
> attributeNames: ['undeliveredCount', 'unsettledCount'],
> values: [, ]
> }
> where the sums are for all routers for all links with linkType == endpoint 
> For the throughput request:
> {
> body: ['deliveriesEgress'],
> application_properties: {
> operation: 'SUM',
> type: 'org.apache.qpid.dispatch.router.address',
> filter: {'name': '*'}  // or name:  for a single address
> }
> }
> This would return:
> {
> attributeNames: ['deliveriesEgress'],
> values: []
> }
> where the sum is for all routers for all address.names that matched the name 
> given in the filter.
> For the latancy request:
> {
> body: ['deliveriesEgress', 'deliveriesEgressDuration'],
> application_properties: {
> operation: 'SUM',
> type: 'org.apache.qpid.dispatch.router.address',
> filter: {'name': '*'} // or name:  for a single address
> }
> }
> This would return:
> {
> attributeNames: ['deliveriesEgress', 'deliveriesEgressDuration'],
> values: [, ]
> }
> where the sums are for all routers for all address.names that matched the 
> name given in the filter.
> Note: If annotating messages with timestamps for the deliveriesEgressDuration 
> attribute is too much of a performance hit, an additional management call is 
> needed to enable and disable this behavior.
> Bonus: This new 'SUM' request can be used to replace the existing request 
> that sums logStats accross routers. 



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

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

[jira] [Assigned] (QPIDIT-109) Add ability to run Proton Python shims under Python 3

[Kim van der Riet (JIRA)]

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

Kim van der Riet reassigned QPIDIT-109:
---

Assignee: Kim van der Riet

> Add ability to run Proton Python shims under Python 3
> -
>
> Key: QPIDIT-109
> URL: https://issues.apache.org/jira/browse/QPIDIT-109
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Bug
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> Currently the shims run under Python 2.7, so add Python 3 as additional shim 
> type.



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

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

[jira] [Created] (QPIDIT-109) Add ability to run Proton Python shims under Python 3

[Kim van der Riet (JIRA)]

Kim van der Riet created QPIDIT-109:
---

 Summary: Add ability to run Proton Python shims under Python 3
 Key: QPIDIT-109
 URL: https://issues.apache.org/jira/browse/QPIDIT-109
 Project: Apache QPID Interoperability Test Suite
  Issue Type: Bug
Reporter: Kim van der Riet


Currently the shims run under Python 2.7, so add Python 3 as additional shim 
type.



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

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

[jira] [Resolved] (QPIDIT-65) Add command-line controls to JMS_hdrs_props_test to control test more precisely

[Kim van der Riet (JIRA)]

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

Kim van der Riet resolved QPIDIT-65.

Resolution: Fixed

Resolved.

> Add command-line controls to JMS_hdrs_props_test to control test more 
> precisely
> ---
>
> Key: QPIDIT-65
> URL: https://issues.apache.org/jira/browse/QPIDIT-65
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Improvement
>  Components: JMS Headers and Properties Test
>Affects Versions: 0.1.0
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Minor
> Fix For: 0.2.0
>
>
> The JMS hdrs_props_test needs additional command-line parameters to control 
> the test precisely. Since the test by default uses only the JMS_MESSAGE_TYPE 
> for this test, the --{include, exclude}-type paramter has no effect at 
> present, but should be used to change/modify the base message type. In 
> addition, a parameter switching on/off the headers and parameters is needed, 
> also a control for the type of header and type of parameters used.



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

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

[jira] [Commented] (QPIDIT-65) Add command-line controls to JMS_hdrs_props_test to control test more precisely

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPIDIT-65:
---

Commit 1276fe1975f8fda5a3cde0320488ef3e1bafdbe0 in qpid-interop-test's branch 
refs/heads/master from [~kpvdr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-interop-test.git;h=1276fe1 ]

QPIDIT-65: Added the last test section (section D) that depends on the message 
properties to work


> Add command-line controls to JMS_hdrs_props_test to control test more 
> precisely
> ---
>
> Key: QPIDIT-65
> URL: https://issues.apache.org/jira/browse/QPIDIT-65
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Improvement
>  Components: JMS Headers and Properties Test
>Affects Versions: 0.1.0
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Minor
> Fix For: 0.2.0
>
>
> The JMS hdrs_props_test needs additional command-line parameters to control 
> the test precisely. Since the test by default uses only the JMS_MESSAGE_TYPE 
> for this test, the --{include, exclude}-type paramter has no effect at 
> present, but should be used to change/modify the base message type. In 
> addition, a parameter switching on/off the headers and parameters is needed, 
> also a control for the type of header and type of parameters used.



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

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

[jira] [Commented] (QPIDJMS-355) Use the new Proton-J SaslListener API to simplify the sasl code

[ASF subversion and git services (JIRA)]

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

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

Commit a297163ea23462af134ab8dd9637d142f487df8a in qpid-jms's branch 
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=a297163 ]

QPIDJMS-355 Use the new SaslListener events to do authentication

Leverage the SaslListener to reduce checking of SASL state on each
read from the Transport layer.


> Use the new Proton-J SaslListener API to simplify the sasl code
> ---
>
> Key: QPIDJMS-355
> URL: https://issues.apache.org/jira/browse/QPIDJMS-355
> Project: Qpid JMS
>  Issue Type: Improvement
>Affects Versions: 0.28.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 0.29.0
>
>
> Latest proton-j release provide a SASL event callback that can be used to 
> simplify the current implementation that must check sasl state on each 
> inbound read.



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

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

[jira] [Resolved] (DISPATCH-914) qd_connector_t leaks mutexes

[Ken Giusti (JIRA)]

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

Ken Giusti resolved DISPATCH-914.
-
Resolution: Fixed

> qd_connector_t leaks mutexes
> 
>
> Key: DISPATCH-914
> URL: https://issues.apache.org/jira/browse/DISPATCH-914
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.1.0
> Environment: Unit tests fail with the following traceback when run 
> under valgrind:
>  
> 39: ==5443== 64 bytes in 1 blocks are definitely lost in loss record 1,047 of 
> 3,514
> 39: ==5443==    at 0x4C30D47: memalign (vg_replace_malloc.c:857)
> 39: ==5443==    by 0x4C30E45: posix_memalign (vg_replace_malloc.c:1020)
> 39: ==5443==    by 0x4E70B58: sys_mutex (threading.c:40)
> 39: ==5443==    by 0x4E8BCAA: qd_server_connector (server.c:1363)
> 39: ==5443==    by 0x4E61A49: qd_dispatch_configure_connector 
> (connection_manager.c:711)
> 39: ==5443==    by 0x10FC8BDD: ffi_call_unix64 (unix64.S:76)
> 39: ==5443==    by 0x10FC854E: ffi_call (ffi64.c:525)
> 39: ==5443==    by 0x10DB53A4: _ctypes_callproc (in 
> /usr/lib64/python2.7/lib-dynload/_ctypes.so)
> 39: ==5443==    by 0x10DAF0BD: ??? (in 
> /usr/lib64/python2.7/lib-dynload/_ctypes.so)
> 39: ==5443==    by 0x5BBE342: PyObject_Call (in 
> /usr/lib64/libpython2.7.so.1.0)
> 39: ==5443==    by 0x5C831B1: PyEval_EvalFrameEx (in 
> /usr/lib64/libpython2.7.so.1.0)
> 39: ==5443==    by 0x5C85B18: PyEval_EvalFrameEx (in 
> /usr/lib64/libpython2.7.so.1.0)
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.1.0
>
>




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

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

[jira] [Created] (QPIDJMS-355) Use the new Proton-J SaslListener API to simplify the sasl code

[Timothy Bish (JIRA)]

Timothy Bish created QPIDJMS-355:


 Summary: Use the new Proton-J SaslListener API to simplify the 
sasl code
 Key: QPIDJMS-355
 URL: https://issues.apache.org/jira/browse/QPIDJMS-355
 Project: Qpid JMS
  Issue Type: Improvement
Affects Versions: 0.28.0
Reporter: Timothy Bish
Assignee: Timothy Bish
 Fix For: 0.29.0


Latest proton-j release provide a SASL event callback that can be used to 
simplify the current implementation that must check sasl state on each inbound 
read.



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

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

[jira] [Resolved] (QPID-8071) Java Qpid library does not report that session was closed

[Keith Wall (JIRA)]

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

Keith Wall resolved QPID-8071.
--
Resolution: Won't Fix

Development of the Qpid JMS AMQP 0-x client is ceased.  As discussed please use 
the https://qpid.apache.org/components/jms/index.html

> Java Qpid library does not report that session was closed
> -
>
> Key: QPID-8071
> URL: https://issues.apache.org/jira/browse/QPID-8071
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-6.1.5
> Environment: slow network towards Qpid broker
> for instance set this to the machine that is making connection towards qpid 
> broker
> sudo tc qdisc add dev enp0s8 root handle 1: tbf rate 16kbit latency 25ms 
> burst 2k
> reset the throttle with this
> sudo tc qdisc del dev enp0s8 root
> add those flags to shorten qpid.io_network_transport_timeout from 1min to 5 
> seconds
> -Dqpid.sync_op_timeout=509000 -Dqpid.io_network_transport_timeout=5000
> try to send 512kB long message. If qpid.io_network_transport_timeout is 
> raised to 3 minutes it should take about 300 seconds to send the message 
> (with 16kbit link) (the default 60s threshold is exceeded).
>Reporter: Alojzij Blatnik
>Priority: Major
>
> when qpid.io_network_transport_timeout is exceeded, qpid-java library does 
> not throw exception, but the exception is just logged, hence the code, that 
> is calling qpid-java library doesn't know that qpid message wasn't sent until 
> it becomes obvious that connection is closed.
> monkey patch:
> {{diff --git a/common/src/main/java/org/apache/qpid/transport/Session.java 
> b/common/src/main/java/org/apache/qpid/transport/Session.java
> index 9568873..b1afd8d 100644
> --- a/common/src/main/java/org/apache/qpid/transport/Session.java
> +++ b/common/src/main/java/org/apache/qpid/transport/Session.java
> @@ -759,16 +759,7 @@ public class Session extends SessionInvoker
>  }
>  catch (SenderException e)
>  {
> -if (!closing)
> -{
> -// if we are not closing then this will happen
> -// again on resume
> -LOGGER.error("error sending command", e);
> -}
> -else
> -{
> -e.rethrow();
> -}
> +e.rethrow();
>  }
>  if (autoSync)
>  {
> }}
> Some logs:
> {{
> 12585 [main] ERROR org.apache.qpid.transport.network.io.IoSender  - write 
> timed out for socket /172.21.0.2:50618-qpid-broker/192.168.80.1:5671: head 
> -2147216975, tail -2147348047
> 12586 [main] ERROR org.apache.qpid.transport.Session  - error sending command
> org.apache.qpid.transport.SenderException: write timed out for socket 
> /172.21.0.2:50618-qpid-broker/192.168.80.1:5671: head -2147216975, tail 
> -2147348047
>   at org.apache.qpid.transport.network.io.IoSender.send(IoSender.java:172)
>   at 
> org.apache.qpid.transport.network.security.ssl.SSLSender.doSend(SSLSender.java:215)
>   at 
> org.apache.qpid.transport.network.security.ssl.SSLSender.flush(SSLSender.java:149)
>   at 
> org.apache.qpid.transport.network.Disassembler.flush(Disassembler.java:88)
>   at org.apache.qpid.transport.Connection.flush(Connection.java:428)
>   at org.apache.qpid.transport.Session.send(Session.java:592)
>   at org.apache.qpid.transport.Session.invoke(Session.java:758)
>   at org.apache.qpid.transport.Session.invoke(Session.java:613)
>   at 
> org.apache.qpid.transport.SessionInvoker.messageTransfer(SessionInvoker.java:93)
>   at 
> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:371)
>   at 
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:549)
>   at 
> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:333)
>   at tld.domain.OurLibrary$SendLogic.sendLogic(OurLibrary.java:430)
>   at tld.domain.OurLibrary$SendLogic.run(OurLibrary.java:391)
>   at tld.domain.OurLibrary.reconnectCommonLogic(OurLibrary.java:497)
>   at tld.domain.OurLibrary.reconnectLogic(OurLibrary.java:483)
>   at tld.domain.OurLibrary.send(OurLibrary.java:373)
>   at tld.domain.Main.send(Main.java:476)
>   at tld.domain.MainAttict.tesSendMsg(MainAttict.java:285)
>   at tld.domain.MainAttict.main(MainAttict.java:368)
> 12589 [main] INFO tld.domain.MainAttict  - message sent
> 12590 [IoRcvr-/172.21.0.2:50618-qpid-broker/192.168.80.1:5671] ERROR 
> org.apache.qpid.client.AMQConnectionDelegate_0_10  - connection exception: 
> conn:70d0de44
> 

[jira] [Commented] (DISPATCH-914) qd_connector_t leaks mutexes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-914:
-

Github user asfgit closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/243


> qd_connector_t leaks mutexes
> 
>
> Key: DISPATCH-914
> URL: https://issues.apache.org/jira/browse/DISPATCH-914
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.1.0
> Environment: Unit tests fail with the following traceback when run 
> under valgrind:
>  
> 39: ==5443== 64 bytes in 1 blocks are definitely lost in loss record 1,047 of 
> 3,514
> 39: ==5443==    at 0x4C30D47: memalign (vg_replace_malloc.c:857)
> 39: ==5443==    by 0x4C30E45: posix_memalign (vg_replace_malloc.c:1020)
> 39: ==5443==    by 0x4E70B58: sys_mutex (threading.c:40)
> 39: ==5443==    by 0x4E8BCAA: qd_server_connector (server.c:1363)
> 39: ==5443==    by 0x4E61A49: qd_dispatch_configure_connector 
> (connection_manager.c:711)
> 39: ==5443==    by 0x10FC8BDD: ffi_call_unix64 (unix64.S:76)
> 39: ==5443==    by 0x10FC854E: ffi_call (ffi64.c:525)
> 39: ==5443==    by 0x10DB53A4: _ctypes_callproc (in 
> /usr/lib64/python2.7/lib-dynload/_ctypes.so)
> 39: ==5443==    by 0x10DAF0BD: ??? (in 
> /usr/lib64/python2.7/lib-dynload/_ctypes.so)
> 39: ==5443==    by 0x5BBE342: PyObject_Call (in 
> /usr/lib64/libpython2.7.so.1.0)
> 39: ==5443==    by 0x5C831B1: PyEval_EvalFrameEx (in 
> /usr/lib64/libpython2.7.so.1.0)
> 39: ==5443==    by 0x5C85B18: PyEval_EvalFrameEx (in 
> /usr/lib64/libpython2.7.so.1.0)
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.1.0
>
>




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

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

[jira] [Commented] (DISPATCH-914) qd_connector_t leaks mutexes

[ASF subversion and git services (JIRA)]

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

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

Commit 3c40c5797287e317d357fd885d4457d9d2dd9520 in qpid-dispatch's branch 
refs/heads/master from Kenneth Giusti
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=3c40c57 ]

DISPATCH-914: correctly free mutex from qd_connector_t


> qd_connector_t leaks mutexes
> 
>
> Key: DISPATCH-914
> URL: https://issues.apache.org/jira/browse/DISPATCH-914
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.1.0
> Environment: Unit tests fail with the following traceback when run 
> under valgrind:
>  
> 39: ==5443== 64 bytes in 1 blocks are definitely lost in loss record 1,047 of 
> 3,514
> 39: ==5443==    at 0x4C30D47: memalign (vg_replace_malloc.c:857)
> 39: ==5443==    by 0x4C30E45: posix_memalign (vg_replace_malloc.c:1020)
> 39: ==5443==    by 0x4E70B58: sys_mutex (threading.c:40)
> 39: ==5443==    by 0x4E8BCAA: qd_server_connector (server.c:1363)
> 39: ==5443==    by 0x4E61A49: qd_dispatch_configure_connector 
> (connection_manager.c:711)
> 39: ==5443==    by 0x10FC8BDD: ffi_call_unix64 (unix64.S:76)
> 39: ==5443==    by 0x10FC854E: ffi_call (ffi64.c:525)
> 39: ==5443==    by 0x10DB53A4: _ctypes_callproc (in 
> /usr/lib64/python2.7/lib-dynload/_ctypes.so)
> 39: ==5443==    by 0x10DAF0BD: ??? (in 
> /usr/lib64/python2.7/lib-dynload/_ctypes.so)
> 39: ==5443==    by 0x5BBE342: PyObject_Call (in 
> /usr/lib64/libpython2.7.so.1.0)
> 39: ==5443==    by 0x5C831B1: PyEval_EvalFrameEx (in 
> /usr/lib64/libpython2.7.so.1.0)
> 39: ==5443==    by 0x5C85B18: PyEval_EvalFrameEx (in 
> /usr/lib64/libpython2.7.so.1.0)
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.1.0
>
>




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

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

[GitHub] qpid-dispatch pull request #243: DISPATCH-914: correctly free mutex from qd_...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/243


---

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

[jira] [Updated] (QPID-8076) [0-91] [Publisher Confirms] basic.ack returned to client before message is sync'd to disk

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8076:
-
Status: Reviewable  (was: In Progress)

> [0-91] [Publisher Confirms] basic.ack returned to client before message is 
> sync'd to disk
> -
>
> Key: QPID-8076
> URL: https://issues.apache.org/jira/browse/QPID-8076
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: 0.32, qpid-java-6.0, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.0
>
>
> QPID-6164 added RabbitMQ's publish confirms [1] feature to Broker-J.  
> Concerning when the basic.ack is sent back to the client, the feature 
> documentation states:
> {quote}
> h3. When will messages be confirmed?
> ..
> For routable messages, the basic.ack is sent when a message has been accepted 
> by all the queues. For persistent messages routed to durable queues, this 
> *means persisting to disk*. 
> {quote}
> Currently, Broker-J does not behave in this way.  The {{basic.ack}} is 
> returned to the client before the auto-async transaction has confirmed that 
> the data is on disk.  The code is AMQChannel#deliverCurrentMessageIfComplete. 
>  It ought to arrange for the acks to be returned once the sync completes.
>  
> [1] [https://www.rabbitmq.com/confirms.html]



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

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

[jira] [Updated] (QPID-8070) Qpid java broker is unable to reconnect to database after kill -9 then restart

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8070:
-
Affects Version/s: qpid-java-6.1.5

> Qpid java broker is unable to reconnect to database after kill -9 then restart
> --
>
> Key: QPID-8070
> URL: https://issues.apache.org/jira/browse/QPID-8070
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.4, qpid-java-6.1.5
>Reporter: Rabih Mourad
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.1, qpid-java-6.1.6
>
>
> Hello,
> We are using Qpid java broker version 6.1.4.
> Our test case:
> We have a JMS client sending messages continuously in autoAck mode to a 
> messaging cluster. The cluster is composed of 1 dispatch router and 2 java 
> brokers which are connected to an Oracle Db.
> At some point, the test kills a broker using kill -9 and then attempts to 
> restart it.
> Randomly, we have a NullPointerException while the broker is restarting and 
> connecting to the virtual host node (the full error stack is at the end of 
> the email).
> Do you have any idea why this is happening? is there a chance that a kill
> -9 on a broker leaves the Db in an unstable state?
> Best regards,
> Rabih
> 2018-01-03 17:16:45,930 INFO  [VirtualHostNode-default-Config]
> (q.m.t.recovery_start) - [Broker]
> [vh(/default)/ms(GenericJDBCMessageStore)] TXN-1004 : Recovery Start
> 2018-01-03 17:16:45,938 WARN  [VirtualHostNode-default-Config]
> (o.a.q.s.v.SynchronousMessageStoreRecoverer) - Message id 1 in log references 
> queue with id 0b2a06aa-6d46-49aa-885f-63f3cd73108d which is not in the 
> configuration, entry will be discarded
> 2018-01-03 17:16:45,946 ERROR [VirtualHostNode-default-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name 
> 'default'.  Object will be put into ERROR state.
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.commitTranAsync(AbstractJDBCMessageStore.java:826)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.access$600(AbstractJDBCMessageStore.java:59)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCTransaction.commitTranAsync(AbstractJDBCMessageStore.java:1205)
> at
> org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.commitTranAsync(GenericAbstractJDBCMessageStore.java:142)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer$MessageInstanceVisitor.handle(SynchronousMessageStoreRecoverer.java:219)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCMessageStoreReader.visitMessageInstances(AbstractJDBCMessageStore.java:1911)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer.recover(SynchronousMessageStoreRecoverer.java:82)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.postCreateDefaultExchangeTasks(AbstractVirtualHost.java:2581)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:2563)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1482)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1461)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1035)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1029)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2609)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2605)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2604)
> at
> com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:404)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:187)
> at

[jira] [Updated] (QPID-8070) Qpid java broker is unable to reconnect to database after kill -9 then restart

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8070:
-
Fix Version/s: (was: qpid-java-6.1.5)
   qpid-python-1.35.0
   qpid-java-6.1.6

> Qpid java broker is unable to reconnect to database after kill -9 then restart
> --
>
> Key: QPID-8070
> URL: https://issues.apache.org/jira/browse/QPID-8070
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.4
>Reporter: Rabih Mourad
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.1, qpid-java-6.1.6
>
>
> Hello,
> We are using Qpid java broker version 6.1.4.
> Our test case:
> We have a JMS client sending messages continuously in autoAck mode to a 
> messaging cluster. The cluster is composed of 1 dispatch router and 2 java 
> brokers which are connected to an Oracle Db.
> At some point, the test kills a broker using kill -9 and then attempts to 
> restart it.
> Randomly, we have a NullPointerException while the broker is restarting and 
> connecting to the virtual host node (the full error stack is at the end of 
> the email).
> Do you have any idea why this is happening? is there a chance that a kill
> -9 on a broker leaves the Db in an unstable state?
> Best regards,
> Rabih
> 2018-01-03 17:16:45,930 INFO  [VirtualHostNode-default-Config]
> (q.m.t.recovery_start) - [Broker]
> [vh(/default)/ms(GenericJDBCMessageStore)] TXN-1004 : Recovery Start
> 2018-01-03 17:16:45,938 WARN  [VirtualHostNode-default-Config]
> (o.a.q.s.v.SynchronousMessageStoreRecoverer) - Message id 1 in log references 
> queue with id 0b2a06aa-6d46-49aa-885f-63f3cd73108d which is not in the 
> configuration, entry will be discarded
> 2018-01-03 17:16:45,946 ERROR [VirtualHostNode-default-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name 
> 'default'.  Object will be put into ERROR state.
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.commitTranAsync(AbstractJDBCMessageStore.java:826)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.access$600(AbstractJDBCMessageStore.java:59)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCTransaction.commitTranAsync(AbstractJDBCMessageStore.java:1205)
> at
> org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.commitTranAsync(GenericAbstractJDBCMessageStore.java:142)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer$MessageInstanceVisitor.handle(SynchronousMessageStoreRecoverer.java:219)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCMessageStoreReader.visitMessageInstances(AbstractJDBCMessageStore.java:1911)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer.recover(SynchronousMessageStoreRecoverer.java:82)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.postCreateDefaultExchangeTasks(AbstractVirtualHost.java:2581)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:2563)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1482)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1461)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1035)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1029)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2609)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2605)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2604)
> at
> com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:404)
> at
> 

[jira] [Updated] (QPID-8070) Qpid java broker is unable to reconnect to database after kill -9 then restart

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8070:
-
Fix Version/s: (was: qpid-python-1.35.0)

> Qpid java broker is unable to reconnect to database after kill -9 then restart
> --
>
> Key: QPID-8070
> URL: https://issues.apache.org/jira/browse/QPID-8070
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.4
>Reporter: Rabih Mourad
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.1, qpid-java-6.1.6
>
>
> Hello,
> We are using Qpid java broker version 6.1.4.
> Our test case:
> We have a JMS client sending messages continuously in autoAck mode to a 
> messaging cluster. The cluster is composed of 1 dispatch router and 2 java 
> brokers which are connected to an Oracle Db.
> At some point, the test kills a broker using kill -9 and then attempts to 
> restart it.
> Randomly, we have a NullPointerException while the broker is restarting and 
> connecting to the virtual host node (the full error stack is at the end of 
> the email).
> Do you have any idea why this is happening? is there a chance that a kill
> -9 on a broker leaves the Db in an unstable state?
> Best regards,
> Rabih
> 2018-01-03 17:16:45,930 INFO  [VirtualHostNode-default-Config]
> (q.m.t.recovery_start) - [Broker]
> [vh(/default)/ms(GenericJDBCMessageStore)] TXN-1004 : Recovery Start
> 2018-01-03 17:16:45,938 WARN  [VirtualHostNode-default-Config]
> (o.a.q.s.v.SynchronousMessageStoreRecoverer) - Message id 1 in log references 
> queue with id 0b2a06aa-6d46-49aa-885f-63f3cd73108d which is not in the 
> configuration, entry will be discarded
> 2018-01-03 17:16:45,946 ERROR [VirtualHostNode-default-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name 
> 'default'.  Object will be put into ERROR state.
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.commitTranAsync(AbstractJDBCMessageStore.java:826)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.access$600(AbstractJDBCMessageStore.java:59)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCTransaction.commitTranAsync(AbstractJDBCMessageStore.java:1205)
> at
> org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.commitTranAsync(GenericAbstractJDBCMessageStore.java:142)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer$MessageInstanceVisitor.handle(SynchronousMessageStoreRecoverer.java:219)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCMessageStoreReader.visitMessageInstances(AbstractJDBCMessageStore.java:1911)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer.recover(SynchronousMessageStoreRecoverer.java:82)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.postCreateDefaultExchangeTasks(AbstractVirtualHost.java:2581)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:2563)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1482)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1461)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1035)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1029)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2609)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2605)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2604)
> at
> com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:404)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:187)
> at
> 

[jira] [Commented] (QPID-8070) Qpid java broker is unable to reconnect to database after kill -9 then restart

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-8070:
--

Changes looked reasonable to me.  Port to 7.0.x and 6.1.x branches done.

> Qpid java broker is unable to reconnect to database after kill -9 then restart
> --
>
> Key: QPID-8070
> URL: https://issues.apache.org/jira/browse/QPID-8070
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.4
>Reporter: Rabih Mourad
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-6.1.5, qpid-java-broker-7.0.1
>
>
> Hello,
> We are using Qpid java broker version 6.1.4.
> Our test case:
> We have a JMS client sending messages continuously in autoAck mode to a 
> messaging cluster. The cluster is composed of 1 dispatch router and 2 java 
> brokers which are connected to an Oracle Db.
> At some point, the test kills a broker using kill -9 and then attempts to 
> restart it.
> Randomly, we have a NullPointerException while the broker is restarting and 
> connecting to the virtual host node (the full error stack is at the end of 
> the email).
> Do you have any idea why this is happening? is there a chance that a kill
> -9 on a broker leaves the Db in an unstable state?
> Best regards,
> Rabih
> 2018-01-03 17:16:45,930 INFO  [VirtualHostNode-default-Config]
> (q.m.t.recovery_start) - [Broker]
> [vh(/default)/ms(GenericJDBCMessageStore)] TXN-1004 : Recovery Start
> 2018-01-03 17:16:45,938 WARN  [VirtualHostNode-default-Config]
> (o.a.q.s.v.SynchronousMessageStoreRecoverer) - Message id 1 in log references 
> queue with id 0b2a06aa-6d46-49aa-885f-63f3cd73108d which is not in the 
> configuration, entry will be discarded
> 2018-01-03 17:16:45,946 ERROR [VirtualHostNode-default-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name 
> 'default'.  Object will be put into ERROR state.
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.commitTranAsync(AbstractJDBCMessageStore.java:826)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.access$600(AbstractJDBCMessageStore.java:59)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCTransaction.commitTranAsync(AbstractJDBCMessageStore.java:1205)
> at
> org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.commitTranAsync(GenericAbstractJDBCMessageStore.java:142)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer$MessageInstanceVisitor.handle(SynchronousMessageStoreRecoverer.java:219)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCMessageStoreReader.visitMessageInstances(AbstractJDBCMessageStore.java:1911)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer.recover(SynchronousMessageStoreRecoverer.java:82)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.postCreateDefaultExchangeTasks(AbstractVirtualHost.java:2581)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:2563)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1482)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1461)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1035)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1029)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2609)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2605)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2604)
> at
> com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:404)
> at
> 

[jira] [Commented] (QPID-8070) Qpid java broker is unable to reconnect to database after kill -9 then restart

[ASF subversion and git services (JIRA)]

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

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

Commit 3dce1474189a5def9bd0e989cb430379bc084659 in qpid-broker-j's branch 
refs/heads/6.1.x from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=3dce147 ]

QPID-8070: [Broker-J] [Unit Tests] Prevent tests leaking in-memory Derby 
instances

Cherry picked from 887f535ea766ef9197b28a95f223b742044e5908


> Qpid java broker is unable to reconnect to database after kill -9 then restart
> --
>
> Key: QPID-8070
> URL: https://issues.apache.org/jira/browse/QPID-8070
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.4
>Reporter: Rabih Mourad
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-6.1.5, qpid-java-broker-7.0.1
>
>
> Hello,
> We are using Qpid java broker version 6.1.4.
> Our test case:
> We have a JMS client sending messages continuously in autoAck mode to a 
> messaging cluster. The cluster is composed of 1 dispatch router and 2 java 
> brokers which are connected to an Oracle Db.
> At some point, the test kills a broker using kill -9 and then attempts to 
> restart it.
> Randomly, we have a NullPointerException while the broker is restarting and 
> connecting to the virtual host node (the full error stack is at the end of 
> the email).
> Do you have any idea why this is happening? is there a chance that a kill
> -9 on a broker leaves the Db in an unstable state?
> Best regards,
> Rabih
> 2018-01-03 17:16:45,930 INFO  [VirtualHostNode-default-Config]
> (q.m.t.recovery_start) - [Broker]
> [vh(/default)/ms(GenericJDBCMessageStore)] TXN-1004 : Recovery Start
> 2018-01-03 17:16:45,938 WARN  [VirtualHostNode-default-Config]
> (o.a.q.s.v.SynchronousMessageStoreRecoverer) - Message id 1 in log references 
> queue with id 0b2a06aa-6d46-49aa-885f-63f3cd73108d which is not in the 
> configuration, entry will be discarded
> 2018-01-03 17:16:45,946 ERROR [VirtualHostNode-default-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name 
> 'default'.  Object will be put into ERROR state.
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.commitTranAsync(AbstractJDBCMessageStore.java:826)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.access$600(AbstractJDBCMessageStore.java:59)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCTransaction.commitTranAsync(AbstractJDBCMessageStore.java:1205)
> at
> org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.commitTranAsync(GenericAbstractJDBCMessageStore.java:142)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer$MessageInstanceVisitor.handle(SynchronousMessageStoreRecoverer.java:219)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCMessageStoreReader.visitMessageInstances(AbstractJDBCMessageStore.java:1911)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer.recover(SynchronousMessageStoreRecoverer.java:82)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.postCreateDefaultExchangeTasks(AbstractVirtualHost.java:2581)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:2563)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1482)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1461)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1035)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1029)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2609)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2605)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> 

[jira] [Commented] (QPID-8070) Qpid java broker is unable to reconnect to database after kill -9 then restart

[ASF subversion and git services (JIRA)]

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

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

Commit 31d81ffe24b7c928bc855186258f74a8cf890a9a in qpid-broker-j's branch 
refs/heads/6.1.x from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=31d81ff ]

QPID-8070:[Broker-J][JDBC Store] Instantiate asynchronous commits executor on 
open of JDBC message store

Cherry picked from 14a53f619628570426466655ef2aa1edac9085a3


> Qpid java broker is unable to reconnect to database after kill -9 then restart
> --
>
> Key: QPID-8070
> URL: https://issues.apache.org/jira/browse/QPID-8070
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.4
>Reporter: Rabih Mourad
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-6.1.5, qpid-java-broker-7.0.1
>
>
> Hello,
> We are using Qpid java broker version 6.1.4.
> Our test case:
> We have a JMS client sending messages continuously in autoAck mode to a 
> messaging cluster. The cluster is composed of 1 dispatch router and 2 java 
> brokers which are connected to an Oracle Db.
> At some point, the test kills a broker using kill -9 and then attempts to 
> restart it.
> Randomly, we have a NullPointerException while the broker is restarting and 
> connecting to the virtual host node (the full error stack is at the end of 
> the email).
> Do you have any idea why this is happening? is there a chance that a kill
> -9 on a broker leaves the Db in an unstable state?
> Best regards,
> Rabih
> 2018-01-03 17:16:45,930 INFO  [VirtualHostNode-default-Config]
> (q.m.t.recovery_start) - [Broker]
> [vh(/default)/ms(GenericJDBCMessageStore)] TXN-1004 : Recovery Start
> 2018-01-03 17:16:45,938 WARN  [VirtualHostNode-default-Config]
> (o.a.q.s.v.SynchronousMessageStoreRecoverer) - Message id 1 in log references 
> queue with id 0b2a06aa-6d46-49aa-885f-63f3cd73108d which is not in the 
> configuration, entry will be discarded
> 2018-01-03 17:16:45,946 ERROR [VirtualHostNode-default-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name 
> 'default'.  Object will be put into ERROR state.
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.commitTranAsync(AbstractJDBCMessageStore.java:826)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.access$600(AbstractJDBCMessageStore.java:59)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCTransaction.commitTranAsync(AbstractJDBCMessageStore.java:1205)
> at
> org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.commitTranAsync(GenericAbstractJDBCMessageStore.java:142)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer$MessageInstanceVisitor.handle(SynchronousMessageStoreRecoverer.java:219)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCMessageStoreReader.visitMessageInstances(AbstractJDBCMessageStore.java:1911)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer.recover(SynchronousMessageStoreRecoverer.java:82)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.postCreateDefaultExchangeTasks(AbstractVirtualHost.java:2581)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:2563)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1482)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1461)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1035)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1029)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2609)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2605)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> 

[jira] [Commented] (DISPATCH-914) qd_connector_t leaks mutexes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-914:
-

GitHub user kgiusti opened a pull request:

https://github.com/apache/qpid-dispatch/pull/243

DISPATCH-914: correctly free mutex from qd_connector_t



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

$ git pull https://github.com/kgiusti/dispatch DISPATCH-914

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

https://github.com/apache/qpid-dispatch/pull/243.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 #243


commit 3c40c5797287e317d357fd885d4457d9d2dd9520
Author: Kenneth Giusti 
Date:   2018-01-16T15:18:14Z

DISPATCH-914: correctly free mutex from qd_connector_t




> qd_connector_t leaks mutexes
> 
>
> Key: DISPATCH-914
> URL: https://issues.apache.org/jira/browse/DISPATCH-914
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.1.0
> Environment: Unit tests fail with the following traceback when run 
> under valgrind:
>  
> 39: ==5443== 64 bytes in 1 blocks are definitely lost in loss record 1,047 of 
> 3,514
> 39: ==5443==    at 0x4C30D47: memalign (vg_replace_malloc.c:857)
> 39: ==5443==    by 0x4C30E45: posix_memalign (vg_replace_malloc.c:1020)
> 39: ==5443==    by 0x4E70B58: sys_mutex (threading.c:40)
> 39: ==5443==    by 0x4E8BCAA: qd_server_connector (server.c:1363)
> 39: ==5443==    by 0x4E61A49: qd_dispatch_configure_connector 
> (connection_manager.c:711)
> 39: ==5443==    by 0x10FC8BDD: ffi_call_unix64 (unix64.S:76)
> 39: ==5443==    by 0x10FC854E: ffi_call (ffi64.c:525)
> 39: ==5443==    by 0x10DB53A4: _ctypes_callproc (in 
> /usr/lib64/python2.7/lib-dynload/_ctypes.so)
> 39: ==5443==    by 0x10DAF0BD: ??? (in 
> /usr/lib64/python2.7/lib-dynload/_ctypes.so)
> 39: ==5443==    by 0x5BBE342: PyObject_Call (in 
> /usr/lib64/libpython2.7.so.1.0)
> 39: ==5443==    by 0x5C831B1: PyEval_EvalFrameEx (in 
> /usr/lib64/libpython2.7.so.1.0)
> 39: ==5443==    by 0x5C85B18: PyEval_EvalFrameEx (in 
> /usr/lib64/libpython2.7.so.1.0)
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.1.0
>
>




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

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

[GitHub] qpid-dispatch pull request #243: DISPATCH-914: correctly free mutex from qd_...

[kgiusti]

GitHub user kgiusti opened a pull request:

https://github.com/apache/qpid-dispatch/pull/243

DISPATCH-914: correctly free mutex from qd_connector_t



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

$ git pull https://github.com/kgiusti/dispatch DISPATCH-914

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

https://github.com/apache/qpid-dispatch/pull/243.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 #243


commit 3c40c5797287e317d357fd885d4457d9d2dd9520
Author: Kenneth Giusti 
Date:   2018-01-16T15:18:14Z

DISPATCH-914: correctly free mutex from qd_connector_t




---

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

[jira] [Commented] (QPID-8070) Qpid java broker is unable to reconnect to database after kill -9 then restart

[ASF subversion and git services (JIRA)]

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

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

Commit 887f535ea766ef9197b28a95f223b742044e5908 in qpid-broker-j's branch 
refs/heads/7.0.x from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=887f535 ]

QPID-8070: [Broker-J] [Unit Tests] Prevent tests leaking in-memory Derby 
instances

Cherry picked fromac5587287d67e1965273155a9d70e63d50f0c3b1


> Qpid java broker is unable to reconnect to database after kill -9 then restart
> --
>
> Key: QPID-8070
> URL: https://issues.apache.org/jira/browse/QPID-8070
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.4
>Reporter: Rabih Mourad
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-6.1.5, qpid-java-broker-7.0.1
>
>
> Hello,
> We are using Qpid java broker version 6.1.4.
> Our test case:
> We have a JMS client sending messages continuously in autoAck mode to a 
> messaging cluster. The cluster is composed of 1 dispatch router and 2 java 
> brokers which are connected to an Oracle Db.
> At some point, the test kills a broker using kill -9 and then attempts to 
> restart it.
> Randomly, we have a NullPointerException while the broker is restarting and 
> connecting to the virtual host node (the full error stack is at the end of 
> the email).
> Do you have any idea why this is happening? is there a chance that a kill
> -9 on a broker leaves the Db in an unstable state?
> Best regards,
> Rabih
> 2018-01-03 17:16:45,930 INFO  [VirtualHostNode-default-Config]
> (q.m.t.recovery_start) - [Broker]
> [vh(/default)/ms(GenericJDBCMessageStore)] TXN-1004 : Recovery Start
> 2018-01-03 17:16:45,938 WARN  [VirtualHostNode-default-Config]
> (o.a.q.s.v.SynchronousMessageStoreRecoverer) - Message id 1 in log references 
> queue with id 0b2a06aa-6d46-49aa-885f-63f3cd73108d which is not in the 
> configuration, entry will be discarded
> 2018-01-03 17:16:45,946 ERROR [VirtualHostNode-default-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name 
> 'default'.  Object will be put into ERROR state.
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.commitTranAsync(AbstractJDBCMessageStore.java:826)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.access$600(AbstractJDBCMessageStore.java:59)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCTransaction.commitTranAsync(AbstractJDBCMessageStore.java:1205)
> at
> org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.commitTranAsync(GenericAbstractJDBCMessageStore.java:142)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer$MessageInstanceVisitor.handle(SynchronousMessageStoreRecoverer.java:219)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCMessageStoreReader.visitMessageInstances(AbstractJDBCMessageStore.java:1911)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer.recover(SynchronousMessageStoreRecoverer.java:82)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.postCreateDefaultExchangeTasks(AbstractVirtualHost.java:2581)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:2563)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1482)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1461)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1035)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1029)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2609)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2605)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> 

[jira] [Commented] (QPID-8070) Qpid java broker is unable to reconnect to database after kill -9 then restart

[ASF subversion and git services (JIRA)]

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

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

Commit 14a53f619628570426466655ef2aa1edac9085a3 in qpid-broker-j's branch 
refs/heads/7.0.x from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=14a53f6 ]

QPID-8070:[Broker-J][JDBC Store] Instantiate asynchronous commits executor on 
open of JDBC message store

Cherry picked from 17d4b5607f3fe73b9a37c53d38b7db980cf0b245


> Qpid java broker is unable to reconnect to database after kill -9 then restart
> --
>
> Key: QPID-8070
> URL: https://issues.apache.org/jira/browse/QPID-8070
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.4
>Reporter: Rabih Mourad
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-6.1.5, qpid-java-broker-7.0.1
>
>
> Hello,
> We are using Qpid java broker version 6.1.4.
> Our test case:
> We have a JMS client sending messages continuously in autoAck mode to a 
> messaging cluster. The cluster is composed of 1 dispatch router and 2 java 
> brokers which are connected to an Oracle Db.
> At some point, the test kills a broker using kill -9 and then attempts to 
> restart it.
> Randomly, we have a NullPointerException while the broker is restarting and 
> connecting to the virtual host node (the full error stack is at the end of 
> the email).
> Do you have any idea why this is happening? is there a chance that a kill
> -9 on a broker leaves the Db in an unstable state?
> Best regards,
> Rabih
> 2018-01-03 17:16:45,930 INFO  [VirtualHostNode-default-Config]
> (q.m.t.recovery_start) - [Broker]
> [vh(/default)/ms(GenericJDBCMessageStore)] TXN-1004 : Recovery Start
> 2018-01-03 17:16:45,938 WARN  [VirtualHostNode-default-Config]
> (o.a.q.s.v.SynchronousMessageStoreRecoverer) - Message id 1 in log references 
> queue with id 0b2a06aa-6d46-49aa-885f-63f3cd73108d which is not in the 
> configuration, entry will be discarded
> 2018-01-03 17:16:45,946 ERROR [VirtualHostNode-default-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name 
> 'default'.  Object will be put into ERROR state.
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.commitTranAsync(AbstractJDBCMessageStore.java:826)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.access$600(AbstractJDBCMessageStore.java:59)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCTransaction.commitTranAsync(AbstractJDBCMessageStore.java:1205)
> at
> org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.commitTranAsync(GenericAbstractJDBCMessageStore.java:142)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer$MessageInstanceVisitor.handle(SynchronousMessageStoreRecoverer.java:219)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCMessageStoreReader.visitMessageInstances(AbstractJDBCMessageStore.java:1911)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer.recover(SynchronousMessageStoreRecoverer.java:82)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.postCreateDefaultExchangeTasks(AbstractVirtualHost.java:2581)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:2563)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1482)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1461)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1035)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1029)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2609)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2605)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> 

[jira] [Commented] (QPID-8070) Qpid java broker is unable to reconnect to database after kill -9 then restart

[ASF subversion and git services (JIRA)]

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

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

Commit ac5587287d67e1965273155a9d70e63d50f0c3b1 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=ac55872 ]

QPID-8070: [Broker-J] [Unit Tests] Prevent tests leaking in-memory Derby 
instances


> Qpid java broker is unable to reconnect to database after kill -9 then restart
> --
>
> Key: QPID-8070
> URL: https://issues.apache.org/jira/browse/QPID-8070
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.4
>Reporter: Rabih Mourad
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-6.1.5, qpid-java-broker-7.0.1
>
>
> Hello,
> We are using Qpid java broker version 6.1.4.
> Our test case:
> We have a JMS client sending messages continuously in autoAck mode to a 
> messaging cluster. The cluster is composed of 1 dispatch router and 2 java 
> brokers which are connected to an Oracle Db.
> At some point, the test kills a broker using kill -9 and then attempts to 
> restart it.
> Randomly, we have a NullPointerException while the broker is restarting and 
> connecting to the virtual host node (the full error stack is at the end of 
> the email).
> Do you have any idea why this is happening? is there a chance that a kill
> -9 on a broker leaves the Db in an unstable state?
> Best regards,
> Rabih
> 2018-01-03 17:16:45,930 INFO  [VirtualHostNode-default-Config]
> (q.m.t.recovery_start) - [Broker]
> [vh(/default)/ms(GenericJDBCMessageStore)] TXN-1004 : Recovery Start
> 2018-01-03 17:16:45,938 WARN  [VirtualHostNode-default-Config]
> (o.a.q.s.v.SynchronousMessageStoreRecoverer) - Message id 1 in log references 
> queue with id 0b2a06aa-6d46-49aa-885f-63f3cd73108d which is not in the 
> configuration, entry will be discarded
> 2018-01-03 17:16:45,946 ERROR [VirtualHostNode-default-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name 
> 'default'.  Object will be put into ERROR state.
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.commitTranAsync(AbstractJDBCMessageStore.java:826)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.access$600(AbstractJDBCMessageStore.java:59)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCTransaction.commitTranAsync(AbstractJDBCMessageStore.java:1205)
> at
> org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.commitTranAsync(GenericAbstractJDBCMessageStore.java:142)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer$MessageInstanceVisitor.handle(SynchronousMessageStoreRecoverer.java:219)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCMessageStoreReader.visitMessageInstances(AbstractJDBCMessageStore.java:1911)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer.recover(SynchronousMessageStoreRecoverer.java:82)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.postCreateDefaultExchangeTasks(AbstractVirtualHost.java:2581)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:2563)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1482)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1461)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1035)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1029)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2609)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2605)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2604)
> at
> 

[jira] [Created] (DISPATCH-914) qd_connector_t leaks mutexes

[Ken Giusti (JIRA)]

Ken Giusti created DISPATCH-914:
---

 Summary: qd_connector_t leaks mutexes
 Key: DISPATCH-914
 URL: https://issues.apache.org/jira/browse/DISPATCH-914
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Router Node
Affects Versions: 1.1.0
 Environment: Unit tests fail with the following traceback when run 
under valgrind:

 

39: ==5443== 64 bytes in 1 blocks are definitely lost in loss record 1,047 of 
3,514
39: ==5443==    at 0x4C30D47: memalign (vg_replace_malloc.c:857)
39: ==5443==    by 0x4C30E45: posix_memalign (vg_replace_malloc.c:1020)
39: ==5443==    by 0x4E70B58: sys_mutex (threading.c:40)
39: ==5443==    by 0x4E8BCAA: qd_server_connector (server.c:1363)
39: ==5443==    by 0x4E61A49: qd_dispatch_configure_connector 
(connection_manager.c:711)
39: ==5443==    by 0x10FC8BDD: ffi_call_unix64 (unix64.S:76)
39: ==5443==    by 0x10FC854E: ffi_call (ffi64.c:525)
39: ==5443==    by 0x10DB53A4: _ctypes_callproc (in 
/usr/lib64/python2.7/lib-dynload/_ctypes.so)
39: ==5443==    by 0x10DAF0BD: ??? (in 
/usr/lib64/python2.7/lib-dynload/_ctypes.so)
39: ==5443==    by 0x5BBE342: PyObject_Call (in /usr/lib64/libpython2.7.so.1.0)
39: ==5443==    by 0x5C831B1: PyEval_EvalFrameEx (in 
/usr/lib64/libpython2.7.so.1.0)
39: ==5443==    by 0x5C85B18: PyEval_EvalFrameEx (in 
/usr/lib64/libpython2.7.so.1.0)
Reporter: Ken Giusti
Assignee: Ken Giusti
 Fix For: 1.1.0






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

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

[jira] [Updated] (QPID-8076) [0-91] [Publisher Confirms] basic.ack returned to client before message is sync'd to disk

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8076:
-
Fix Version/s: qpid-java-broker-7.0.0

> [0-91] [Publisher Confirms] basic.ack returned to client before message is 
> sync'd to disk
> -
>
> Key: QPID-8076
> URL: https://issues.apache.org/jira/browse/QPID-8076
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: 0.32, qpid-java-6.0, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.0
>
>
> QPID-6164 added RabbitMQ's publish confirms [1] feature to Broker-J.  
> Concerning when the basic.ack is sent back to the client, the feature 
> documentation states:
> {quote}
> h3. When will messages be confirmed?
> ..
> For routable messages, the basic.ack is sent when a message has been accepted 
> by all the queues. For persistent messages routed to durable queues, this 
> *means persisting to disk*. 
> {quote}
> Currently, Broker-J does not behave in this way.  The {{basic.ack}} is 
> returned to the client before the auto-async transaction has confirmed that 
> the data is on disk.  The code is AMQChannel#deliverCurrentMessageIfComplete. 
>  It ought to arrange for the acks to be returned once the sync completes.
>  
> [1] [https://www.rabbitmq.com/confirms.html]



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

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

[jira] [Assigned] (QPID-8076) [0-91] [Publisher Confirms] basic.ack returned to client before message is sync'd to disk

[Keith Wall (JIRA)]

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

Keith Wall reassigned QPID-8076:


Assignee: Keith Wall

> [0-91] [Publisher Confirms] basic.ack returned to client before message is 
> sync'd to disk
> -
>
> Key: QPID-8076
> URL: https://issues.apache.org/jira/browse/QPID-8076
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: 0.32, qpid-java-6.0, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
>
> QPID-6164 added RabbitMQ's publish confirms [1] feature to Broker-J.  
> Concerning when the basic.ack is sent back to the client, the feature 
> documentation states:
> {quote}
> h3. When will messages be confirmed?
> ..
> For routable messages, the basic.ack is sent when a message has been accepted 
> by all the queues. For persistent messages routed to durable queues, this 
> *means persisting to disk*. 
> {quote}
> Currently, Broker-J does not behave in this way.  The {{basic.ack}} is 
> returned to the client before the auto-async transaction has confirmed that 
> the data is on disk.  The code is AMQChannel#deliverCurrentMessageIfComplete. 
>  It ought to arrange for the acks to be returned once the sync completes.
>  
> [1] [https://www.rabbitmq.com/confirms.html]



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

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

[jira] [Resolved] (QPID-8077) [AMQ 0-91] [Publisher Confirms] Improve validations when switching to confirms mode.

[Keith Wall (JIRA)]

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

Keith Wall resolved QPID-8077.
--
Resolution: Invalid

> [AMQ 0-91] [Publisher Confirms] Improve validations when switching to 
> confirms mode.
> 
>
> Key: QPID-8077
> URL: https://issues.apache.org/jira/browse/QPID-8077
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Trivial
> Fix For: qpid-java-broker-7.1.0
>
>
> The RabbitMQ documentation for publish confirms states that:
> {quote}A transactional channel cannot be put into confirm mode and once a 
> channel is in confirm mode, it cannot be made transactional.
> {quote}
>  
>  
>  



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

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

[jira] [Assigned] (QPID-8079) [Broker-J] If the future associated with an AsyncCommand completes abnormally, the associated action is not rolled-back

[Keith Wall (JIRA)]

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

Keith Wall reassigned QPID-8079:


Assignee: Keith Wall

> [Broker-J] If the future associated with an AsyncCommand completes 
> abnormally, the associated action is not rolled-back
> ---
>
> Key: QPID-8079
> URL: https://issues.apache.org/jira/browse/QPID-8079
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> The protocol layers currently use AsyncCommands to organise for work to be 
> completed after an async auto-commit transaction competes.  When 
> {{AsyncCommand#complete}} is invoked, it awaits completion of the future then 
> calls underlying action.  The code currently fails to call \{{onRollback}} in 
> the failure case.



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

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

[jira] [Updated] (QPID-8079) [Broker-J] If the future associated with an AsyncCommand completes abnormally, the associated action is not rolled-back

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8079:
-
Status: Reviewable  (was: In Progress)

> [Broker-J] If the future associated with an AsyncCommand completes 
> abnormally, the associated action is not rolled-back
> ---
>
> Key: QPID-8079
> URL: https://issues.apache.org/jira/browse/QPID-8079
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> The protocol layers currently use AsyncCommands to organise for work to be 
> completed after an async auto-commit transaction competes.  When 
> {{AsyncCommand#complete}} is invoked, it awaits completion of the future then 
> calls underlying action.  The code currently fails to call \{{onRollback}} in 
> the failure case.



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

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

[jira] [Commented] (QPID-8079) [Broker-J] If the future associated with an AsyncCommand completes abnormally, the associated action is not rolled-back

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-8079:
--

Given this defect does not currently cause a defect, I don't think this 
requires back porting.

> [Broker-J] If the future associated with an AsyncCommand completes 
> abnormally, the associated action is not rolled-back
> ---
>
> Key: QPID-8079
> URL: https://issues.apache.org/jira/browse/QPID-8079
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> The protocol layers currently use AsyncCommands to organise for work to be 
> completed after an async auto-commit transaction competes.  When 
> {{AsyncCommand#complete}} is invoked, it awaits completion of the future then 
> calls underlying action.  The code currently fails to call \{{onRollback}} in 
> the failure case.



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

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

[jira] [Commented] (PROTON-1703) [cpp] Remove auto_settle from receiver options

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell commented on PROTON-1703:


Note that the change was made then reverted to avoid API+ABI change in the 
0.19.0 release for such a trivial item when there weren't any other such 
changes. JIRA reopened in case a suitable opportunity presents itself later 
that it can be included along with other changes.

> [cpp] Remove auto_settle from receiver options
> --
>
> Key: PROTON-1703
> URL: https://issues.apache.org/jira/browse/PROTON-1703
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.19.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Minor
>
> auto_settle is a sender-only option, the receiver equivalent is auto_accept.
> auto_settle is only used at messaging_adapter.cpp#L172, which applies only to 
> senders, it was included in the option list by mistake.



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

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

[jira] [Updated] (QPID-8032) [AMQP1.0] AsyncAutoCommitTransaction optimisation

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8032:
-
Description: 
Some AMQP 1.0 messaging use-cases would benefit from the 
{{AsyncAutoCommitTransactions}} optimisation that is already in use on the 
older protocols.

For instance, for a publisher sending persistent settled messages, currently 
each message is written to disk and sync before the next message is the buffer 
is processed,. With this optimisation, the syncs would be allowed to coalesce.

  was:
Some AMQP 1.0 messaging use-cases would benefit from the 
{{AsyncAutoCommitTransactions}} optimisation that is already in use on the 
older protocols.

For instance, for a publisher sending persistent settled messages, currently 
each message is written to disk and sync before the next message is the buffer 
is processed,.  With this optimisation, the syncs would be allowed to coalesce. 
 

Care needs to be taken when the work includes actions that aren't 
non-transactional transfers to ensure that transactions remain ACID.



> [AMQP1.0] AsyncAutoCommitTransaction optimisation
> -
>
> Key: QPID-8032
> URL: https://issues.apache.org/jira/browse/QPID-8032
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
>
> Some AMQP 1.0 messaging use-cases would benefit from the 
> {{AsyncAutoCommitTransactions}} optimisation that is already in use on the 
> older protocols.
> For instance, for a publisher sending persistent settled messages, currently 
> each message is written to disk and sync before the next message is the 
> buffer is processed,. With this optimisation, the syncs would be allowed to 
> coalesce.



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

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

[jira] [Updated] (QPID-8032) [AMQP1.0] AsyncAutoCommitTransaction optimisation

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8032:
-
Status: Reviewable  (was: In Progress)

> [AMQP1.0] AsyncAutoCommitTransaction optimisation
> -
>
> Key: QPID-8032
> URL: https://issues.apache.org/jira/browse/QPID-8032
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
>
> Some AMQP 1.0 messaging use-cases would benefit from the 
> {{AsyncAutoCommitTransactions}} optimisation that is already in use on the 
> older protocols.
> For instance, for a publisher sending persistent settled messages, currently 
> each message is written to disk and sync before the next message is the 
> buffer is processed,.  With this optimisation, the syncs would be allowed to 
> coalesce.  
> Care needs to be taken when the work includes actions that aren't 
> non-transactional transfers to ensure that transactions remain ACID.



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

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

[jira] [Closed] (PROTON-390) Suppress or Fix the warnings openssl.c produce

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell closed PROTON-390.
-
   Resolution: Done
Fix Version/s: (was: proton-c-future)

The Travis CI build on OSX appears clear from anything like this, suggesting it 
was resolved at some point via other JIRAs. Closing.

> Suppress or Fix the warnings openssl.c produce
> --
>
> Key: PROTON-390
> URL: https://issues.apache.org/jira/browse/PROTON-390
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
> Environment: OS X
>Reporter: Hiram Chirino
>Priority: Major
>  Labels: osx
>
> openssl.c produces lots of warnings.
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c: In function 
> ‘_log_ssl_error’:
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:165: warning: 
> ‘ERR_get_error’ is deprecated (declared at /usr/include/openssl/err.h:266)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:167: warning: 
> ‘ERR_error_string_n’ is deprecated (declared at 
> /usr/include/openssl/err.h:280)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:169: warning: 
> ‘ERR_get_error’ is deprecated (declared at /usr/include/openssl/err.h:266)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c: In function 
> ‘ssl_failed’:
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:189: warning: 
> ‘ERR_get_error’ is deprecated (declared at /usr/include/openssl/err.h:266)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:191: warning: 
> ‘ERR_error_string_n’ is deprecated (declared at 
> /usr/include/openssl/err.h:280)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c: In function 
> ‘verify_callback’:
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:257: warning: 
> ‘X509_STORE_CTX_get_error_depth’ is deprecated (declared at 
> /usr/include/openssl/x509_vfy.h:453)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:261: warning: 
> ‘X509_STORE_CTX_get_current_cert’ is deprecated (declared at 
> /usr/include/openssl/x509_vfy.h:454)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:262: warning: 
> ‘X509_STORE_CTX_get_ex_data’ is deprecated (declared at 
> /usr/include/openssl/x509_vfy.h:450)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:262: warning: 
> ‘SSL_get_ex_data_X509_STORE_CTX_idx’ is deprecated (declared at 
> /usr/include/openssl/ssl.h:1601)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:268: warning: 
> ‘SSL_get_ex_data’ is deprecated (declared at /usr/include/openssl/ssl.h:1587)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:285: warning: 
> ‘X509_get_ext_d2i’ is deprecated (declared at 
> /usr/include/openssl/x509.h:1151)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:287: warning: 
> ‘sk_num’ is deprecated (declared at /usr/include/openssl/stack.h:81)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:290: warning: 
> ‘sk_value’ is deprecated (declared at /usr/include/openssl/stack.h:82)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:295: warning: 
> ‘ASN1_STRING_to_UTF8’ is deprecated (declared at 
> /usr/include/openssl/asn1.h:981)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:299: warning: 
> ‘CRYPTO_free’ is deprecated (declared at /usr/include/openssl/crypto.h:480)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:308: warning: 
> ‘X509_get_subject_name’ is deprecated (declared at 
> /usr/include/openssl/x509.h:1013)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:310: warning: 
> ‘X509_NAME_get_index_by_NID’ is deprecated (declared at 
> /usr/include/openssl/x509.h:1105)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:311: warning: 
> ‘X509_NAME_get_entry’ is deprecated (declared at 
> /usr/include/openssl/x509.h:1108)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:312: warning: 
> ‘X509_NAME_ENTRY_get_data’ is deprecated (declared at 
> /usr/include/openssl/x509.h:1130)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:315: warning: 
> ‘ASN1_STRING_to_UTF8’ is deprecated (declared at 
> /usr/include/openssl/asn1.h:981)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:319: warning: 
> ‘CRYPTO_free’ is deprecated (declared at /usr/include/openssl/crypto.h:480)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:329: warning: 
> ‘X509_STORE_CTX_set_error’ is deprecated (declared at 
> /usr/include/openssl/x509_vfy.h:452)
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c: In function 
> ‘get_dh2048’:
> /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:371: warning: 
> ‘DH_new’ is deprecated 

[jira] [Assigned] (DISPATCH-908) Router loses dispositions over receive link on qpid-interop-test 2-node test

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy reassigned DISPATCH-908:
--

Assignee: Ganesh Murthy

> Router loses dispositions over receive link on qpid-interop-test 2-node test
> 
>
> Key: DISPATCH-908
> URL: https://issues.apache.org/jira/browse/DISPATCH-908
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Kim van der Riet
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: dispatch-2node.qpid-cpp.jms_hdrs_props.pcapng, 
> qdrouterd.node1.conf, qdrouterd.node2.conf, qpidd.conf, scan0001.pdf
>
>
> When running qpid_interop_test.jms_hdrs_props_test, failures occur owing to 
> the improper disposition of messages on the central broker node which were 
> sent to the receiver. Analysis of the AMQP traffic shows that the Receiver 
> sent a disposition to Node 2, but Node 2 simply sent an AMQP detach without 
> any disposition to the broker.
> It is probable that the other QIT tests show this behavior, but don't exhibit 
> errors because no checks are made that the queues on the broker are empty 
> once the test ends, and no two tests share the same queue. The 
> jms_hdrs_props_test shares queues, allowing the improperly disposed messages 
> to remain in the queue and cause problems for the next test.
> The test is configured as follows:
> {noformat}
>9001 5672   5672 9002
> Sender --> Dispatch --> Broker --> Dispatch --> Receiver
> Node 1  Node 2
> {noformat}
> The configuration files for the broker (in this case, qpid-cpp) and the two 
> nodes are attached. Also attached are the wireshark capture file and a 
> diagram showing the AMQP traffic on the four links in sequence (scan0001.pdf).
> Notes on diagram:
> # If using the default Linux pdf viewer, the diagram can be rotated left in 
> the view menu to get it to display in the correct orientation.
> # The following abbreviations are used to display the AMQP performatives:
> H - header
> O - open
> B - begin
> AR - Attach as receiver
> AS - Attach as sender
> F - flow
> TN - transfer id=N
> DRN - disposition as receiver, settled=N
> DSN - disposition as sender, settled=N
> C - close
> X - detach
> E - end
> Bar is return direction traffic relative to traffic initiator.



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

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

[jira] [Commented] (DISPATCH-907) cannot set address phase via qdmanage tool

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-907:
-

Github user ganeshmurthy closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/242


> cannot set address phase via qdmanage tool
> --
>
> Key: DISPATCH-907
> URL: https://issues.apache.org/jira/browse/DISPATCH-907
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.0.0
>Reporter: Ken Giusti
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.1.0
>
>
> Attempting to configure a router address via qdmanage fails to set the value 
> of the phase attributes:
> $ qdmanage create --type "org.apache.qpid.dispatch.router.config.address" 
> pattern="a.b.#" ingressPhase=5 egressPhase=6
> {
>   "name": null, 
>   "pattern": "a.b.#", 
>   "prefix": null, 
>   "ingressPhase": 0,   <--- should be 5
>   "waypoint": false, 
>   "distribution": "balanced", 
>   "type": "org.apache.qpid.dispatch.router.config.address", 
>   "identity": "35", 
>   "egressPhase": 0  <--- should be 6
> This is due to qdmanage sending all attribute values as *string* types even 
> in the case where the schema defines them as integer types.  This means 
> qdmanage cannot be used to manage any integer type attribute.



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

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

[GitHub] qpid-dispatch pull request #242: DISPATCH-907 - Added code to qdmanage to ha...

[ganeshmurthy]

Github user ganeshmurthy closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/242


---

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

[jira] [Commented] (DISPATCH-907) cannot set address phase via qdmanage tool

[ASF subversion and git services (JIRA)]

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

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

Commit 791592a935fd2d9998fbf42fe4442d92cb999568 in qpid-dispatch's branch 
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=791592a ]

DISPATCH-907 - Added code to qdmanage to handle integer types


> cannot set address phase via qdmanage tool
> --
>
> Key: DISPATCH-907
> URL: https://issues.apache.org/jira/browse/DISPATCH-907
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.0.0
>Reporter: Ken Giusti
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.1.0
>
>
> Attempting to configure a router address via qdmanage fails to set the value 
> of the phase attributes:
> $ qdmanage create --type "org.apache.qpid.dispatch.router.config.address" 
> pattern="a.b.#" ingressPhase=5 egressPhase=6
> {
>   "name": null, 
>   "pattern": "a.b.#", 
>   "prefix": null, 
>   "ingressPhase": 0,   <--- should be 5
>   "waypoint": false, 
>   "distribution": "balanced", 
>   "type": "org.apache.qpid.dispatch.router.config.address", 
>   "identity": "35", 
>   "egressPhase": 0  <--- should be 6
> This is due to qdmanage sending all attribute values as *string* types even 
> in the case where the schema defines them as integer types.  This means 
> qdmanage cannot be used to manage any integer type attribute.



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

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

[jira] [Closed] (DISPATCH-913) system_tests_delivery_abort failing

[Chuck Rolke (JIRA)]

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

Chuck Rolke closed DISPATCH-913.

Resolution: Cannot Reproduce

Tests working again with the current master branches:

qpid-proton@0fe3b

qpid-dispatch@eed8b

 

> system_tests_delivery_abort failing
> ---
>
> Key: DISPATCH-913
> URL: https://issues.apache.org/jira/browse/DISPATCH-913
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.0.0
> Environment: Fedora 27  with kernel 4.14.11-300.fc27.x86_64
> Current master qpid-proton
>  
>Reporter: Chuck Rolke
>Priority: Major
>
> Self test command:
> {noformat}
> ctest -VV -R system_tests_delivery_abort{noformat}
> fails about 10% of the time with error:
> {noformat}
> 36: Test command: /usr/bin/python 
> "/home/chug/git/qpid-dispatch/build/tests/run.py" "-x" "unit2" "-v" 
> "system_tests_delivery_abort"
> 36: Test timeout computed to be: 1500
> 36: test_01_message_route_truncated_one_router 
> (system_tests_delivery_abort.RouterTest) ... ok
> 36: test_02_message_route_truncated_two_routers 
> (system_tests_delivery_abort.RouterTest) ... ok
> 36: test_03_link_route_truncated_one_router 
> (system_tests_delivery_abort.RouterTest) ... ok
> 36: test_04_link_route_truncated_two_routers 
> (system_tests_delivery_abort.RouterTest) ... ok
> 36: test_05_message_route_abort_one_router 
> (system_tests_delivery_abort.RouterTest) ... ok
> 36: test_06_message_route_abort_two_routers 
> (system_tests_delivery_abort.RouterTest) ... 
>   python2: /home/chug/git/qpid-proton/proton-c/src/core/engine.c:689:
>   pni_add_work: Assertion `!delivery->local.settled' failed.
> 1/1 Test #36: system_tests_delivery_abort ..***Exception: Child aborted  
> 5.06 sec
> 0% tests passed, 1 tests failed out of 1
> Total Test time (real) =   5.06 sec
> {noformat}
> This could be a Proton bug but there is a built-in reproducer in Dispatch so 
> I'm starting it here.
>  



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

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

[jira] [Resolved] (DISPATCH-907) cannot set address phase via qdmanage tool

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy resolved DISPATCH-907.

Resolution: Fixed

> cannot set address phase via qdmanage tool
> --
>
> Key: DISPATCH-907
> URL: https://issues.apache.org/jira/browse/DISPATCH-907
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.0.0
>Reporter: Ken Giusti
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.1.0
>
>
> Attempting to configure a router address via qdmanage fails to set the value 
> of the phase attributes:
> $ qdmanage create --type "org.apache.qpid.dispatch.router.config.address" 
> pattern="a.b.#" ingressPhase=5 egressPhase=6
> {
>   "name": null, 
>   "pattern": "a.b.#", 
>   "prefix": null, 
>   "ingressPhase": 0,   <--- should be 5
>   "waypoint": false, 
>   "distribution": "balanced", 
>   "type": "org.apache.qpid.dispatch.router.config.address", 
>   "identity": "35", 
>   "egressPhase": 0  <--- should be 6
> This is due to qdmanage sending all attribute values as *string* types even 
> in the case where the schema defines them as integer types.  This means 
> qdmanage cannot be used to manage any integer type attribute.



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

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

[jira] [Created] (QPID-8080) [Broker-J] Broker can crash when JDBC message store opens to many SQL connections to the RDBMS exceeding the maximum connection limit

[Alex Rudyy (JIRA)]

Alex Rudyy created QPID-8080:


 Summary: [Broker-J] Broker can crash when JDBC message store opens 
to many SQL connections to the RDBMS exceeding the maximum connection limit
 Key: QPID-8080
 URL: https://issues.apache.org/jira/browse/QPID-8080
 Project: Qpid
  Issue Type: Bug
  Components: Broker-J
Affects Versions: qpid-java-6.1.5, qpid-java-broker-7.0.0, qpid-java-6.0.8
 Environment: Broker-J with JDVC message store can crash when messaging 
client(s) consume or publish small messages in non-transactional manner (for 
example, when AUTO_ACK acknowledge mode is used by JMS client).

The broker creates \{{AsyncAutoCommitTransaction}} per each consumed/published 
message. Each transaction opens a separate connection to RDBMS server. The 
number of concurrent \{{AsyncAutoCommitTransaction}} can exceed the maximum 
connection limit. As result, sql connection establishment fails causing broker 
to crash with the stack trace like the one below:

{noformat}


#
# Unhandled Exception org.apache.qpid.server.util.ServerScopedRuntimeException: 
org.apache.qpid.server.store.StoreException: 
java.sql.SQLNonTransientConnectionException: Too many connections in Thread 
IO-/127.0.0.1:55228
#
# Exiting
#

org.apache.qpid.server.util.ServerScopedRuntimeException: 
org.apache.qpid.server.store.StoreException: 
java.sql.SQLNonTransientConnectionException: Too many connections
    at 
org.apache.qpid.server.protocol.v0_10.AMQPConnection_0_10Impl.lambda$received$1(AMQPConnection_0_10Impl.java:157)
    at java.security.AccessController.doPrivileged(Native Method)
    at 
org.apache.qpid.server.protocol.v0_10.AMQPConnection_0_10Impl.received(AMQPConnection_0_10Impl.java:141)
    at 
org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:134)
    at 
org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
    at 
org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
    at 
org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
    at 
org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
    at 
org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
    at 
org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:575)
    at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:366)
    at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
    at 
org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:533)
    at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at 
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
    at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.qpid.server.store.StoreException: 
java.sql.SQLNonTransientConnectionException: Too many connections
    at 
org.apache.qpid.server.store.jdbc.AbstractJDBCMessageStore$JDBCTransaction.(AbstractJDBCMessageStore.java:1065)
    at 
org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:122)
    at 
org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:118)
    at 
org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore.newTransaction(GenericAbstractJDBCMessageStore.java:114)
    at 
org.apache.qpid.server.txn.AsyncAutoCommitTransaction.dequeue(AsyncAutoCommitTransaction.java:104)
    at 
org.apache.qpid.server.protocol.v0_10.ServerSession.acknowledge(ServerSession.java:1185)
    at 
org.apache.qpid.server.protocol.v0_10.ConsumerTarget_0_10.acknowledge(ConsumerTarget_0_10.java:401)
    at 
org.apache.qpid.server.protocol.v0_10.ExplicitAcceptDispositionChangeListener.onAccept(ExplicitAcceptDispositionChangeListener.java:51)
    at 
org.apache.qpid.server.protocol.v0_10.ServerSession$2.performAction(ServerSession.java:1000)
    at 
org.apache.qpid.server.protocol.v0_10.ServerSession.dispositionChange(ServerSession.java:1091)
    at 
org.apache.qpid.server.protocol.v0_10.ServerSession.accept(ServerSession.java:995)
    at 
org.apache.qpid.server.protocol.v0_10.ServerSessionDelegate.messageAccept(ServerSessionDelegate.java:142)
    at 

[jira] [Commented] (QPID-8038) [Broker-J][System Tests] Add protocol system test suites for AMQP 0-x

[ASF subversion and git services (JIRA)]

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

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

Commit e906b9091a97a9c208e2c427728d4860f3d02ef5 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=e906b90 ]

QPID-8038: [Broker-J] [AMQP 0-8..0-91] Add publisher confirms with txn tests 
(Qpid extension to publsher confirmers).


> [Broker-J][System Tests] Add protocol system test suites for AMQP 0-x
> -
>
> Key: QPID-8038
> URL: https://issues.apache.org/jira/browse/QPID-8038
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J, Java Tests
>Reporter: Alex Rudyy
>Priority: Major
>
> We need a test frameworks which would allow creation of tests which would be 
> sending the AMQP 0-x performatives over TCP and receiving and asserting 
> broker responses.
> The framework should satisfy the following requirements:
> * It should allow running tests against other AMQP brokers
> * The framework should encapsulate starting/stopping of broker and queue 
> creation/deletion under special interface(s) which can be implemented by the 
> Broker developers in order to run tests against different Broker 
> implementations
> * Tests should be able to start and stop broker if required or configured
> * Tests should be able to generate AMQP performatives and assert received 
> peer's AMQP performatives
> * The framework should allow using other transport than TCP if required
> * The framework should be based on AMQP 0-x  implementations of Broker-J



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

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

[jira] [Commented] (QPID-7948) [Java Broker] [AMQP0-9] [Publish Confirms] Client hangs if message sent to topic within no subscribers

[ASF subversion and git services (JIRA)]

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

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

Commit fb98e76e86656799a9e16e6f09a6402b01bd2f2a 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=fb98e76 ]

QPID-7948: [Broker-J] [AMQP 0-9-1] [Publisher Confirms] Ensure that unroutable 
non-mandatory messages are acknowledged


> [Java Broker] [AMQP0-9] [Publish Confirms] Client hangs if message sent to 
> topic within no subscribers
> --
>
> Key: QPID-7948
> URL: https://issues.apache.org/jira/browse/QPID-7948
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: Future
>
>
> Testing on master today, If publish confirms is enabled, if I sent to a topic 
> with no subscribers, the client hangs in the following way:
> {noformat}
> javax.jms.JMSException: Server did not respond in a timely fashion
> at 
> org.apache.qpid.client.BasicMessageProducer_0_8.sendMessage(BasicMessageProducer_0_8.java:386)
> at 
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:549)
> at 
> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:333)
> at 
> org.apache.qpid.server.security.acl.MessagingACLTest.testPublishToTempTopicSuccess(MessagingACLTest.java:483)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.qpid.test.utils.QpidTestCase.runTest(QpidTestCase.java:181)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at 
> org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:91)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:165)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {noformat}
> Currently, the Broker does not send a nack in this case, but the client 
> awaits all the same.



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

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

[jira] [Commented] (QPID-8076) [0-91] [Publisher Confirms] basic.ack returned to client before message is sync'd to disk

[ASF subversion and git services (JIRA)]

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

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

Commit f03f718f98545f15859197f9a1f78f76a985e0a3 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=f03f718 ]

QPID-8076: [Broker-J] [AMQP 0-9-1] [Publisher Confirms] Delay sending publish 
confirms until underlying store transaction completes.


> [0-91] [Publisher Confirms] basic.ack returned to client before message is 
> sync'd to disk
> -
>
> Key: QPID-8076
> URL: https://issues.apache.org/jira/browse/QPID-8076
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: 0.32, qpid-java-6.0, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Major
>
> QPID-6164 added RabbitMQ's publish confirms [1] feature to Broker-J.  
> Concerning when the basic.ack is sent back to the client, the feature 
> documentation states:
> {quote}
> h3. When will messages be confirmed?
> ..
> For routable messages, the basic.ack is sent when a message has been accepted 
> by all the queues. For persistent messages routed to durable queues, this 
> *means persisting to disk*. 
> {quote}
> Currently, Broker-J does not behave in this way.  The {{basic.ack}} is 
> returned to the client before the auto-async transaction has confirmed that 
> the data is on disk.  The code is AMQChannel#deliverCurrentMessageIfComplete. 
>  It ought to arrange for the acks to be returned once the sync completes.
>  
> [1] [https://www.rabbitmq.com/confirms.html]



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

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

[jira] [Commented] (QPID-8079) [Broker-J] If the future associated with an AsyncCommand completes abnormally, the associated action is not rolled-back

[ASF subversion and git services (JIRA)]

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

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

Commit 5fa398cfc2141d6ec090df3464f5bcbf63d7b023 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=5fa398c ]

QPID-8079: [Broker-J] Ensure that actions associated with AsyncCommand are 
rolled back if the underlying future completes unsucessfully


> [Broker-J] If the future associated with an AsyncCommand completes 
> abnormally, the associated action is not rolled-back
> ---
>
> Key: QPID-8079
> URL: https://issues.apache.org/jira/browse/QPID-8079
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
>
> The protocol layers currently use AsyncCommands to organise for work to be 
> completed after an async auto-commit transaction competes.  When 
> {{AsyncCommand#complete}} is invoked, it awaits completion of the future then 
> calls underlying action.  The code currently fails to call \{{onRollback}} in 
> the failure case.



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

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

[jira] [Closed] (PROTON-803) Message codec improvements

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell closed PROTON-803.
-
   Resolution: Duplicate
Fix Version/s: (was: proton-j-future)

Closing this out. Various improvements to the existing codec were made via 
PROTON-1708 to improve its performance, further changes will be as a distinct 
effort.

> Message codec improvements
> --
>
> Key: PROTON-803
> URL: https://issues.apache.org/jira/browse/PROTON-803
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: 0.8
>Reporter: Rajith Attapattu
>Priority: Major
>  Labels: codec, patch, perf
>
> This JIRA covers improvements made to the codec, especially lists and maps.
> The work is based on 
> https://github.com/rhs/qpid-proton-old/tree/codec/proton-j/src/main/java/org/apache/qpid/proton/codec2
> The above referenced code, is quite an improvement with respect to writing 
> lists, maps and strings over the existing codec.
> Simply put the writeList and writeMap methods in the old encorder is about 
> ~10 times slower than the new encorder.
> If I run with a sufficiently large set of strings, the old encorder is about 
> ~2 times slower than the new encorder.



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

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

[jira] [Commented] (QPID-8074) [Qpid JMS AMQP 0-x] Build framework to run JMS client system tests

[ASF subversion and git services (JIRA)]

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

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

Commit c5488e7f52fb00e5a371a5a957ca7c5156efedd4 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=c5488e7 ]

QPID-8074: [JMS AMQP 0-x][System Tests] Exclude 
org.apache.qpid.systest.connection.HeartbeatTest#testUnidirectionalHeartbeating 
from CPP


> [Qpid JMS AMQP 0-x] Build framework to run JMS client system tests
> --
>
> Key: QPID-8074
> URL: https://issues.apache.org/jira/browse/QPID-8074
> Project: Qpid
>  Issue Type: Improvement
>  Components: JMS AMQP 0-x
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
>
> A number of JMS AMQP 0-x  client tests exist in Broker-J system test suite. 
> We need to move those tests from Broker-J source tree into JMS AMQP 0-x 
> sources. In order to do so, we need to build a new test framework which would 
> allow us to start Broker-J (and potentially Cpp Broker) and run the system 
> tests against the started broker.
> The test suite should use our virtualhost per test pattern. Check 
> {{BrokerAdmin}} idea in broker system tests.
> One wrinkle would be Java 8 - the tests would need Java 8 to run, even though 
> we want the client to remain Java 7 compatible.
> We could also write a broker admin allowing the tests to be run against the 
> CPPBroker



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

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

[jira] [Commented] (QPID-8077) [AMQ 0-91] [Publisher Confirms] Improve validations when switching to confirms mode.

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-8077:
--

Invalid.  I see now that QPID-6164 went beyond Rabbit's capabilities and 
allowed publisher confirms on transactional channels too.

> [AMQ 0-91] [Publisher Confirms] Improve validations when switching to 
> confirms mode.
> 
>
> Key: QPID-8077
> URL: https://issues.apache.org/jira/browse/QPID-8077
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Trivial
> Fix For: qpid-java-broker-7.1.0
>
>
> The RabbitMQ documentation for publish confirms states that:
> {quote}A transactional channel cannot be put into confirm mode and once a 
> channel is in confirm mode, it cannot be made transactional.
> {quote}
>  
>  
>  



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

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

[jira] [Comment Edited] (QPID-8079) [Broker-J] If the future associated with an AsyncCommand completes abnormally, the associated action is not rolled-back

[Keith Wall (JIRA)]

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

Keith Wall edited comment on QPID-8079 at 1/16/18 11:54 AM:


{{ServerTransaction.EnqueueAction}} are used in three places: 
{{QueueManagingVirtualHost.Transaction#move}}  and 
{{QueueManagingVirtualHost.Transaction#copy}} messages and the enqueue path 
{{RoutingResult#send}} .  The first two aren't affected as they are management 
operations, use local transactions and don't thus use the async auto-commit 
codes paths.   I think the enqueue path could be a problem in the HA case.  An 
unfortunately timed loss of quorum whilst a message is being enqueued causing 
the async auto commit transaction to fail could leak a message reference. (the 
release within the rollback path of 
{{org.apache.qpid.server.message.RoutingResult#send}} won't be called).  
However, as in the HA case the loss of quorum results in a new master, I think 
the net effect of the defect is currently nill.

In the non-HA case, if the underlying transaction fails, the Broker always 
fails, so again the net effect of the defect is nill.

I do think the {{AsyncCommand}} code should be correctly to call {{onRollback}} 
so this defect cannot bite in future. Separately, I notice that one of the 
{{AsyncAutoCommitTransaction#enqueue}} chains a {{postCommit}} rather than a 
{{onRollback}}.   This seems to a typo.  

 

 

 


was (Author: k-wall):
{{ServerTransaction.EnqueueAction}} are used in three places: 
{{QueueManagingVirtualHost.Transaction#move}}  and 
{{QueueManagingVirtualHost.Transaction#copy}} messages and the enqueue path 
{{RoutingResult#send}} .  The first two aren't affected as they are management 
operations, use local transactions and don't thus use the async auto-commit 
codes paths.   I think the enqueue path could be a problem in the HA case.  An 
unfortunately timed loss of quorum whilst a message is being enqueued causing 
the async auto commit transaction to fail could leak a message reference. (the 
release within the rollback path of 
org.apache.qpid.server.message.RoutingResult#send won't be called).  However, 
as in the HA case the loss of quorum results in a new master, I think the net 
effect of the defect is currently nill.

I do think the {{AsyncCommand}} code should be correctly to call {{onRollback}} 
so this defect cannot bite in future.

Separately, I notice that one of the AsyncAutoCommitTransaction#enqueue chains 
a {{postCommit}} rather than a {{onRollback}}.   This seems to a typo.  

 

 

 

> [Broker-J] If the future associated with an AsyncCommand completes 
> abnormally, the associated action is not rolled-back
> ---
>
> Key: QPID-8079
> URL: https://issues.apache.org/jira/browse/QPID-8079
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
>
> The protocol layers currently use AsyncCommands to organise for work to be 
> completed after an async auto-commit transaction competes.  When 
> {{AsyncCommand#complete}} is invoked, it awaits completion of the future then 
> calls underlying action.  The code currently fails to call \{{onRollback}} in 
> the failure case.



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

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

[jira] [Comment Edited] (QPID-8079) [Broker-J] If the future associated with an AsyncCommand completes abnormally, the associated action is not rolled-back

[Keith Wall (JIRA)]

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

Keith Wall edited comment on QPID-8079 at 1/16/18 11:54 AM:


{{ServerTransaction.EnqueueAction}} are used in three places: 
{{QueueManagingVirtualHost.Transaction#move}}  and 
{{QueueManagingVirtualHost.Transaction#copy}} messages and the enqueue path 
{{RoutingResult#send}} .  The first two aren't affected as they are management 
operations, use local transactions and don't thus use the async auto-commit 
codes paths.   I think the enqueue path could be a problem in the HA case.  An 
unfortunately timed loss of quorum whilst a message is being enqueued causing 
the async auto commit transaction to fail could leak a message reference. (the 
release within the rollback path of 
{{org.apache.qpid.server.message.RoutingResult#send}} won't be called).  
However, as in the HA case the loss of quorum results in a new master, I think 
the net effect of the defect is currently nill.

In the non-HA case, if the underlying transaction fails, the Broker always 
fails, so again the net effect of the defect is nill.

I do think the {{AsyncCommand}} code should be correctly to call {{onRollback}} 
so this defect cannot bite in future. Separately, I notice that one of the 
{{AsyncAutoCommitTransaction#enqueue}} chains a {{postCommit}} rather than a 
{{onRollback}}.   This seems to a typo.  


was (Author: k-wall):
{{ServerTransaction.EnqueueAction}} are used in three places: 
{{QueueManagingVirtualHost.Transaction#move}}  and 
{{QueueManagingVirtualHost.Transaction#copy}} messages and the enqueue path 
{{RoutingResult#send}} .  The first two aren't affected as they are management 
operations, use local transactions and don't thus use the async auto-commit 
codes paths.   I think the enqueue path could be a problem in the HA case.  An 
unfortunately timed loss of quorum whilst a message is being enqueued causing 
the async auto commit transaction to fail could leak a message reference. (the 
release within the rollback path of 
{{org.apache.qpid.server.message.RoutingResult#send}} won't be called).  
However, as in the HA case the loss of quorum results in a new master, I think 
the net effect of the defect is currently nill.

In the non-HA case, if the underlying transaction fails, the Broker always 
fails, so again the net effect of the defect is nill.

I do think the {{AsyncCommand}} code should be correctly to call {{onRollback}} 
so this defect cannot bite in future. Separately, I notice that one of the 
{{AsyncAutoCommitTransaction#enqueue}} chains a {{postCommit}} rather than a 
{{onRollback}}.   This seems to a typo.  

 

 

 

> [Broker-J] If the future associated with an AsyncCommand completes 
> abnormally, the associated action is not rolled-back
> ---
>
> Key: QPID-8079
> URL: https://issues.apache.org/jira/browse/QPID-8079
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
>
> The protocol layers currently use AsyncCommands to organise for work to be 
> completed after an async auto-commit transaction competes.  When 
> {{AsyncCommand#complete}} is invoked, it awaits completion of the future then 
> calls underlying action.  The code currently fails to call \{{onRollback}} in 
> the failure case.



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

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

[jira] [Updated] (QPID-8079) [Broker-J] If the future associated with an AsyncCommand completes abnormally, the associated action is not rolled-back

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8079:
-
Priority: Minor  (was: Major)

> [Broker-J] If the future associated with an AsyncCommand completes 
> abnormally, the associated action is not rolled-back
> ---
>
> Key: QPID-8079
> URL: https://issues.apache.org/jira/browse/QPID-8079
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
>
> The protocol layers currently use AsyncCommands to organise for work to be 
> completed after an async auto-commit transaction competes.  When 
> {{AsyncCommand#complete}} is invoked, it awaits completion of the future then 
> calls underlying action.  The code currently fails to call \{{onRollback}} in 
> the failure case.



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

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

[jira] [Comment Edited] (QPID-8079) [Broker-J] If the future associated with an AsyncCommand completes abnormally, the associated action is not rolled-back

[Keith Wall (JIRA)]

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

Keith Wall edited comment on QPID-8079 at 1/16/18 11:49 AM:


{{ServerTransaction.EnqueueAction}} are used in three places: 
{{QueueManagingVirtualHost.Transaction#move}}  and 
{{QueueManagingVirtualHost.Transaction#copy}} messages and the enqueue path 
{{RoutingResult#send}} .  The first two aren't affected as they are management 
operations, use local transactions and don't thus use the async auto-commit 
codes paths.   I think the enqueue path could be a problem in the HA case.  An 
unfortunately timed loss of quorum whilst a message is being enqueued causing 
the async auto commit transaction to fail could leak a message reference. (the 
release within the rollback path of 
org.apache.qpid.server.message.RoutingResult#send won't be called).  However, 
as in the HA case the loss of quorum results in a new master, I think the net 
effect of the defect is currently nill.

I do think the {{AsyncCommand}} code should be correctly to call {{onRollback}} 
so this defect cannot bite in future.

Separately, I notice that one of the AsyncAutoCommitTransaction#enqueue chains 
a {{postCommit}} rather than a {{onRollback}}.   This seems to a typo.  

 

 

 


was (Author: k-wall):
{{ServerTransaction.EnqueueAction}} are used in three places: 
{{QueueManagingVirtualHost.Transaction#move}}  and 
{{QueueManagingVirtualHost.Transaction#copy}} messages and the enqueue path 
{{RoutingResult#send}} .  The first two aren't affected as they are management 
operations, use local transactions and don't thus use the async auto-commit 
codes paths.   I think the enqueue path could be a problem in the HA case.  An 
unfortunately timed loss of quorum whilst a message is being enqueued causing 
the async auto commit transaction to fail could leak a message reference. 
However, as in the HA case the loss of quorum results in a new master, I think 
the net effect of the defect is currently nill.

I do think the {{AsyncCommand}} code should be correctly to call {{onRollback}} 
so this defect cannot bite in future.

 

 

> [Broker-J] If the future associated with an AsyncCommand completes 
> abnormally, the associated action is not rolled-back
> ---
>
> Key: QPID-8079
> URL: https://issues.apache.org/jira/browse/QPID-8079
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
>
> The protocol layers currently use AsyncCommands to organise for work to be 
> completed after an async auto-commit transaction competes.  When 
> {{AsyncCommand#complete}} is invoked, it awaits completion of the future then 
> calls underlying action.  The code currently fails to call \{{onRollback}} in 
> the failure case.



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

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

[jira] [Commented] (QPID-8079) [Broker-J] If the future associated with an AsyncCommand completes abnormally, the associated action is not rolled-back

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-8079:
--

{{ServerTransaction.EnqueueAction}} are used in three places: 
{{QueueManagingVirtualHost.Transaction#move}}  and 
{{QueueManagingVirtualHost.Transaction#copy}} messages and the enqueue path 
{{RoutingResult#send}} .  The first two aren't affected as they are management 
operations, use local transactions and don't thus use the async auto-commit 
codes paths.   I think the enqueue path could be a problem in the HA case.  An 
unfortunately timed loss of quorum whilst a message is being enqueued causing 
the async auto commit transaction to fail could leak a message reference. 
However, as in the HA case the loss of quorum results in a new master, I think 
the net effect of the defect is currently nill.

I do think the {{AsyncCommand}} code should be correctly to call {{onRollback}} 
so this defect cannot bite in future.

 

 

> [Broker-J] If the future associated with an AsyncCommand completes 
> abnormally, the associated action is not rolled-back
> ---
>
> Key: QPID-8079
> URL: https://issues.apache.org/jira/browse/QPID-8079
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
>
> The protocol layers currently use AsyncCommands to organise for work to be 
> completed after an async auto-commit transaction competes.  When 
> {{AsyncCommand#complete}} is invoked, it awaits completion of the future then 
> calls underlying action.  The code currently fails to call \{{onRollback}} in 
> the failure case.



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

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

[jira] [Created] (QPID-8079) [Broker-J] If the future associated with an AsyncCommand completes abnormally, the associated action is not rolled-back

[Keith Wall (JIRA)]

Keith Wall created QPID-8079:


 Summary: [Broker-J] If the future associated with an AsyncCommand 
completes abnormally, the associated action is not rolled-back
 Key: QPID-8079
 URL: https://issues.apache.org/jira/browse/QPID-8079
 Project: Qpid
  Issue Type: Bug
  Components: Broker-J
Reporter: Keith Wall


The protocol layers currently use AsyncCommands to organise for work to be 
completed after an async auto-commit transaction competes.  When 
{{AsyncCommand#complete}} is invoked, it awaits completion of the future then 
calls underlying action.  The code currently fails to call \{{onRollback}} in 
the failure case.



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

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

[jira] [Updated] (QPID-8078) error by compiling

[Daniel Gavrila (JIRA)]

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

Daniel Gavrila updated QPID-8078:
-
Environment: 
linearstore option is enabled

gcc 4.8.5 with c++11 flag enabled

 

The problem is  0  :

should be nullptr or static_cast(0)

 

  was:
linearstore option is enabled

gcc 7.2 with c++11 flag enabled

 

The problem is  0  :

should be nullptr or static_cast(0)

 


> error by compiling
> --
>
> Key: QPID-8078
> URL: https://issues.apache.org/jira/browse/QPID-8078
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Build
>Affects Versions: qpid-cpp-1.37.0
> Environment: linearstore option is enabled
> gcc 4.8.5 with c++11 flag enabled
>  
> The problem is  0  :
> should be nullptr or static_cast(0)
>  
>Reporter: Daniel Gavrila
>Priority: Minor
> Attachments: error-qpid
>
>
> [ 73%] Building CXX object 
> src/CMakeFiles/linearstore.dir/qpid/linearstore/MessageStoreImpl.cpp.o
> /usr/local/projects/gema4_dds/pkg/qpid-cpp-1.37.0/src/qpid/linearstore/MessageStoreImpl.cpp:
>  In member function ‘void 
> qpid::linearstore::MessageStoreImpl::init(bool)’:
> /usr/local/projects/gema4_dds/pkg/qpid-cpp-1.37.0/src/qpid/linearstore/MessageStoreImpl.cpp:230:36:
>  error: call of overloaded ‘DbEnv(int)’ is ambiguous
>  dbenv.reset(new DbEnv(0));
>     ^
> /usr/local/projects/gema4_dds/pkg/qpid-cpp-1.37.0/src/qpid/linearstore/MessageStoreImpl.cpp:230:36:
>  note: candidates are:
> In file included from 
> /usr/local/projects/gema4_dds/pkg/qpid-cpp-1.37.0/objdir/src/db-inc.h:1:0,
>  from 
> /usr/local/projects/gema4_dds/pkg/qpid-cpp-1.37.0/src/qpid/linearstore/BindingDbt.h:25,
>  from 
> /usr/local/projects/gema4_dds/pkg/qpid-cpp-1.37.0/src/qpid/linearstore/MessageStoreImpl.cpp:27:
> /usr/local/projects/gema4_dds/pkg/DBBerkley/include/db_cxx.h:916:2: note: 
> DbEnv::DbEnv(const DbEnv&)
>   DbEnv(const DbEnv &);
>   ^
> /usr/local/projects/gema4_dds/pkg/DBBerkley/include/db_cxx.h:518:2: note: 
> DbEnv::DbEnv(DB_ENV*)
>   DbEnv(DB_ENV *dbenv);
>   ^
> /usr/local/projects/gema4_dds/pkg/DBBerkley/include/db_cxx.h:516:2: note: 
> DbEnv::DbEnv(u_int32_t)
>   DbEnv(u_int32_t flags);
>   ^
> make[2]: *** 
> [src/CMakeFiles/linearstore.dir/qpid/linearstore/MessageStoreImpl.cpp.o] 
> Error 1
> make[1]: *** [src/CMakeFiles/linearstore.dir/all] Error 2
> make: *** [all] Error 2



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

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

[ANNOUNCE] Apache Qpid Proton-J 0.25.0 released

[Robbie Gemmell]

The Apache Qpid (http://qpid.apache.org) community is pleased to announce
the immediate availability of Apache Qpid Proton-J 0.25.0.

Apache Qpid Proton-J is a messaging library for the Advanced Message Queuing
Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, http://www.amqp.org). It can be used
in a wide range of messaging applications including brokers, clients,
routers, bridges, proxies, and more.

The release is available now from our website:
http://qpid.apache.org/download.html

Binaries are also available via Maven Central:
http://qpid.apache.org/maven.html

Release notes can be found at:
http://qpid.apache.org/releases/qpid-proton-j-0.25.0/release-notes.html

Thanks to all involved,
Robbie

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

[jira] [Created] (QPID-8078) error by compiling

[Daniel Gavrila (JIRA)]

Daniel Gavrila created QPID-8078:


 Summary: error by compiling
 Key: QPID-8078
 URL: https://issues.apache.org/jira/browse/QPID-8078
 Project: Qpid
  Issue Type: Bug
  Components: C++ Build
Affects Versions: qpid-cpp-1.37.0
 Environment: linearstore option is enabled

gcc 7.2 with c++11 flag enabled

 

The problem is  0  :

should be nullptr or static_cast(0)

 
Reporter: Daniel Gavrila
 Attachments: error-qpid

[ 73%] Building CXX object 
src/CMakeFiles/linearstore.dir/qpid/linearstore/MessageStoreImpl.cpp.o
/usr/local/projects/gema4_dds/pkg/qpid-cpp-1.37.0/src/qpid/linearstore/MessageStoreImpl.cpp:
 In member function ‘void qpid::linearstore::MessageStoreImpl::init(bool)’:
/usr/local/projects/gema4_dds/pkg/qpid-cpp-1.37.0/src/qpid/linearstore/MessageStoreImpl.cpp:230:36:
 error: call of overloaded ‘DbEnv(int)’ is ambiguous
 dbenv.reset(new DbEnv(0));
    ^
/usr/local/projects/gema4_dds/pkg/qpid-cpp-1.37.0/src/qpid/linearstore/MessageStoreImpl.cpp:230:36:
 note: candidates are:
In file included from 
/usr/local/projects/gema4_dds/pkg/qpid-cpp-1.37.0/objdir/src/db-inc.h:1:0,
 from 
/usr/local/projects/gema4_dds/pkg/qpid-cpp-1.37.0/src/qpid/linearstore/BindingDbt.h:25,
 from 
/usr/local/projects/gema4_dds/pkg/qpid-cpp-1.37.0/src/qpid/linearstore/MessageStoreImpl.cpp:27:
/usr/local/projects/gema4_dds/pkg/DBBerkley/include/db_cxx.h:916:2: note: 
DbEnv::DbEnv(const DbEnv&)
  DbEnv(const DbEnv &);
  ^
/usr/local/projects/gema4_dds/pkg/DBBerkley/include/db_cxx.h:518:2: note: 
DbEnv::DbEnv(DB_ENV*)
  DbEnv(DB_ENV *dbenv);
  ^
/usr/local/projects/gema4_dds/pkg/DBBerkley/include/db_cxx.h:516:2: note: 
DbEnv::DbEnv(u_int32_t)
  DbEnv(u_int32_t flags);
  ^
make[2]: *** 
[src/CMakeFiles/linearstore.dir/qpid/linearstore/MessageStoreImpl.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/linearstore.dir/all] Error 2
make: *** [all] Error 2



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

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

[jira] [Updated] (QPID-8077) [AMQ 0-91] [Publisher Confirms] Improve validations when switching to confirms mode.

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8077:
-
Summary: [AMQ 0-91] [Publisher Confirms] Improve validations when switching 
to confirms mode.  (was: [AMQ 0-91] [Publisher Confirms] Improve validations 
when switch to confirms mode.)

> [AMQ 0-91] [Publisher Confirms] Improve validations when switching to 
> confirms mode.
> 
>
> Key: QPID-8077
> URL: https://issues.apache.org/jira/browse/QPID-8077
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Trivial
> Fix For: qpid-java-broker-7.1.0
>
>
> The RabbitMQ documentation for publish confirms states that:
> {quote}A transactional channel cannot be put into confirm mode and once a 
> channel is in confirm mode, it cannot be made transactional.
> {quote}
>  
>  
>  



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

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

[jira] [Created] (QPID-8077) [AMQ 0-91] [Publisher Confirms] Improve validations when switch to confirms mode.

[Keith Wall (JIRA)]

Keith Wall created QPID-8077:


 Summary: [AMQ 0-91] [Publisher Confirms] Improve validations when 
switch to confirms mode.
 Key: QPID-8077
 URL: https://issues.apache.org/jira/browse/QPID-8077
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J
Reporter: Keith Wall
 Fix For: qpid-java-broker-7.1.0


The RabbitMQ documentation for publish confirms states that:
{quote}A transactional channel cannot be put into confirm mode and once a 
channel is in confirm mode, it cannot be made transactional.
{quote}
 

 

 



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

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

[jira] [Commented] (PROTON-1729) [OSX] Update MacPorts Portfile to utilize tagged 0.19.0 version

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell commented on PROTON-1729:


As this is about a downstream packaging effort I wouldn't say it really 
warrants a specific JIRA being raised here. A comment on the lists would seem 
more suited, if anything.

> [OSX] Update MacPorts Portfile to utilize tagged 0.19.0 version
> ---
>
> Key: PROTON-1729
> URL: https://issues.apache.org/jira/browse/PROTON-1729
> Project: Qpid Proton
>  Issue Type: Improvement
>Affects Versions: proton-c-0.19.0
> Environment: OSX 10.11.6
> Xcode 7.3.1
>Reporter: Roddie Kieley
>Priority: Minor
>
> The release of 0.19.0 marks the first official tagged release that builds on 
> OSX "out of the box". A MacPorts Portfile for Qpid Proton was added as soon 
> as a commit became available that would build on OSX in the 0.18.1++ 
> timeframe and this should be updated to utilize the 0.19.0 release.



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

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

[jira] [Closed] (PROTON-1729) [OSX] Update MacPorts Portfile to utilize tagged 0.19.0 version

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell closed PROTON-1729.
--

> [OSX] Update MacPorts Portfile to utilize tagged 0.19.0 version
> ---
>
> Key: PROTON-1729
> URL: https://issues.apache.org/jira/browse/PROTON-1729
> Project: Qpid Proton
>  Issue Type: Improvement
>Affects Versions: proton-c-0.19.0
> Environment: OSX 10.11.6
> Xcode 7.3.1
>Reporter: Roddie Kieley
>Priority: Minor
>
> The release of 0.19.0 marks the first official tagged release that builds on 
> OSX "out of the box". A MacPorts Portfile for Qpid Proton was added as soon 
> as a commit became available that would build on OSX in the 0.18.1++ 
> timeframe and this should be updated to utilize the 0.19.0 release.



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

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

[jira] [Updated] (PROTON-1725) [ruby] broker example does not work if run outside home directory

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated PROTON-1725:
---
Fix Version/s: proton-c-0.19.0

> [ruby] broker example does not work if run outside home directory
> -
>
> Key: PROTON-1725
> URL: https://issues.apache.org/jira/browse/PROTON-1725
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.19.0
>
>
> The ruby broker example looks for SSL config files in the current directory 
> and is supposed to proceed without SSL if it doesn't find them. Due to a 
> typo, it instead creates an invalid SSL context and refuses all comers.



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

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

[jira] [Assigned] (PROTON-1732) [OSX] Enable swig for the Travis CI build

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell reassigned PROTON-1732:
--

 Assignee: Andrew Stitcher
Fix Version/s: (was: proton-c-future)
   proton-c-0.20.0

> [OSX] Enable swig for the Travis CI build
> -
>
> Key: PROTON-1732
> URL: https://issues.apache.org/jira/browse/PROTON-1732
> Project: Qpid Proton
>  Issue Type: Sub-task
>  Components: proton-c
>Affects Versions: proton-c-0.19.0
> Environment: Travis CI
> Xcode 7.3, 9
>Reporter: Roddie Kieley
>Assignee: Andrew Stitcher
>Priority: Minor
> Fix For: proton-c-0.20.0
>
>
> Comparing the current travis builds for linux and osx we see that the linux 
> builds cover ruby whereas the osx builds do not. Swig is required for this to 
> occur.



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

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

[jira] [Updated] (PROTON-1742) there is no send example that works well with selected_recv

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated PROTON-1742:
---
Fix Version/s: (was: proton-c-0.21.0)
   proton-c-0.20.0
  Component/s: examples

Updated fix version.

> there is no send example that works well with selected_recv
> ---
>
> Key: PROTON-1742
> URL: https://issues.apache.org/jira/browse/PROTON-1742
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: examples
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Minor
> Fix For: proton-c-0.20.0
>
> Attachments: selected_recv_cpp_test.patch
>
>




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

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

[jira] [Updated] (PROTON-1702) Fix epoll proactor listener for rearming and overflow per socket

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated PROTON-1702:
---
Fix Version/s: (was: proton-j-0.19.0)
   proton-c-0.19.0

Corrected fix-version

> Fix epoll proactor listener for rearming and overflow per socket
> 
>
> Key: PROTON-1702
> URL: https://issues.apache.org/jira/browse/PROTON-1702
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: proton-c-0.18.1
> Environment: Linux epoll
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
>Priority: Major
> Fix For: proton-c-0.19.0
>
>
> This addresses the comment
>   // TODO: armed logic should be per socket not per aggregate listener
> which is a required step to add logic to safely shutdown a listener 
> (PROTON-1531).  The overflow logic needs similar per socket updating.
> Additional issues to address while addressing this code change:
>   pclosefd - fix deadlock on recursive lock for listener sockets
>   socket array size to 1 on failure to match realloc
>   check for need to wakeup listener if pn_listener_accept() not called from 
> or close to ACCEPT event callback (i.e. not "working").



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

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

[jira] [Commented] (QPID-8076) [0-91] [Publisher Confirms] basic.ack returned to client before message is sync'd to disk

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-8076:
--

My analysis is partly duff.   The problem actually only affects the HA case.  
In the non-HA case, the failure of the store commit future will halt the Broker 
and this will happen before the \{{basic.ack}} hits the wire. However in the HA 
case, the failure of the store commit future is not necessarily fatal (for 
instance in the case of too few replicas), so in this case the Broker will 
claim from the messages have been accepted when in actual fact, they are lost. 

> [0-91] [Publisher Confirms] basic.ack returned to client before message is 
> sync'd to disk
> -
>
> Key: QPID-8076
> URL: https://issues.apache.org/jira/browse/QPID-8076
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: 0.32, qpid-java-6.0, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Major
>
> QPID-6164 added RabbitMQ's publish confirms [1] feature to Broker-J.  
> Concerning when the basic.ack is sent back to the client, the feature 
> documentation states:
> {quote}
> h3. When will messages be confirmed?
> ..
> For routable messages, the basic.ack is sent when a message has been accepted 
> by all the queues. For persistent messages routed to durable queues, this 
> *means persisting to disk*. 
> {quote}
> Currently, Broker-J does not behave in this way.  The {{basic.ack}} is 
> returned to the client before the auto-async transaction has confirmed that 
> the data is on disk.  The code is AMQChannel#deliverCurrentMessageIfComplete. 
>  It ought to arrange for the acks to be returned once the sync completes.
>  
> [1] [https://www.rabbitmq.com/confirms.html]



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

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

[jira] [Updated] (QPID-8070) Qpid java broker is unable to reconnect to database after kill -9 then restart

[Alex Rudyy (JIRA)]

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

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

> Qpid java broker is unable to reconnect to database after kill -9 then restart
> --
>
> Key: QPID-8070
> URL: https://issues.apache.org/jira/browse/QPID-8070
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.4
>Reporter: Rabih Mourad
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-6.1.5, qpid-java-broker-7.0.1
>
>
> Hello,
> We are using Qpid java broker version 6.1.4.
> Our test case:
> We have a JMS client sending messages continuously in autoAck mode to a 
> messaging cluster. The cluster is composed of 1 dispatch router and 2 java 
> brokers which are connected to an Oracle Db.
> At some point, the test kills a broker using kill -9 and then attempts to 
> restart it.
> Randomly, we have a NullPointerException while the broker is restarting and 
> connecting to the virtual host node (the full error stack is at the end of 
> the email).
> Do you have any idea why this is happening? is there a chance that a kill
> -9 on a broker leaves the Db in an unstable state?
> Best regards,
> Rabih
> 2018-01-03 17:16:45,930 INFO  [VirtualHostNode-default-Config]
> (q.m.t.recovery_start) - [Broker]
> [vh(/default)/ms(GenericJDBCMessageStore)] TXN-1004 : Recovery Start
> 2018-01-03 17:16:45,938 WARN  [VirtualHostNode-default-Config]
> (o.a.q.s.v.SynchronousMessageStoreRecoverer) - Message id 1 in log references 
> queue with id 0b2a06aa-6d46-49aa-885f-63f3cd73108d which is not in the 
> configuration, entry will be discarded
> 2018-01-03 17:16:45,946 ERROR [VirtualHostNode-default-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name 
> 'default'.  Object will be put into ERROR state.
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.commitTranAsync(AbstractJDBCMessageStore.java:826)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore.access$600(AbstractJDBCMessageStore.java:59)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCTransaction.commitTranAsync(AbstractJDBCMessageStore.java:1205)
> at
> org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.commitTranAsync(GenericAbstractJDBCMessageStore.java:142)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer$MessageInstanceVisitor.handle(SynchronousMessageStoreRecoverer.java:219)
> at
> org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCMessageStoreReader.visitMessageInstances(AbstractJDBCMessageStore.java:1911)
> at
> org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer.recover(SynchronousMessageStoreRecoverer.java:82)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.postCreateDefaultExchangeTasks(AbstractVirtualHost.java:2581)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:2563)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1482)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1461)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1035)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1029)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2609)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2605)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2604)
> at
> com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:404)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:187)
> at
>