[jira] [Commented] (PROTON-1533) Swig deprecation warnings with recent versions of cmake

2017-08-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on PROTON-1533:


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

https://github.com/apache/qpid-proton/pull/115#discussion_r132225370
  
--- Diff: proton-c/bindings/php/CMakeLists.txt ---
@@ -34,7 +34,7 @@ list(APPEND SWIG_MODULE_cproton_EXTRA_DEPS
 ${CMAKE_SOURCE_DIR}/proton-c/include/proton/cproton.i
 ${PROTON_HEADERS}
 )
-swig_add_module(cproton php ${CMAKE_CURRENT_SOURCE_DIR}/php.i)
+swig_add_library(cproton LANGUAGE php SOURCES 
${CMAKE_CURRENT_SOURCE_DIR}/php.i)
--- End diff --

Not directly related to your change, but I think the 
${CMAKE_CURRENT_SOURCE_DIR} is extraneous here and is different from all the 
other uses of swig_add_library in the other bindings.


> Swig deprecation warnings with recent versions of cmake
> ---
>
> Key: PROTON-1533
> URL: https://issues.apache.org/jira/browse/PROTON-1533
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: build
> Environment: Fedora 25, 26
> Cmake 3.8+
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Minor
> Fix For: proton-c-0.18.0
>
>
> Same output as described in https://issues.apache.org/jira/browse/QPID-7860



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class

2017-08-09 Thread Jiri Danek (JIRA)

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

Jiri Danek commented on QPIDJMS-313:


Thanks for investigating. The difference between what I have and what the Qpid 
JMS test suite has is essentially this

{code}
diff --git 
a/qpid-jms-client/src/test/java/org/apache/qpid/jms/message/JmsBytesMessageTest.java
 
b/qpid-jms-client/src/test/java/org/apache/qpid/jms/message/JmsBytesMessageTest.java
index d56c533c..330f1208 100644
--- 
a/qpid-jms-client/src/test/java/org/apache/qpid/jms/message/JmsBytesMessageTest.java
+++ 
b/qpid-jms-client/src/test/java/org/apache/qpid/jms/message/JmsBytesMessageTest.java
@@ -968,8 +968,6 @@ public class JmsBytesMessageTest {
 public void testGetBodyThrowsMessageFormatException() throws JMSException {
 JmsBytesMessage bytesMessage = factory.createBytesMessage();
 bytesMessage.setStringProperty("property", "value");
-bytesMessage.writeByte((byte) 1);
-bytesMessage.writeInt(22);
 
 try {
 bytesMessage.getBody(StringBuffer.class);
{code}

If I remove the two lines (do not set any content of the message) then the Qpid 
JMS suite starts failing.

> Message#getBody does not throw when attempting to read a BytesMessage as 
> String.class
> -
>
> Key: QPIDJMS-313
> URL: https://issues.apache.org/jira/browse/QPIDJMS-313
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.23.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Consider the ActiveMQ Artemis test 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
>  adapted to run through multiple JMS ConnectionFactories in turn. This test 
> passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
> OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.
> {noformat}
>  BytesMessage bytesMessage = sess.createBytesMessage();
>  producer.send(bytesMessage);
>  Message msg = cons.receiveNoWait();
>  assertNotNull(msg);
>  try {
> msg.getBody(String.class);
> fail("Exception expected");
>  } catch (MessageFormatException e) {
>  }
> {noformat}
> The failing line is the {{fail("Exception expected");}}, because qpid-jms 
> does not throw {{MessageFormatException}} where it is supposed to.
> According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If 
> the message is a BytesMessage then this parameter must be set to byte[].class 
> (or java.lang.Object.class). This method will reset the BytesMessage before 
> and after use." ... "Throws: MessageFormatException" ... "if the message body 
> cannot be assigned to the specified type."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class

2017-08-09 Thread Jiri Danek (JIRA)

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

Jiri Danek commented on QPIDJMS-313:


Agreed. I've reported that as ARTEMIS-1341.

> Message#getBody does not throw when attempting to read a BytesMessage as 
> String.class
> -
>
> Key: QPIDJMS-313
> URL: https://issues.apache.org/jira/browse/QPIDJMS-313
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.23.0, 0.24.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Consider the ActiveMQ Artemis test 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
>  adapted to run through multiple JMS ConnectionFactories in turn. This test 
> passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
> OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.
> {noformat}
>  BytesMessage bytesMessage = sess.createBytesMessage();
>  producer.send(bytesMessage);
>  Message msg = cons.receiveNoWait();
>  assertNotNull(msg);
>  try {
> msg.getBody(String.class);
> fail("Exception expected");
>  } catch (MessageFormatException e) {
>  }
> {noformat}
> The failing line is the {{fail("Exception expected");}}, because qpid-jms 
> does not throw {{MessageFormatException}} where it is supposed to.
> According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If 
> the message is a BytesMessage then this parameter must be set to byte[].class 
> (or java.lang.Object.class). This method will reset the BytesMessage before 
> and after use." ... "Throws: MessageFormatException" ... "if the message body 
> cannot be assigned to the specified type."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (PROTON-1533) Swig deprecation warnings with recent versions of cmake

2017-08-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on PROTON-1533:


Github user ssorj closed the pull request at:

https://github.com/apache/qpid-proton/pull/115


> Swig deprecation warnings with recent versions of cmake
> ---
>
> Key: PROTON-1533
> URL: https://issues.apache.org/jira/browse/PROTON-1533
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: build
> Environment: Fedora 25, 26
> Cmake 3.8+
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Minor
> Fix For: proton-c-0.18.0
>
>
> Same output as described in https://issues.apache.org/jira/browse/QPID-7860



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Reopened] (PROTON-1278) [Proton-c] Closing connection in proton::handler puts connection in TIME_WAIT state

2017-08-09 Thread Alan Conway (JIRA)

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

Alan Conway reopened PROTON-1278:
-

> [Proton-c] Closing connection in proton::handler puts connection in TIME_WAIT 
> state
> ---
>
> Key: PROTON-1278
> URL: https://issues.apache.org/jira/browse/PROTON-1278
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding, proton-c
>Affects Versions: 0.12.2
>Reporter: Adel Boutros
>Assignee: Justin Ross
>  Labels: reproducer
> Fix For: proton-c-0.18.0
>
> Attachments: ConnectionTimeWaitState.cpp, Wireshark output.png
>
>
> You can check 
> [Nabble|http://qpid.2158936.n2.nabble.com/Java-Broker-6-0-1-AMQP-random-errors-when-sending-messages-using-Proton-c-0-12-2-td7648822.html]
>   for more details.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...

2017-08-09 Thread ganeshmurthy
GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-803 - The following changes were made to support forbidden d…

…istribution

1. Added a new attribute to the router entity called called 
defaultDistribution which defaults to balanced
but can be set to forbidden
2. Attaches to forbidden addresses are rejected and the link is detached
3. Anonymous senders sending to forbidden addresses will be sent back a 
disposition of PN_REJECTED but link will not be closed
4. Added system test system_tests_default_distribution.py to test the above 
cases

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

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

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

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


commit 6ddee464d11e570fdfe8f2599e1587c3f4fc0c42
Author: Ganesh Murthy 
Date:   2017-08-09T17:41:08Z

DISPATCH-803 - The following changes were made to support forbidden 
distribution
1. Added a new attribute to the router entity called called 
defaultDistribution which defaults to balanced
but can be set to forbidden
2. Attaches to forbidden addresses are rejected and the link is detached
3. Anonymous senders sending to forbidden addresses will be sent back a 
disposition of PN_REJECTED but link will not be closed
4. Added system test system_tests_default_distribution.py to test the above 
cases




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

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



[jira] [Commented] (DISPATCH-803) refuse attach to undefined addresses

2017-08-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on DISPATCH-803:
-

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-803 - The following changes were made to support forbidden d…

…istribution

1. Added a new attribute to the router entity called called 
defaultDistribution which defaults to balanced
but can be set to forbidden
2. Attaches to forbidden addresses are rejected and the link is detached
3. Anonymous senders sending to forbidden addresses will be sent back a 
disposition of PN_REJECTED but link will not be closed
4. Added system test system_tests_default_distribution.py to test the above 
cases

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

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

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

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


commit 6ddee464d11e570fdfe8f2599e1587c3f4fc0c42
Author: Ganesh Murthy 
Date:   2017-08-09T17:41:08Z

DISPATCH-803 - The following changes were made to support forbidden 
distribution
1. Added a new attribute to the router entity called called 
defaultDistribution which defaults to balanced
but can be set to forbidden
2. Attaches to forbidden addresses are rejected and the link is detached
3. Anonymous senders sending to forbidden addresses will be sent back a 
disposition of PN_REJECTED but link will not be closed
4. Added system test system_tests_default_distribution.py to test the above 
cases




> refuse attach to undefined addresses
> 
>
> Key: DISPATCH-803
> URL: https://issues.apache.org/jira/browse/DISPATCH-803
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> At present, if you attach to an address in the router whose semantics have 
> not been specifically defined, you get balanced message routing semantics.
> It would be useful to be able to configure the router such that it would 
> refuse links whose source/target was not explicitly defined. E.g. by being 
> able to configure the default semantics to be of type 'invalid' (or anything 
> similar). (Being able to explicitly blacklist certain addresses might also be 
> nice, but is a more exotic use case I think).
> Messages sent through an anonymous link to these 'invalid' addresses would be 
> rejected.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Assigned] (QPID-7860) [cpp] Build produces deprecation warnings on recent Fedora

2017-08-09 Thread Justin Ross (JIRA)

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

Justin Ross reassigned QPID-7860:
-

Assignee: Justin Ross

> [cpp] Build produces deprecation warnings on recent Fedora
> --
>
> Key: QPID-7860
> URL: https://issues.apache.org/jira/browse/QPID-7860
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, C++ Client
>Affects Versions: qpid-cpp-1.36.0
> Environment: Fedora 25
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Minor
>  Labels: patch
> Fix For: 1.37.0
>
> Attachments: swig-deprecation.patch
>
>
> {noformat}
> -- Found SWIG: /usr/bin/swig (found version "3.0.11") 
> -- Found PythonLibs: /usr/lib64/libpython2.7.so (found version "2.7.13") 
> -- Found Perl: /usr/bin/perl (found version "5.24.1") 
> -- Found PerlLibs: /usr/lib64/libperl.so (found version "5.24.1") 
> -- Building Python bindings
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226 
> (message):
>   SWIG_ADD_MODULE is deprecated.  Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
>   bindings/qpid/python/CMakeLists.txt:35 (swig_add_module)
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226 
> (message):
>   SWIG_ADD_MODULE is deprecated.  Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
>   bindings/qmf2/python/CMakeLists.txt:35 (swig_add_module)
> -- Building Ruby bindings
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226 
> (message):
>   SWIG_ADD_MODULE is deprecated.  Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
>   bindings/qpid/ruby/CMakeLists.txt:48 (swig_add_module)
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226 
> (message):
>   SWIG_ADD_MODULE is deprecated.  Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
>   bindings/qmf2/ruby/CMakeLists.txt:39 (swig_add_module)
> -- Building Perl bindings
> CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226 
> (message):
>   SWIG_ADD_MODULE is deprecated.  Use SWIG_ADD_LIBRARY instead.
> Call Stack (most recent call first):
>   bindings/qpid/perl/CMakeLists.txt:31 (swig_add_module)
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/jross/code/qpid-cpp/bld
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[GitHub] qpid-dispatch pull request #181: Dispatch 731- configure wildcard addresses

2017-08-09 Thread asfgit
Github user asfgit closed the pull request at:

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


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

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



[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...

2017-08-09 Thread ted-ross
Github user ted-ross commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/185#discussion_r132260270
  
--- Diff: src/router_core/connections.c ---
@@ -1300,9 +1310,15 @@ static void 
qdr_link_inbound_first_attach_CT(qdr_core_t *core, qdr_action_t *act
 //
 // This link has a target address
 //
-bool   link_route;
-qdr_address_t *addr = qdr_lookup_terminus_address_CT(core, 
dir, conn, target, true, true, _route);
-if (!addr) {
+bool  link_route;
+bool  forbidden;
+qdr_address_t *addr = qdr_lookup_terminus_address_CT(core, 
dir, conn, target, true, true, _route, );
+if (forbidden) {
+qdr_link_outbound_detach_CT(core, link, 0, 
QDR_CONDITION_FORBIDDEN, true);
--- End diff --

Does this do the right thing protocol-wise?  Does the router send an attach 
with NULL terminus followed by a detach?


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

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



[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...

2017-08-09 Thread ted-ross
Github user ted-ross commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/185#discussion_r132261405
  
--- Diff: src/router_core/transfer.c ---
@@ -634,6 +634,23 @@ static void qdr_link_forward_CT(qdr_core_t *core, 
qdr_link_t *link, qdr_delivery
 addr->deliveries_ingress++;
 link->total_deliveries++;
 }
+//
+// There is no address that we can send this delivery to, which means 
the addr was not found in our hastable. This
+// can be because there were no receivers or because the address was 
not defined in the config file.
+// If the treatment for such addresses is set to be forbidden, we send 
back a rejected disposition and detach the link
+//
+else if (core->qd->treatment == QD_TREATMENT_LINK_FORBIDDEN) {
+dlv->disposition = PN_REJECTED;
+dlv->error = qdr_error("qd:forbidden", "Sending deliveries to this 
address is forbidden");
--- End diff --

You should be using one of the AMQP-specified error conditions that is in 
the amqp.[ch] files.  It seems that the appropriate error condition is 
"amqp:not-allowed", not "forbidden" (which is an error code only for the 
management protocol).


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

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



[jira] [Commented] (DISPATCH-803) refuse attach to undefined addresses

2017-08-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on DISPATCH-803:
-

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

https://github.com/apache/qpid-dispatch/pull/185#discussion_r132275310
  
--- Diff: include/qpid/dispatch/router.h ---
@@ -42,7 +42,8 @@ typedef enum {
 QD_TREATMENT_MULTICAST_ONCE   = 1,
 QD_TREATMENT_ANYCAST_CLOSEST  = 2,
 QD_TREATMENT_ANYCAST_BALANCED = 3,
-QD_TREATMENT_LINK_BALANCED= 4
+QD_TREATMENT_LINK_BALANCED= 4,
+QD_TREATMENT_LINK_FORBIDDEN   = 5
--- End diff --

Changed QD_TREATMENT_LINK_FORBIDDEN to QD_TREATMENT_FORBIDDEN


> refuse attach to undefined addresses
> 
>
> Key: DISPATCH-803
> URL: https://issues.apache.org/jira/browse/DISPATCH-803
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> At present, if you attach to an address in the router whose semantics have 
> not been specifically defined, you get balanced message routing semantics.
> It would be useful to be able to configure the router such that it would 
> refuse links whose source/target was not explicitly defined. E.g. by being 
> able to configure the default semantics to be of type 'invalid' (or anything 
> similar). (Being able to explicitly blacklist certain addresses might also be 
> nice, but is a more exotic use case I think).
> Messages sent through an anonymous link to these 'invalid' addresses would be 
> rejected.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...

2017-08-09 Thread ganeshmurthy
Github user ganeshmurthy commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/185#discussion_r132275399
  
--- Diff: src/dispatch_private.h ---
@@ -52,6 +52,7 @@ struct qd_dispatch_t {
 qd_connection_manager_t *connection_manager;
 qd_policy_t *policy;
 void*dl_handle;
+qd_address_treatment_t   treatment;
--- End diff --

Changed treatment to default_treatment


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

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



[jira] [Commented] (PROTON-785) pn_code is missing one error code

2017-08-09 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on PROTON-785:


Commit 4d25d88f5c96165c7c6aa24c28d214ad599caff8 in qpid-proton's branch 
refs/heads/master from [~jr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=4d25d88 ]

PROTON-785: Add missing error code


> pn_code is missing one error code
> -
>
> Key: PROTON-785
> URL: https://issues.apache.org/jira/browse/PROTON-785
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.7, 0.8
> Environment: Linux
>Reporter: Andreas Welchlin
>Assignee: Justin Ross
>Priority: Trivial
> Fix For: proton-c-0.18.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> In error.c there is one error code missing in function pn_code:
> const char *pn_code(int code)
> {
>   switch (code)
>   {
>   case 0: return "";
>   case PN_EOS: return "PN_EOS";
>   case PN_ERR: return "PN_ERR";
>   case PN_OVERFLOW: return "PN_OVERFLOW";
>   case PN_UNDERFLOW: return "PN_UNDERFLOW";
>   case PN_STATE_ERR: return "PN_STATE_ERR";
>   case PN_ARG_ERR: return "PN_ARG_ERR";
>   case PN_TIMEOUT: return "PN_TIMEOUT";
>   case PN_INTR: return "PN_INTR";
>   default: return "";
>   }
> }
> There should also be:
>   case PN_INPROGRESS: return "PN_INPROGRESS";



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (PROTON-584) Proton-c transport reserves large buffers for brief use

2017-08-09 Thread Alan Conway (JIRA)

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

Alan Conway commented on PROTON-584:


Not necessary but need to think carefully about how/when to reduce the buffer 
size. Re-allocating a buffer for each message is expensive, so keeping a buffer 
that is "big enough for most messages" is a performance win. The buffer also 
can hold more than one frame, and reading/writing multiple frames in a single 
read is an important performance win. The current scheme works well for streams 
of messages that don't have "exceptionallly large" outlier messages - so the 
trick will be to shrink buffers that have grown because of one "exceptionally 
large" message without  penalizing the "normal sized" message stream by with 
very small reads or frequent re-allocations.

What are the stats for your message traffic? How much do "exceptional" messages 
diverge from "normal" messages in size? Would a statically configured 
min/normal-max settings work (never reduce below min, if you go over normal-max 
shrink back to normal-max ASAP)? Adaptive schemes based on past 
traffic/buffer-size/max-read might also be worth considering.

> Proton-c transport reserves large buffers for brief use
> ---
>
> Key: PROTON-584
> URL: https://issues.apache.org/jira/browse/PROTON-584
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.8
>Reporter: Cliff Jansen
>Assignee: Alan Conway
>  Labels: perf
> Fix For: proton-c-0.19.0
>
>
> When processing transfer frames for incoming messages, Proton requires a 
> temporary buffer holding the whole transfer frame briefly in contiguous space 
> in the transport before moving it to the engine proper which holds the 
> content in a separate memory area.
> pn_transport_capacity grows the buffer in the non-ssl case 
> (transport->input_buf), and openssl.c largely duplicates the code (including 
> the comment about "no limit") for ssl->inbuf for ssl connections.
> Either way, a large message will trigger reserving a similarly large buffer 
> for the rest of the life of the connection.
> Is it necessary for the transport to buffer the whole message body and hang 
> on to that memory?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Closed] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class

2017-08-09 Thread Timothy Bish (JIRA)

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

Timothy Bish closed QPIDJMS-313.

Resolution: Not A Problem

This is already tested to work but I've added a few other variations that show 
it works in the client test suite.  I'd recommend checking your tests.  If you 
can supply a reproducer test for the Qpid JMS suite feel free to reopen. 

> Message#getBody does not throw when attempting to read a BytesMessage as 
> String.class
> -
>
> Key: QPIDJMS-313
> URL: https://issues.apache.org/jira/browse/QPIDJMS-313
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.23.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Consider the ActiveMQ Artemis test 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
>  adapted to run through multiple JMS ConnectionFactories in turn. This test 
> passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
> OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.
> {noformat}
>  BytesMessage bytesMessage = sess.createBytesMessage();
>  producer.send(bytesMessage);
>  Message msg = cons.receiveNoWait();
>  assertNotNull(msg);
>  try {
> msg.getBody(String.class);
> fail("Exception expected");
>  } catch (MessageFormatException e) {
>  }
> {noformat}
> The failing line is the {{fail("Exception expected");}}, because qpid-jms 
> does not throw {{MessageFormatException}} where it is supposed to.
> According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If 
> the message is a BytesMessage then this parameter must be set to byte[].class 
> (or java.lang.Object.class). This method will reset the BytesMessage before 
> and after use." ... "Throws: MessageFormatException" ... "if the message body 
> cannot be assigned to the specified type."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[GitHub] qpid-proton pull request #115: PROTON-1533: Fix swig deprecation warnings

2017-08-09 Thread astitcher
Github user astitcher commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/115#discussion_r132225370
  
--- Diff: proton-c/bindings/php/CMakeLists.txt ---
@@ -34,7 +34,7 @@ list(APPEND SWIG_MODULE_cproton_EXTRA_DEPS
 ${CMAKE_SOURCE_DIR}/proton-c/include/proton/cproton.i
 ${PROTON_HEADERS}
 )
-swig_add_module(cproton php ${CMAKE_CURRENT_SOURCE_DIR}/php.i)
+swig_add_library(cproton LANGUAGE php SOURCES 
${CMAKE_CURRENT_SOURCE_DIR}/php.i)
--- End diff --

Not directly related to your change, but I think the 
${CMAKE_CURRENT_SOURCE_DIR} is extraneous here and is different from all the 
other uses of swig_add_library in the other bindings.


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

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



[jira] [Commented] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class

2017-08-09 Thread Timothy Bish (JIRA)

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

Timothy Bish commented on QPIDJMS-313:
--

Ah, so then your assumption of the result is incorrect then, if you read the 
Message API you will see that the bullet point below the one you quoted says:

{quote}
f the message is a TextMessage, ObjectMessage, MapMessage or BytesMessage and 
the message has no body, then the above does not apply and this parameter may 
be set to any type; the returned value will always be null.
{quote}

> Message#getBody does not throw when attempting to read a BytesMessage as 
> String.class
> -
>
> Key: QPIDJMS-313
> URL: https://issues.apache.org/jira/browse/QPIDJMS-313
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.23.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Consider the ActiveMQ Artemis test 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
>  adapted to run through multiple JMS ConnectionFactories in turn. This test 
> passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
> OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.
> {noformat}
>  BytesMessage bytesMessage = sess.createBytesMessage();
>  producer.send(bytesMessage);
>  Message msg = cons.receiveNoWait();
>  assertNotNull(msg);
>  try {
> msg.getBody(String.class);
> fail("Exception expected");
>  } catch (MessageFormatException e) {
>  }
> {noformat}
> The failing line is the {{fail("Exception expected");}}, because qpid-jms 
> does not throw {{MessageFormatException}} where it is supposed to.
> According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If 
> the message is a BytesMessage then this parameter must be set to byte[].class 
> (or java.lang.Object.class). This method will reset the BytesMessage before 
> and after use." ... "Throws: MessageFormatException" ... "if the message body 
> cannot be assigned to the specified type."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Closed] (PROTON-1278) [Proton-c] Closing connection in proton::handler puts connection in TIME_WAIT state

2017-08-09 Thread Alan Conway (JIRA)

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

Alan Conway closed PROTON-1278.
---
Resolution: Won't Fix

> [Proton-c] Closing connection in proton::handler puts connection in TIME_WAIT 
> state
> ---
>
> Key: PROTON-1278
> URL: https://issues.apache.org/jira/browse/PROTON-1278
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding, proton-c
>Affects Versions: 0.12.2
>Reporter: Adel Boutros
>Assignee: Justin Ross
>  Labels: reproducer
> Fix For: proton-c-0.18.0
>
> Attachments: ConnectionTimeWaitState.cpp, Wireshark output.png
>
>
> You can check 
> [Nabble|http://qpid.2158936.n2.nabble.com/Java-Broker-6-0-1-AMQP-random-errors-when-sending-messages-using-Proton-c-0-12-2-td7648822.html]
>   for more details.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...

2017-08-09 Thread ted-ross
Github user ted-ross commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/185#discussion_r132259545
  
--- Diff: src/dispatch_private.h ---
@@ -52,6 +52,7 @@ struct qd_dispatch_t {
 qd_connection_manager_t *connection_manager;
 qd_policy_t *policy;
 void*dl_handle;
+qd_address_treatment_t   treatment;
--- End diff --

Shouldn't this be called default_treatment?


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

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



[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...

2017-08-09 Thread ted-ross
Github user ted-ross commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/185#discussion_r132259033
  
--- Diff: include/qpid/dispatch/router.h ---
@@ -42,7 +42,8 @@ typedef enum {
 QD_TREATMENT_MULTICAST_ONCE   = 1,
 QD_TREATMENT_ANYCAST_CLOSEST  = 2,
 QD_TREATMENT_ANYCAST_BALANCED = 3,
-QD_TREATMENT_LINK_BALANCED= 4
+QD_TREATMENT_LINK_BALANCED= 4,
+QD_TREATMENT_LINK_FORBIDDEN   = 5
--- End diff --

This constant should not have "_LINK_" in it.  That implies that this is 
only for link-routing.  You should rename it "QD_TREATMENT_FORBIDDEN" because 
this feature is not relevant for link-routing.


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

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



[jira] [Commented] (DISPATCH-803) refuse attach to undefined addresses

2017-08-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on DISPATCH-803:
-

Github user ted-ross commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/185#discussion_r132259545
  
--- Diff: src/dispatch_private.h ---
@@ -52,6 +52,7 @@ struct qd_dispatch_t {
 qd_connection_manager_t *connection_manager;
 qd_policy_t *policy;
 void*dl_handle;
+qd_address_treatment_t   treatment;
--- End diff --

Shouldn't this be called default_treatment?


> refuse attach to undefined addresses
> 
>
> Key: DISPATCH-803
> URL: https://issues.apache.org/jira/browse/DISPATCH-803
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> At present, if you attach to an address in the router whose semantics have 
> not been specifically defined, you get balanced message routing semantics.
> It would be useful to be able to configure the router such that it would 
> refuse links whose source/target was not explicitly defined. E.g. by being 
> able to configure the default semantics to be of type 'invalid' (or anything 
> similar). (Being able to explicitly blacklist certain addresses might also be 
> nice, but is a more exotic use case I think).
> Messages sent through an anonymous link to these 'invalid' addresses would be 
> rejected.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (DISPATCH-803) refuse attach to undefined addresses

2017-08-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on DISPATCH-803:
-

Github user ted-ross commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/185#discussion_r132259033
  
--- Diff: include/qpid/dispatch/router.h ---
@@ -42,7 +42,8 @@ typedef enum {
 QD_TREATMENT_MULTICAST_ONCE   = 1,
 QD_TREATMENT_ANYCAST_CLOSEST  = 2,
 QD_TREATMENT_ANYCAST_BALANCED = 3,
-QD_TREATMENT_LINK_BALANCED= 4
+QD_TREATMENT_LINK_BALANCED= 4,
+QD_TREATMENT_LINK_FORBIDDEN   = 5
--- End diff --

This constant should not have "_LINK_" in it.  That implies that this is 
only for link-routing.  You should rename it "QD_TREATMENT_FORBIDDEN" because 
this feature is not relevant for link-routing.


> refuse attach to undefined addresses
> 
>
> Key: DISPATCH-803
> URL: https://issues.apache.org/jira/browse/DISPATCH-803
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> At present, if you attach to an address in the router whose semantics have 
> not been specifically defined, you get balanced message routing semantics.
> It would be useful to be able to configure the router such that it would 
> refuse links whose source/target was not explicitly defined. E.g. by being 
> able to configure the default semantics to be of type 'invalid' (or anything 
> similar). (Being able to explicitly blacklist certain addresses might also be 
> nice, but is a more exotic use case I think).
> Messages sent through an anonymous link to these 'invalid' addresses would be 
> rejected.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (DISPATCH-803) refuse attach to undefined addresses

2017-08-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on DISPATCH-803:
-

Github user ted-ross commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/185#discussion_r132260270
  
--- Diff: src/router_core/connections.c ---
@@ -1300,9 +1310,15 @@ static void 
qdr_link_inbound_first_attach_CT(qdr_core_t *core, qdr_action_t *act
 //
 // This link has a target address
 //
-bool   link_route;
-qdr_address_t *addr = qdr_lookup_terminus_address_CT(core, 
dir, conn, target, true, true, _route);
-if (!addr) {
+bool  link_route;
+bool  forbidden;
+qdr_address_t *addr = qdr_lookup_terminus_address_CT(core, 
dir, conn, target, true, true, _route, );
+if (forbidden) {
+qdr_link_outbound_detach_CT(core, link, 0, 
QDR_CONDITION_FORBIDDEN, true);
--- End diff --

Does this do the right thing protocol-wise?  Does the router send an attach 
with NULL terminus followed by a detach?


> refuse attach to undefined addresses
> 
>
> Key: DISPATCH-803
> URL: https://issues.apache.org/jira/browse/DISPATCH-803
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> At present, if you attach to an address in the router whose semantics have 
> not been specifically defined, you get balanced message routing semantics.
> It would be useful to be able to configure the router such that it would 
> refuse links whose source/target was not explicitly defined. E.g. by being 
> able to configure the default semantics to be of type 'invalid' (or anything 
> similar). (Being able to explicitly blacklist certain addresses might also be 
> nice, but is a more exotic use case I think).
> Messages sent through an anonymous link to these 'invalid' addresses would be 
> rejected.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (DISPATCH-803) refuse attach to undefined addresses

2017-08-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on DISPATCH-803:
-

Github user ted-ross commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/185#discussion_r132261405
  
--- Diff: src/router_core/transfer.c ---
@@ -634,6 +634,23 @@ static void qdr_link_forward_CT(qdr_core_t *core, 
qdr_link_t *link, qdr_delivery
 addr->deliveries_ingress++;
 link->total_deliveries++;
 }
+//
+// There is no address that we can send this delivery to, which means 
the addr was not found in our hastable. This
+// can be because there were no receivers or because the address was 
not defined in the config file.
+// If the treatment for such addresses is set to be forbidden, we send 
back a rejected disposition and detach the link
+//
+else if (core->qd->treatment == QD_TREATMENT_LINK_FORBIDDEN) {
+dlv->disposition = PN_REJECTED;
+dlv->error = qdr_error("qd:forbidden", "Sending deliveries to this 
address is forbidden");
--- End diff --

You should be using one of the AMQP-specified error conditions that is in 
the amqp.[ch] files.  It seems that the appropriate error condition is 
"amqp:not-allowed", not "forbidden" (which is an error code only for the 
management protocol).


> refuse attach to undefined addresses
> 
>
> Key: DISPATCH-803
> URL: https://issues.apache.org/jira/browse/DISPATCH-803
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> At present, if you attach to an address in the router whose semantics have 
> not been specifically defined, you get balanced message routing semantics.
> It would be useful to be able to configure the router such that it would 
> refuse links whose source/target was not explicitly defined. E.g. by being 
> able to configure the default semantics to be of type 'invalid' (or anything 
> similar). (Being able to explicitly blacklist certain addresses might also be 
> nice, but is a more exotic use case I think).
> Messages sent through an anonymous link to these 'invalid' addresses would be 
> rejected.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (PROTON-1072) Proton build fails if epydoc is installed

2017-08-09 Thread Justin Ross (JIRA)

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

Justin Ross commented on PROTON-1072:
-

This doesn't reproduce for me, on F23 or F26.  [~ganeshmurthy], is this still 
an issue for you?

> Proton build fails if epydoc is installed
> -
>
> Key: PROTON-1072
> URL: https://issues.apache.org/jira/browse/PROTON-1072
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.11.0
>Reporter: Ganesh Murthy
>Assignee: Justin Ross
> Fix For: proton-c-0.18.0
>
>
> Steps to reproduce 
> Get the latest proton from master.
> Install epydoc on your system (dnf -y install epydoc  (I did this on Docker 
> using Fedora 23 environment))
> Now run the proton build
> You will see the following error - 
>  CMake Warning (dev) at proton-c/bindings/python/CMakeLists.txt:87 
> (add_custom_target):
>Syntax error in cmake code at
>  /main/qpid-proton/proton-c/bindings/python/CMakeLists.txt:91
>when parsing string
>  ${SWIG_MODULE_${cproton}_REAL_NAME
>syntax error, unexpected $end, expecting } (34)
>Policy CMP0010 is not set: Bad variable reference syntax is an error.  Run
>"cmake --help-policy CMP0010" for policy details.  Use the cmake_policy
>command to set the policy and suppress this warning.
>  This warning is for project developers.  Use -Wno-dev to suppress it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (DISPATCH-803) refuse attach to undefined addresses

2017-08-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on DISPATCH-803:
-

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

https://github.com/apache/qpid-dispatch/pull/185#discussion_r132275399
  
--- Diff: src/dispatch_private.h ---
@@ -52,6 +52,7 @@ struct qd_dispatch_t {
 qd_connection_manager_t *connection_manager;
 qd_policy_t *policy;
 void*dl_handle;
+qd_address_treatment_t   treatment;
--- End diff --

Changed treatment to default_treatment


> refuse attach to undefined addresses
> 
>
> Key: DISPATCH-803
> URL: https://issues.apache.org/jira/browse/DISPATCH-803
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> At present, if you attach to an address in the router whose semantics have 
> not been specifically defined, you get balanced message routing semantics.
> It would be useful to be able to configure the router such that it would 
> refuse links whose source/target was not explicitly defined. E.g. by being 
> able to configure the default semantics to be of type 'invalid' (or anything 
> similar). (Being able to explicitly blacklist certain addresses might also be 
> nice, but is a more exotic use case I think).
> Messages sent through an anonymous link to these 'invalid' addresses would be 
> rejected.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...

2017-08-09 Thread ganeshmurthy
Github user ganeshmurthy commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/185#discussion_r132275310
  
--- Diff: include/qpid/dispatch/router.h ---
@@ -42,7 +42,8 @@ typedef enum {
 QD_TREATMENT_MULTICAST_ONCE   = 1,
 QD_TREATMENT_ANYCAST_CLOSEST  = 2,
 QD_TREATMENT_ANYCAST_BALANCED = 3,
-QD_TREATMENT_LINK_BALANCED= 4
+QD_TREATMENT_LINK_BALANCED= 4,
+QD_TREATMENT_LINK_FORBIDDEN   = 5
--- End diff --

Changed QD_TREATMENT_LINK_FORBIDDEN to QD_TREATMENT_FORBIDDEN


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

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



[jira] [Resolved] (PROTON-785) pn_code is missing one error code

2017-08-09 Thread Justin Ross (JIRA)

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

Justin Ross resolved PROTON-785.

Resolution: Fixed

> pn_code is missing one error code
> -
>
> Key: PROTON-785
> URL: https://issues.apache.org/jira/browse/PROTON-785
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.7, 0.8
> Environment: Linux
>Reporter: Andreas Welchlin
>Assignee: Justin Ross
>Priority: Trivial
> Fix For: proton-c-0.18.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> In error.c there is one error code missing in function pn_code:
> const char *pn_code(int code)
> {
>   switch (code)
>   {
>   case 0: return "";
>   case PN_EOS: return "PN_EOS";
>   case PN_ERR: return "PN_ERR";
>   case PN_OVERFLOW: return "PN_OVERFLOW";
>   case PN_UNDERFLOW: return "PN_UNDERFLOW";
>   case PN_STATE_ERR: return "PN_STATE_ERR";
>   case PN_ARG_ERR: return "PN_ARG_ERR";
>   case PN_TIMEOUT: return "PN_TIMEOUT";
>   case PN_INTR: return "PN_INTR";
>   default: return "";
>   }
> }
> There should also be:
>   case PN_INPROGRESS: return "PN_INPROGRESS";



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Created] (QPIDJMS-312) Exception is not thrown when user attempts to create context with invalid session mode value

2017-08-09 Thread Jiri Danek (JIRA)
Jiri Danek created QPIDJMS-312:
--

 Summary: Exception is not thrown when user attempts to create 
context with invalid session mode value
 Key: QPIDJMS-312
 URL: https://issues.apache.org/jira/browse/QPIDJMS-312
 Project: Qpid JMS
  Issue Type: Bug
  Components: qpid-jms-client
Affects Versions: 0.23.0
Reporter: Jiri Danek
Priority: Trivial


Consider Apache ActiveMQ Artemis tests 
{{org.apache.activemq.artemis.tests.integration.jms.jms2client.JmsContextTest#testInvalidSessionModesValueMinusOne}}
 and {{#testInvalidSessionModesValue4}} (in the same class).

When it is adapted to run with multiple JMS clients, or when run from the 
standalone reproducer at 
https://github.com/jdanekrh/jms-reproducers/blob/master/src/test/java/org/apache/activemq/artemis/tests/integration/jms/jms2client/JmsContextTest.java
(the standalone reproducer requires a running broker to connect to), the test 
passes with Core, is skipped on OpenWire (because that is not a JMS 2.0 client) 
and fails on AMQP protocol (with qpid-jms-client as the JMS library):

{noformat}
   @Test(expected = JMSRuntimeException.class)
   public void testInvalidSessionModesValueMinusOne() {
  context.createContext(-1);
   }

   @Test(expected = JMSRuntimeException.class)
   public void testInvalidSessionModesValue4() {
  context.createContext(4);
   }
{noformat}

with exception

{noformat}
java.lang.AssertionError: Expected exception: javax.jms.JMSRuntimeException
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Updated] (QPID-7879) [Java Broker] Keystore improvements

2017-08-09 Thread Keith Wall (JIRA)

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

Keith Wall updated QPID-7879:
-
Fix Version/s: Future

> [Java Broker] Keystore improvements
> ---
>
> Key: QPID-7879
> URL: https://issues.apache.org/jira/browse/QPID-7879
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: Future
>
>
> The keystore model and UI should expose subject alternative names (SANs) to 
> help operators trying to diagnose TLS certificate problems. 
> Also for the FileTrustStore the model does not make it clear which of the 
> certificates contained within will be used to identify the TLS server (you 
> just have to know that it is the certificate identified by the alias, or the 
> first certificate in the store).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



Re: proton server (azure SB) limit the incoming_window=5000

2017-08-09 Thread Pankaj Bhagra
Thanks Gordon for looking into my query. It makes sense what u said,
however i am still searching for a reason of flow control and limited batch
size.

As per your suggestion i tried increasing the link-credit to 10k, 100k, but
that doesn't change much. my understanding of prefetch was that its number
of packets not the number of bytes (i confirmed this by reducing the
prefetch to 2 and then i see only 1 pkt per bulk message (half of the
window size)).

The size of the each pkt is roughly 900B, and as u can see that i am not
able to read more than 12 pkts per batch in the complete logs below. So
looking back yes the size of 12x900B is greater than 5KB, so the heading
may need correction - it looks like 2x of that which is 10kb.

would appreciate if someone can suggest some more knobs i should play to
figure out where this limit of 10kb is coming from ? client advertised
incoming_window is incoming-window=2147483647 <(214)%20748-3647>

see the complete logs, as u can see the bulk size is limited to 12 pkts,
where the link credit remains at , after every bulk.


[0xb58380]:  -> SASL

[0xb58380]:  <- SASL

[0xb58380]:0 <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:MSSBCBS, :PLAIN, :ANONYMOUS, :EXTERNAL]]

[0xb58380]:0 -> @sasl-init(65) [mechanism=:PLAIN,
initial-response=b"\x0"]

[0xb58380]:0 <- @sasl-outcome(68) [code=0, additional-data=b"Welcome!"]

[0xb58380]:  -> AMQP

[0xb58380]:0 -> @open(16)
[container-id="bc599ddc-74df-46b0-800c-401aed27f321", hostname="
nebhubsb.servicebus.windows.net", channel-max=32767]

[0xb58380]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=2147483647]

[0xb58380]:0 -> @attach(18)
[name="bc599ddc-74df-46b0-800c-401aed27f321-kukatopic/Subscriptions/kukasub",
handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [address="kukatopic/Subscriptions/kukasub", durable=0,
timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0,
dynamic=false], initial-delivery-count=0, max-message-size=0]

[0xb58380]:0 -> @flow(19) [incoming-window=2147483647, next-outgoing-id=0,
outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=1,
drain=false]

[0xb58380]:  <- AMQP

[0xb58380]:0 <- @open(16)
[container-id="fa8f5d5577be485ebd7f5ebdbdfd9ca1_G13", max-frame-size=65536,
channel-max=4999, idle-time-out=24]

[0xb58380]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1,
incoming-window=5000, outgoing-window=2147483647, handle-max=255]

[0xb58380]:0 <- @attach(18)
[name="bc599ddc-74df-46b0-800c-401aed27f321-kukatopic/Subscriptions/kukasub",
handle=0, role=false, rcv-settle-mode=1, source=@source(40)
[address="kukatopic/Subscriptions/kukasub", durable=0, timeout=0,
dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false],
initial-delivery-count=0, max-message-size=266240]

[0xb58380]:0 <- @transfer(20) [handle=0, delivery-id=0,
delivery-tag=b"\x06\xa8\xb3\xf9\x94\x1b\x09H\xa0\xc7\xf2\x11\xd7I\xa9\x12",
message-format=0, more=false, batchable=true] (1250) "\x00Sp\xc0\x0b\x05@
@p\x05&\\x00@R\x02\x00Sq\xc1\x01\x00\x00Sr\xc1\\x06\xa3\x13x-opt-enqueued-time\x83\x00\x00\x01]\xc0\x92\xc7\x0a\xa3\x15x-opt-sequence-number\x81\x00\x00\x00\x00\x009\xc9\x15\xa3\x12x-opt-locked-until\x83\x00\x00\x01]\xc5\xb4\xa5)\x00St\xc1\xef\x06\xa1\x1biothub-connection-device-id\xa1)S-1-5-21-1936340646-3222415949-3237289474\xa1\x1diothub-connection-auth-method\xa1K{"scope":"hub","type":"sas","issuer":"iothub","acceptingIpFilterRule":null}\xa1$iothub-connection-auth-generation-id\xa1\x12636327363635593852\x00Su\xb0\x00\x00\x03o{"AssetId":
{"type": "KR C", "eid": "S-1-5-21-1936340646-3222415949-3237289474"},
"AssetUpdateHdr": {"timestamp": "2017-08-08T06:40:29.4663961Z",
"iteration": 467375, "update_type": "AssetAttributes"}, "parentId":
"88eeb6e55ae548de97576e16d5289050", "AssetMonitoredItems": {"AXIS_ACT":
{"A1": {"units": "Double", "value": 7.35237932}, "A3": {"units": "Double",
"value": 97.599472}, "A2": {"units": "Double", "value": -88.2291565}, "A5":
{"units": "Double", "value": 80"... (truncated)

[0xb58380]:0 <- @transfer(20) [handle=0, delivery-id=1,
delivery-tag=b"P\xb1\x94N9\x18\x0bD\xb6\x00[cr#\x1d\xab", message-format=0,
more=false, batchable=true] (1245)
"\x00Sp\xc0\x0b\x05@@p\x05&\\x00@R\x02\x00Sq\xc1\x01\x00\x00Sr\xc1\\x06\xa3\x13x-opt-enqueued-time\x83\x00\x00\x01]\xc0\x92\xcb\x04\xa3\x15x-opt-sequence-number\x81\x00\x00\x00\x00\x009\xc9\x16\xa3\x12x-opt-locked-until\x83\x00\x00\x01]\xc5\xb4\xa5)\x00St\xc1\xef\x06\xa1\x1biothub-connection-device-id\xa1)S-1-5-21-1936340646-3222415949-3237289474\xa1\x1diothub-connection-auth-method\xa1K{"scope":"hub","type":"sas","issuer":"iothub","acceptingIpFilterRule":null}\xa1$iothub-connection-auth-generation-id\xa1\x12636327363635593852\x00Su\xb0\x00\x00\x03j{"AssetId":
{"type": "KR C", "eid": "S-1-5-21-1936340646-3222415949-3237289474"},
"AssetUpdateHdr": {"timestamp": "2017-08-08T06:40:30.4976526Z",
"iteration": 467376, "update_type": 

[jira] [Commented] (QPID-7881) [Java Broker] [WMC] Expose broker restart operation through Management Console.

2017-08-09 Thread ASF subversion and git services (JIRA)

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

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

Commit 67aa48fd5069778c3dff86443eda47d75e852974 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=67aa48f ]

QPID-7881: [Java Broker] [WMC] Expose broker restart operation


> [Java Broker] [WMC] Expose broker restart operation through Management 
> Console.
> ---
>
> Key: QPID-7881
> URL: https://issues.apache.org/jira/browse/QPID-7881
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Give the user's of the web management console convenient access to the 
> restart broker operation already exposed by the REST API.  This is useful as 
> some configuration changes require a restart to be applied.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Updated] (QPID-7881) [Java Broker] [WMC] Expose broker restart operation through Management Console.

2017-08-09 Thread Keith Wall (JIRA)

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

Keith Wall updated QPID-7881:
-
Description: 
Give the user of the web management console convenient access to the restart 
broker operation (already exposed by the REST API).  This is useful as some 
configuration changes require a restart to be applied.



  was:
Give the user's of the web management console convenient access to the restart 
broker operation already exposed by the REST API.  This is useful as some 
configuration changes require a restart to be applied.




> [Java Broker] [WMC] Expose broker restart operation through Management 
> Console.
> ---
>
> Key: QPID-7881
> URL: https://issues.apache.org/jira/browse/QPID-7881
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Give the user of the web management console convenient access to the restart 
> broker operation (already exposed by the REST API).  This is useful as some 
> configuration changes require a restart to be applied.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (QPID-7867) Authentication using expired certificate

2017-08-09 Thread Keith Wall (JIRA)

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

Keith Wall commented on QPID-7867:
--


I found the following resources useful when working on the IBM JDK test 
failures (addressed by efb35e5). 

https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/knowndiffsun.html
https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/debug.html

With regard to the change made to {{TrustAnchorValidatingTrustManager.java}} by 
efb35e5, I was unable to find an authoritative source that states that the peer 
certificate must appear in the store passed to {{PKIXBuilderParameters}} but I 
was able to find a number of examples of this usage style online (some with 
comments regarding working around IBM JDK 'issues').  "Beginning Cryptography 
with Java", Hook, 2005 also illustrates the same pattern.



> Authentication using expired certificate
> 
>
> Key: QPID-7867
> URL: https://issues.apache.org/jira/browse/QPID-7867
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
> Environment: * qpid-jms-client version 0.23.0
> * java qpid broker 7.0.0
>Reporter: Martin Krasa
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Using qpid-jms-client version 0.23.0 and (as of July 17 2017) expired 
> self-signed certificate (Valid until: Sat Dec 17 10:46:56 CET 2016) user can 
> _successfully authenticate_ against the java qpid broker 7.0.0 
> {code:title=extract from Java broker log file|borderStyle=solid} 2017-07-14 
> 16:34:58,022 INFO [Broker-Config] (q.m.c.open) - [con:0(/XXX.XX.XX.XX:54268)] 
> CON-1001 : Open : Destination : amqps(XXX.XX.XX.XXX:10202) : Protocol Version 
> : 1.0 : SSL 2017-07-14 16:34:58,093 INFO [IO-/172.23.38.21:54268] 
> (q.m.c.open) - [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)] CON-1001 : 
> Open : Destination : amqps(XXX.XX.XX.XXX:10202) : Protocol Version : 1.0 : 
> SSL : Client ID : ID:6303ba8b-2055-49e5-9bf8-80336865a672:1 : Client Version 
> : 0.23.0 : Client Product : QpidJMS 2017-07-14 16:34:58,124 INFO 
> [IO-/XXX.XX.XX.XX:54268] (q.m.c.create) - 
> [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)/ch:0] CHN-1001 : Create 
> 2017-07-14 16:34:58,155 INFO [IO-/XXX.XX.XX.XX:54268] (q.m.c.create) - 
> [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)/ch:1] CHN-1001 : Create 
> {code} {color:blue}*NOTE:* The same behaviour rings true with expired node 
> certificate{color}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Updated] (QPID-6960) BDB HA limits message size to je.rep.maxMessageSize (which was inadvertently lowered in qpid-java-6.0)

2017-08-09 Thread Keith Wall (JIRA)

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

Keith Wall updated QPID-6960:
-
Fix Version/s: Future

> BDB HA limits message size to je.rep.maxMessageSize (which was inadvertently 
> lowered in qpid-java-6.0)
> --
>
> Key: QPID-6960
> URL: https://issues.apache.org/jira/browse/QPID-6960
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0
>Reporter: Keith Wall
> Fix For: Future
>
>
> If I create a Java Broker BDB HA group and publish a message whose payload + 
> overhead exceeds  {{je.rep.maxMessageSize}}, the replicas log the following 
> exception.  On qpid-java-v6.0, the replica doesn't fail but instead slowly 
> spins, seemingly continually retrying repeating the same log message.
> {{je.rep.maxMessageSize}} is not overridden by Qpid, so it takes its default 
> value 0.  0 is interpreted by JE to mean {{je.maxMemory /2}}.  QPID-6751 
> reduced the size of {{je.maxMemory}} from 5% of JVM's heap to 2%.  This means 
> that in qpid-java-v6.0, the default maximum message size will be 2% of 
> default JVM heap size (0.5GB) = 10MB.   For comparison, in 0.32 with default 
> heap of 2GB gave a maximum message size of 50MB.
> Users can work around this issue by raising {{je.rep.maxMessageSize}}.  This 
> can be done from the Java Broker command line (-prop), or from QPID_OPTS 
> environment variable.
> {noformat}
>  com.sleepycat.je.EnvironmentFailureException: (JE 5.0.104) Message op: Entry 
> Body size: 32557779 is too large.  maxSizeAllowed: 21126184
> If a larger value is needed, set the 'je.rep.maxMessageSize' parameter. 
> UNEXPECTED_STATE: Unexpected internal state, may have side effects.
> at 
> com.sleepycat.je.EnvironmentFailureException.unexpectedState(EnvironmentFailureException.java:426)
> at 
> com.sleepycat.je.rep.utilint.BinaryProtocol.read(BinaryProtocol.java:469)
> at 
> com.sleepycat.je.rep.impl.node.Replica.doRunReplicaLoopInternalWork(Replica.java:466)
> at 
> com.sleepycat.je.rep.impl.node.Replica.runReplicaLoopInternal(Replica.java:397)
> at 
> com.sleepycat.je.rep.impl.node.Replica.runReplicaLoop(Replica.java:332)
> at 
> com.sleepycat.je.rep.impl.node.RepNode.run(RepNode.java:1506)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Created] (QPID-7881) [Java Broker] [WMC] Expose broker restart operation through Management Console.

2017-08-09 Thread Keith Wall (JIRA)
Keith Wall created QPID-7881:


 Summary: [Java Broker] [WMC] Expose broker restart operation 
through Management Console.
 Key: QPID-7881
 URL: https://issues.apache.org/jira/browse/QPID-7881
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Keith Wall
Priority: Minor
 Fix For: qpid-java-broker-7.0.0


Give the user's of the web management console convenient access to the restart 
broker operation already exposed by the REST API.  This is useful as some 
configuration changes require a restart to be applied.





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Updated] (QPID-7882) SSL related tests fail on IBM JDK profile when run with Qpid JMS Client

2017-08-09 Thread Keith Wall (JIRA)

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

Keith Wall updated QPID-7882:
-
Component/s: Java Broker

> SSL related tests fail on IBM JDK profile when run with Qpid JMS Client
> ---
>
> Key: QPID-7882
> URL: https://issues.apache.org/jira/browse/QPID-7882
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: Future
>
>
> Running with the command:
> {code}
> mvn clean  verify -DfailIfNoTests=false 
> -DXmaven.surefire.debug="-Dcom.ibm.jsse2.overrideDefaultTLS=true" -P 
> java-mms.1-0 -DenableAmqp1-0 
> "-Dprofile.specific.excludes=JavaTransientExcludes Java10BrokenTestsExcludes 
> Java10Excludes Java10UninvestigatedTestsExcludes IBMJDKExcludes"
> {code}
> I see the following failures:
> Failed tests:
>   
> SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testClientCertMissingWhilstWanting:468->missingClientCertWhileNeedingOrWantingTestImpl:529
>  Connection failed, unexpected exception thrown
>   
> ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerOnSSLPort:88
>  Should be able to create a connection to the SSL port: Received fatal alert: 
> handshake_failure
>   
> ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerUsernameAsCN:306
>  Should be able to create a connection to the SSL port: Received fatal alert: 
> handshake_failure
>   
> ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerUsernameAsDN:350
>  Should be able to create a connection to the SSL port: Received fatal alert: 
> handshake_failure
>   
> ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationWithPeersOnlyTrustStore:201->externalAuthenticationWithPeersOnlyTrustStoreTestImpl:256
>  Client's validation against the broker's multi store manager unexpectedly 
> failed, when configured store was expected to allow.
>   
> ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationWithRegularAndPeersOnlyTrustStores:210->externalAuthenticationWithPeersOnlyTrustStoreTestImpl:256
>  Client's validation against the broker's multi store manager unexpectedly 
> failed, when configured store was expected to allow.
> Tests in error:
>   
> SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLConnectionUsingConnectionURLParams:107->QpidBrokerTestCase.getConnectionWithOptions:281
>  » JMS
>   
> SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLConnectionUsingConnectionURLParamsTrustStoreOnly:433->QpidBrokerTestCase.getConnectionWithOptions:281
>  » JMS
>   
> SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLandTCPonSamePort:563->QpidBrokerTestCase.getConnectionWithOptions:281
>  » JMS
>   
> AmqpManagementTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testInvokeSecureOperation:658
>  » JMS



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Created] (QPID-7882) SSL related tests fail on IBM JDK profile when run with Qpid JMS Client

2017-08-09 Thread Keith Wall (JIRA)
Keith Wall created QPID-7882:


 Summary: SSL related tests fail on IBM JDK profile when run with 
Qpid JMS Client
 Key: QPID-7882
 URL: https://issues.apache.org/jira/browse/QPID-7882
 Project: Qpid
  Issue Type: Bug
Reporter: Keith Wall
 Fix For: Future


Running with the command:

{code}
mvn clean  verify -DfailIfNoTests=false 
-DXmaven.surefire.debug="-Dcom.ibm.jsse2.overrideDefaultTLS=true" -P 
java-mms.1-0 -DenableAmqp1-0 "-Dprofile.specific.excludes=JavaTransientExcludes 
Java10BrokenTestsExcludes Java10Excludes Java10UninvestigatedTestsExcludes 
IBMJDKExcludes"
{code}

I see the following failures:

Failed tests:
  
SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testClientCertMissingWhilstWanting:468->missingClientCertWhileNeedingOrWantingTestImpl:529
 Connection failed, unexpected exception thrown
  
ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerOnSSLPort:88
 Should be able to create a connection to the SSL port: Received fatal alert: 
handshake_failure
  
ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerUsernameAsCN:306
 Should be able to create a connection to the SSL port: Received fatal alert: 
handshake_failure
  
ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerUsernameAsDN:350
 Should be able to create a connection to the SSL port: Received fatal alert: 
handshake_failure
  
ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationWithPeersOnlyTrustStore:201->externalAuthenticationWithPeersOnlyTrustStoreTestImpl:256
 Client's validation against the broker's multi store manager unexpectedly 
failed, when configured store was expected to allow.
  
ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationWithRegularAndPeersOnlyTrustStores:210->externalAuthenticationWithPeersOnlyTrustStoreTestImpl:256
 Client's validation against the broker's multi store manager unexpectedly 
failed, when configured store was expected to allow.
Tests in error:
  
SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLConnectionUsingConnectionURLParams:107->QpidBrokerTestCase.getConnectionWithOptions:281
 » JMS
  
SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLConnectionUsingConnectionURLParamsTrustStoreOnly:433->QpidBrokerTestCase.getConnectionWithOptions:281
 » JMS
  
SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLandTCPonSamePort:563->QpidBrokerTestCase.getConnectionWithOptions:281
 » JMS
  
AmqpManagementTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testInvokeSecureOperation:658
 » JMS



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (QPID-7882) SSL related tests fail on IBM JDK profile when run with Qpid JMS Client

2017-08-09 Thread Keith Wall (JIRA)

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

Keith Wall commented on QPID-7882:
--

Invalid. I had failed to set -Dcom.ibm.jsse2.overrideDefaultTLS=true to make 
all TLS protocols available (I had left an X in my mvn command line).

> SSL related tests fail on IBM JDK profile when run with Qpid JMS Client
> ---
>
> Key: QPID-7882
> URL: https://issues.apache.org/jira/browse/QPID-7882
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: Future
>
>
> Running with the command:
> {code}
> mvn clean  verify -DfailIfNoTests=false 
> -DXmaven.surefire.debug="-Dcom.ibm.jsse2.overrideDefaultTLS=true" -P 
> java-mms.1-0 -DenableAmqp1-0 
> "-Dprofile.specific.excludes=JavaTransientExcludes Java10BrokenTestsExcludes 
> Java10Excludes Java10UninvestigatedTestsExcludes IBMJDKExcludes"
> {code}
> I see the following failures:
> Failed tests:
>   
> SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testClientCertMissingWhilstWanting:468->missingClientCertWhileNeedingOrWantingTestImpl:529
>  Connection failed, unexpected exception thrown
>   
> ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerOnSSLPort:88
>  Should be able to create a connection to the SSL port: Received fatal alert: 
> handshake_failure
>   
> ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerUsernameAsCN:306
>  Should be able to create a connection to the SSL port: Received fatal alert: 
> handshake_failure
>   
> ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerUsernameAsDN:350
>  Should be able to create a connection to the SSL port: Received fatal alert: 
> handshake_failure
>   
> ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationWithPeersOnlyTrustStore:201->externalAuthenticationWithPeersOnlyTrustStoreTestImpl:256
>  Client's validation against the broker's multi store manager unexpectedly 
> failed, when configured store was expected to allow.
>   
> ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationWithRegularAndPeersOnlyTrustStores:210->externalAuthenticationWithPeersOnlyTrustStoreTestImpl:256
>  Client's validation against the broker's multi store manager unexpectedly 
> failed, when configured store was expected to allow.
> Tests in error:
>   
> SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLConnectionUsingConnectionURLParams:107->QpidBrokerTestCase.getConnectionWithOptions:281
>  » JMS
>   
> SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLConnectionUsingConnectionURLParamsTrustStoreOnly:433->QpidBrokerTestCase.getConnectionWithOptions:281
>  » JMS
>   
> SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLandTCPonSamePort:563->QpidBrokerTestCase.getConnectionWithOptions:281
>  » JMS
>   
> AmqpManagementTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testInvokeSecureOperation:658
>  » JMS



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[ANNOUNCE] Apache Qpid JMS 0.24.0 released

2017-08-09 Thread Robbie Gemmell
The Apache Qpid (http://qpid.apache.org) community is pleased to
announce the immediate availability of Apache Qpid JMS 0.24.0.

This is the latest release of our newer JMS client supporting the
Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464,
http://www.amqp.org), based around the Apache Qpid Proton protocol
engine and implementing the AMQP JMS Mapping as it evolves at OASIS.

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-jms-0.24.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] [Closed] (QPID-7882) SSL related tests fail on IBM JDK profile when run with Qpid JMS Client

2017-08-09 Thread Keith Wall (JIRA)

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

Keith Wall closed QPID-7882.

Resolution: Invalid

> SSL related tests fail on IBM JDK profile when run with Qpid JMS Client
> ---
>
> Key: QPID-7882
> URL: https://issues.apache.org/jira/browse/QPID-7882
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: Future
>
>
> Running with the command:
> {code}
> mvn clean  verify -DfailIfNoTests=false 
> -DXmaven.surefire.debug="-Dcom.ibm.jsse2.overrideDefaultTLS=true" -P 
> java-mms.1-0 -DenableAmqp1-0 
> "-Dprofile.specific.excludes=JavaTransientExcludes Java10BrokenTestsExcludes 
> Java10Excludes Java10UninvestigatedTestsExcludes IBMJDKExcludes"
> {code}
> I see the following failures:
> Failed tests:
>   
> SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testClientCertMissingWhilstWanting:468->missingClientCertWhileNeedingOrWantingTestImpl:529
>  Connection failed, unexpected exception thrown
>   
> ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerOnSSLPort:88
>  Should be able to create a connection to the SSL port: Received fatal alert: 
> handshake_failure
>   
> ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerUsernameAsCN:306
>  Should be able to create a connection to the SSL port: Received fatal alert: 
> handshake_failure
>   
> ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerUsernameAsDN:350
>  Should be able to create a connection to the SSL port: Received fatal alert: 
> handshake_failure
>   
> ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationWithPeersOnlyTrustStore:201->externalAuthenticationWithPeersOnlyTrustStoreTestImpl:256
>  Client's validation against the broker's multi store manager unexpectedly 
> failed, when configured store was expected to allow.
>   
> ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationWithRegularAndPeersOnlyTrustStores:210->externalAuthenticationWithPeersOnlyTrustStoreTestImpl:256
>  Client's validation against the broker's multi store manager unexpectedly 
> failed, when configured store was expected to allow.
> Tests in error:
>   
> SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLConnectionUsingConnectionURLParams:107->QpidBrokerTestCase.getConnectionWithOptions:281
>  » JMS
>   
> SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLConnectionUsingConnectionURLParamsTrustStoreOnly:433->QpidBrokerTestCase.getConnectionWithOptions:281
>  » JMS
>   
> SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLandTCPonSamePort:563->QpidBrokerTestCase.getConnectionWithOptions:281
>  » JMS
>   
> AmqpManagementTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testInvokeSecureOperation:658
>  » JMS



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Resolved] (QPID-7878) [Java Broker] [Windows start batch file] Add command line option to pause if start-up fails.

2017-08-09 Thread Alex Rudyy (JIRA)

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

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

The changes look reasonable to me

> [Java Broker] [Windows start batch file] Add command line option to pause if 
> start-up fails.
> 
>
> Key: QPID-7878
> URL: https://issues.apache.org/jira/browse/QPID-7878
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Trivial
>
> The {{qpid-server.bat}} batch file may be called from the Windows start menu 
> or Windows short-cut.  If the Broker fails to start (unset JAVA_HOME or wrong 
> JVM version), currently the command window associated with the batch file 
> closes before the contents of the window can be read.  This frustrates users 
> trying to diagnose problems.
> An option 'run' command line option could be added to instruct the batch 
> script pause if the java or the broker report a non-zero exit status.   The 
> run command line option is a private concern the the batch file and not 
> passed to Qpid proper.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



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

2017-08-09 Thread Justin Ross (JIRA)

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

Justin Ross reassigned PROTON-1477:
---

Assignee: Justin Ross

> Problem building qpid-proton 0.17.0 in Fedora rawhide
> -
>
> Key: PROTON-1477
> URL: https://issues.apache.org/jira/browse/PROTON-1477
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: build
> Environment: x86_64
>Reporter: Irina Boverman
>Assignee: Justin Ross
>
> [ 39%] Swig source
> cd /builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl && 
> /usr/bin/cmake -E make_directory 
> /builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl
> make[2]: Leaving directory '/builddir/build/BUILD/qpid-proton-0.17.0'
> cd /builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl && 
> /usr/bin/swig -perl -outdir 
> /builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl -shadow 
> -I/builddir/build/BUILD/qpid-proton-0.17.0/proton-c/src 
> -I/builddir/build/BUILD/qpid-proton-0.17.0/proton-c/include -I/usr/include 
> -I/usr/lib64/perl5/CORE -o 
> /builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl/perlPERL_wrap.c
>  /builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl/perl.i
> make[2]: Leaving directory '/builddir/build/BUILD/qpid-proton-0.17.0'
> cc1plus: error: -Wformat-security ignored without -Wformat 
> [-Werror=format-security]
> cc1plus: all warnings being treated as errors
> make[2]: *** 
> [proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/build.make:66: 
> proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/src/binary.cpp.o] Error 1



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Created] (PROTON-1533) Swig deprecation warnings with recent versions of cmake

2017-08-09 Thread Justin Ross (JIRA)
Justin Ross created PROTON-1533:
---

 Summary: Swig deprecation warnings with recent versions of cmake
 Key: PROTON-1533
 URL: https://issues.apache.org/jira/browse/PROTON-1533
 Project: Qpid Proton
  Issue Type: Bug
  Components: build
 Environment: Fedora 25, 26
Cmake 3.8+
Reporter: Justin Ross
Assignee: Justin Ross
Priority: Minor
 Fix For: proton-c-0.18.0


Same output as described in https://issues.apache.org/jira/browse/QPID-7860




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (PROTON-1533) Swig deprecation warnings with recent versions of cmake

2017-08-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on PROTON-1533:


GitHub user ssorj opened a pull request:

https://github.com/apache/qpid-proton/pull/115

PROTON-1533: Fix swig deprecation warnings

For review

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

$ git pull https://github.com/ssorj/qpid-proton master

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

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


commit 7fa4bf7be0f7e5cf6e43683a3294675df908f46c
Author: Justin Ross 
Date:   2017-08-08T23:49:31Z

Use swig_add_library instead of the now deprecated swig_add_module; provide 
a fallback impl

commit 5c2b1529e610171172565eb802cec8102a9e48be
Author: Justin Ross 
Date:   2017-08-09T00:07:42Z

Correct a cmake test expression

commit 04c07670a445ceb7188a56070c5141e8bded56a0
Author: Justin Ross 
Date:   2017-08-09T12:02:24Z

Remove extraneous macro definition




> Swig deprecation warnings with recent versions of cmake
> ---
>
> Key: PROTON-1533
> URL: https://issues.apache.org/jira/browse/PROTON-1533
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: build
> Environment: Fedora 25, 26
> Cmake 3.8+
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Minor
> Fix For: proton-c-0.18.0
>
>
> Same output as described in https://issues.apache.org/jira/browse/QPID-7860



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[GitHub] qpid-proton pull request #115: PROTON-1533: Fix swig deprecation warnings

2017-08-09 Thread ssorj
GitHub user ssorj opened a pull request:

https://github.com/apache/qpid-proton/pull/115

PROTON-1533: Fix swig deprecation warnings

For review

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

$ git pull https://github.com/ssorj/qpid-proton master

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

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


commit 7fa4bf7be0f7e5cf6e43683a3294675df908f46c
Author: Justin Ross 
Date:   2017-08-08T23:49:31Z

Use swig_add_library instead of the now deprecated swig_add_module; provide 
a fallback impl

commit 5c2b1529e610171172565eb802cec8102a9e48be
Author: Justin Ross 
Date:   2017-08-09T00:07:42Z

Correct a cmake test expression

commit 04c07670a445ceb7188a56070c5141e8bded56a0
Author: Justin Ross 
Date:   2017-08-09T12:02:24Z

Remove extraneous macro definition




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

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



[jira] [Created] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class

2017-08-09 Thread Jiri Danek (JIRA)
Jiri Danek created QPIDJMS-313:
--

 Summary: Message#getBody does not throw when attempting to read a 
BytesMessage as String.class
 Key: QPIDJMS-313
 URL: https://issues.apache.org/jira/browse/QPIDJMS-313
 Project: Qpid JMS
  Issue Type: Bug
  Components: qpid-jms-client
Affects Versions: 0.23.0
Reporter: Jiri Danek
Priority: Minor


Consider the ActiveMQ Artemis test 
{{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
 adapted to run through multiple JMS ConnectionFactories in turn. This test 
passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.

{noformat}
 BytesMessage bytesMessage = sess.createBytesMessage();
 producer.send(bytesMessage);

 Message msg = cons.receiveNoWait();
 assertNotNull(msg);

 try {
msg.getBody(String.class);
fail("Exception expected");
 } catch (MessageFormatException e) {
 }
{noformat}

The failing line is the {{fail("Exception expected");}}, because qpid-jms does 
not throw {{MessageFormatException}} where it is supposed to.

According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If 
the message is a BytesMessage then this parameter must be set to byte[].class 
(or java.lang.Object.class). This method will reset the BytesMessage before and 
after use." ... "Throws: MessageFormatException" ... "if the message body 
cannot be assigned to the specified type."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Created] (QPID-7883) Python client should not raise exception on close() after stop.

2017-08-09 Thread Alan Conway (JIRA)
Alan Conway created QPID-7883:
-

 Summary: Python client should not raise exception on close() after 
stop.
 Key: QPID-7883
 URL: https://issues.apache.org/jira/browse/QPID-7883
 Project: Qpid
  Issue Type: Bug
  Components: Python Client
Affects Versions: qpid-python-1.36.0
Reporter: Alan Conway
Assignee: Alan Conway
 Fix For: qpid-python-1.37.0


The python client throws exceptions out of AMQP object methods (Connection, 
Session and Link objects) if the selector has been stopped, to prevent hanging 
(see QPID-7317 Deadlock on publish)

However to be robust to shut-down order, the close() method should *not* throw 
an exception in this case, but should be a no-op.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (PROTON-622) Add missing error check to pn_event_inspect

2017-08-09 Thread Justin Ross (JIRA)

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

Justin Ross commented on PROTON-622:


This code was refactored at some point, and it now includes the error check.

https://github.com/apache/qpid-proton/blob/master/proton-c/src/core/event.c#L257

> Add missing error check to pn_event_inspect
> ---
>
> Key: PROTON-622
> URL: https://issues.apache.org/jira/browse/PROTON-622
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Reporter: Bozo Dragojevic
>Assignee: Justin Ross
>Priority: Trivial
>  Labels: patch
> Fix For: proton-c-0.18.0
>
> Attachments: 
> 0002-PROTON-622-Add-missing-error-check-to-pn_event_inspe.patch
>
>
> Found by XCode Analyze



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...

2017-08-09 Thread grs
Github user grs commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/185#discussion_r132281323
  
--- Diff: src/router_core/transfer.c ---
@@ -634,6 +634,23 @@ static void qdr_link_forward_CT(qdr_core_t *core, 
qdr_link_t *link, qdr_delivery
 addr->deliveries_ingress++;
 link->total_deliveries++;
 }
+//
+// There is no address that we can send this delivery to, which means 
the addr was not found in our hastable. This
+// can be because there were no receivers or because the address was 
not defined in the config file.
+// If the treatment for such addresses is set to be forbidden, we send 
back a rejected disposition and detach the link
+//
+else if (core->qd->treatment == QD_TREATMENT_LINK_FORBIDDEN) {
+dlv->disposition = PN_REJECTED;
+dlv->error = qdr_error("qd:forbidden", "Sending deliveries to this 
address is forbidden");
--- End diff --

Or perhaps even better would be amqp:not-found, since we are really saying 
that this is not a recognised address?


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

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



[jira] [Commented] (DISPATCH-803) refuse attach to undefined addresses

2017-08-09 Thread Gordon Sim (JIRA)

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

Gordon Sim commented on DISPATCH-803:
-

[~aconway]:
> The original requirement is to prevent auto-creation of addresses. This 
> proposal sounds like the router will auto-create forbidden addresses which is 
> quite different

I think the requirement is simply that clients get some visible error signaled 
when trying to use an address for which no semantics have been configured. At 
present this is handled by treating such addresses as balanced. I don't 
personally view this as auto-creating the addresses, just as a way of inferring 
the semantics if none have been explicitly configured.

I'm not sure how your suggested config works. Are the two option - autoLink & 
autoCreateDistribution -scoped to the router? or a given address? For the 
latter, I don't think that helps with the original requirement, unless you come 
up with some special prefix that matches anything for which there is no more 
specific match. For thr former, I don't understand what autLink would do. In 
the former, the autoCreateDistribution is effectively just a different name for 
defaultDistribution, and personally I find defaultDistribution a bit more 
obvious.

> refuse attach to undefined addresses
> 
>
> Key: DISPATCH-803
> URL: https://issues.apache.org/jira/browse/DISPATCH-803
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> At present, if you attach to an address in the router whose semantics have 
> not been specifically defined, you get balanced message routing semantics.
> It would be useful to be able to configure the router such that it would 
> refuse links whose source/target was not explicitly defined. E.g. by being 
> able to configure the default semantics to be of type 'invalid' (or anything 
> similar). (Being able to explicitly blacklist certain addresses might also be 
> nice, but is a more exotic use case I think).
> Messages sent through an anonymous link to these 'invalid' addresses would be 
> rejected.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (QPID-7317) Deadlock on publish

2017-08-09 Thread ASF subversion and git services (JIRA)

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

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

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

QUID-7884: Python client should not raise on close() after stop.

The python client throws exceptions out of AMQP object methods (Connection, 
Session and Link objects) if the selector has been stopped, to prevent hanging 
(see QPID-7317 Deadlock on publish)

However to be robust to shut-down order, the close() method should not throw an 
exception in this case, but should be a no-op.


> Deadlock on publish
> ---
>
> Key: QPID-7317
> URL: https://issues.apache.org/jira/browse/QPID-7317
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Affects Versions: 0.32
> Environment: python-qpid-0.32-13.fc23.noarch
>Reporter: Brian Bouterse
>Assignee: Alan Conway
> Fix For: qpid-python-1.36.0
>
> Attachments: bad_child.py, bad_child.py, bt.txt, lsof.txt, 
> pystack.17806, spout-hang.py, spout-hang-trace.txt, taabt.txt, worker-stacks
>
>
> When publishing a task with qpid.messaging it deadlocks and our application 
> cannot continue. This has not been a problem for several releases, but within 
> a few days recently, another Satellite developer and I both experienced the 
> issue on separate machines, different distros. He is using a MRG built 
> pacakge (not sure of version). I am using python-qpid-0.32-13.fc23.
> Both deadlocked machines had core dumps taken on the deadlocked processes and 
> only show only 1 Qpid thread when I expect there to be 2. There are other 
> mongo threads, but those are idle as expected and not related. The traces 
> show our application calling into qpid.messaging to publish a message to the 
> message bus.
> This problem happens intermittently, and in cases where message publish is 
> successful I've verified by core dump that there are the expected 2 threads 
> for Qpid.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Closed] (PROTON-622) Add missing error check to pn_event_inspect

2017-08-09 Thread Justin Ross (JIRA)

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

Justin Ross closed PROTON-622.
--
Resolution: Not A Problem

> Add missing error check to pn_event_inspect
> ---
>
> Key: PROTON-622
> URL: https://issues.apache.org/jira/browse/PROTON-622
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Reporter: Bozo Dragojevic
>Assignee: Justin Ross
>Priority: Trivial
>  Labels: patch
> Fix For: proton-c-0.18.0
>
> Attachments: 
> 0002-PROTON-622-Add-missing-error-check-to-pn_event_inspe.patch
>
>
> Found by XCode Analyze



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (DISPATCH-803) refuse attach to undefined addresses

2017-08-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on DISPATCH-803:
-

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

https://github.com/apache/qpid-dispatch/pull/185#discussion_r132280889
  
--- Diff: python/qpid_dispatch/management/qdrouter.json ---
@@ -504,6 +504,13 @@
 "deprecated": true,
 "description": "(DEPRECATED) This value is no longer 
used in the router.",
 "create": true
+},
+"defaultDistribution": {
+"type": ["multicast", "closest", "balanced", 
"forbidden"],
+"description": "Default forwarding treatment for any 
address without a specified treatment. multicast - one copy of each message 
delivered to all subscribers; closest - messages delivered to only the closest 
subscriber; balanced - messages delivered to one subscriber with load balanced 
across subscribers; linkBalanced - for link-routing, link attaches balanced 
across destinations; forbidden - this address is forbidden, link attaches to an 
address of forbidden distribution will be rejected.",
--- End diff --

linkBalanced should be removed from the comment


> refuse attach to undefined addresses
> 
>
> Key: DISPATCH-803
> URL: https://issues.apache.org/jira/browse/DISPATCH-803
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> At present, if you attach to an address in the router whose semantics have 
> not been specifically defined, you get balanced message routing semantics.
> It would be useful to be able to configure the router such that it would 
> refuse links whose source/target was not explicitly defined. E.g. by being 
> able to configure the default semantics to be of type 'invalid' (or anything 
> similar). (Being able to explicitly blacklist certain addresses might also be 
> nice, but is a more exotic use case I think).
> Messages sent through an anonymous link to these 'invalid' addresses would be 
> rejected.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...

2017-08-09 Thread grs
Github user grs commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/185#discussion_r132280889
  
--- Diff: python/qpid_dispatch/management/qdrouter.json ---
@@ -504,6 +504,13 @@
 "deprecated": true,
 "description": "(DEPRECATED) This value is no longer 
used in the router.",
 "create": true
+},
+"defaultDistribution": {
+"type": ["multicast", "closest", "balanced", 
"forbidden"],
+"description": "Default forwarding treatment for any 
address without a specified treatment. multicast - one copy of each message 
delivered to all subscribers; closest - messages delivered to only the closest 
subscriber; balanced - messages delivered to one subscriber with load balanced 
across subscribers; linkBalanced - for link-routing, link attaches balanced 
across destinations; forbidden - this address is forbidden, link attaches to an 
address of forbidden distribution will be rejected.",
--- End diff --

linkBalanced should be removed from the comment


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

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



[jira] [Commented] (DISPATCH-803) refuse attach to undefined addresses

2017-08-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on DISPATCH-803:
-

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

https://github.com/apache/qpid-dispatch/pull/185#discussion_r132281323
  
--- Diff: src/router_core/transfer.c ---
@@ -634,6 +634,23 @@ static void qdr_link_forward_CT(qdr_core_t *core, 
qdr_link_t *link, qdr_delivery
 addr->deliveries_ingress++;
 link->total_deliveries++;
 }
+//
+// There is no address that we can send this delivery to, which means 
the addr was not found in our hastable. This
+// can be because there were no receivers or because the address was 
not defined in the config file.
+// If the treatment for such addresses is set to be forbidden, we send 
back a rejected disposition and detach the link
+//
+else if (core->qd->treatment == QD_TREATMENT_LINK_FORBIDDEN) {
+dlv->disposition = PN_REJECTED;
+dlv->error = qdr_error("qd:forbidden", "Sending deliveries to this 
address is forbidden");
--- End diff --

Or perhaps even better would be amqp:not-found, since we are really saying 
that this is not a recognised address?


> refuse attach to undefined addresses
> 
>
> Key: DISPATCH-803
> URL: https://issues.apache.org/jira/browse/DISPATCH-803
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> At present, if you attach to an address in the router whose semantics have 
> not been specifically defined, you get balanced message routing semantics.
> It would be useful to be able to configure the router such that it would 
> refuse links whose source/target was not explicitly defined. E.g. by being 
> able to configure the default semantics to be of type 'invalid' (or anything 
> similar). (Being able to explicitly blacklist certain addresses might also be 
> nice, but is a more exotic use case I think).
> Messages sent through an anonymous link to these 'invalid' addresses would be 
> rejected.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Created] (QPID-7884) Python client should not raise exception on close() after stop.

2017-08-09 Thread Alan Conway (JIRA)
Alan Conway created QPID-7884:
-

 Summary: Python client should not raise exception on close() after 
stop.
 Key: QPID-7884
 URL: https://issues.apache.org/jira/browse/QPID-7884
 Project: Qpid
  Issue Type: Bug
  Components: Python Client
Affects Versions: qpid-python-1.36.0
Reporter: Alan Conway
Assignee: Alan Conway
 Fix For: qpid-python-1.37.0


The python client throws exceptions out of AMQP object methods (Connection, 
Session and Link objects) if the selector has been stopped, to prevent hanging 
(see QPID-7317 Deadlock on publish)

However to be robust to shut-down order, the close() method should *not* throw 
an exception in this case, but should be a no-op.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (QPID-7768) Problem building on Fedora rawhide

2017-08-09 Thread Irina Boverman (JIRA)

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

Irina Boverman commented on QPID-7768:
--

And here:

[ 64%] Built target receiver
make[2]: *** [src/CMakeFiles/qpidbroker.dir/build.make:3234: 
src/CMakeFiles/qpidbroker.dir/qpid/broker/Selector.cpp.o] Error 1

[ 66%] Building CXX object 
src/tests/CMakeFiles/qpid-topic-publisher.dir/qpid-topic-publisher.cpp.o
cd /foo/cpp/cpp-vpath/src/tests && /usr/bin/c++  -DBOOST_TEST_DYN_LINK 
-DXQ_EFFECTIVE_BOOLEAN_VALUE_HPP -I/foo/cpp/src -I/foo/cpp/src/../include 
-I/foo/cpp/cpp-vpath/src -I/foo/cpp/cpp-vpath/src/../include -isystem 
/usr/include/nss3 -isystem /usr/include/nspr4 -I/foo/usr/include 
-I/foo/cpp/src/tests  -fvisibility-inlines-hidden -Werror -pedantic -Wall 
-Wextra -Wno-shadow -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long 
-Wvolatile-register-var -Winvalid-pch -Wno-system-headers -Woverloaded-virtual 
-Wno-deprecated-declarations -Wno-implicit-fallthrough -O2 -g -DNDEBUG   
-pthread -Wno-variadic-macros -o 
CMakeFiles/qpid-topic-publisher.dir/qpid-topic-publisher.cpp.o -c 
/foo/cpp/src/tests/qpid-topic-publisher.cpp
/foo/cpp/src/qpid/broker/SelectorExpression.cpp: In member function 
'qpid::broker::Expression* qpid::broker::Parse::parseExactNumeric(const 
qpid::broker::Token&, bool)':
/foo/cpp/src/qpid/broker/SelectorExpression.cpp:1041:13: error: '*((void*)& s 
+17)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
 if (s[1]=='b' || s[1]=='B') {
/foo/cpp/src/qpid/broker/SelectorExpression.cpp: In member function 
'qpid::broker::Expression* 
qpid::broker::Parse::orExpression(qpid::broker::Tokeniser&)':
/foo/cpp/src/qpid/broker/SelectorExpression.cpp:1041:13: error: '*((void*)& s 
+17)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
 if (s[1]=='b' || s[1]=='B') {
/foo/cpp/src/qpid/broker/SelectorExpression.cpp:1041:13: error: '*((void*)& s 
+17)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
 if (s[1]=='b' || s[1]=='B') {
/foo/cpp/src/qpid/broker/SelectorExpression.cpp:1041:13: error: '*((void*)& s 
+17)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
 if (s[1]=='b' || s[1]=='B') {
/foo/cpp/src/qpid/broker/SelectorExpression.cpp:1041:13: error: '*((void*)& s 
+17)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
 if (s[1]=='b' || s[1]=='B') {
/foo/cpp/src/qpid/broker/SelectorExpression.cpp:1041:13: error: '*((void*)& s 
+17)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
 if (s[1]=='b' || s[1]=='B') {
/foo/cpp/src/qpid/broker/SelectorExpression.cpp: In member function 
'qpid::broker::Expression* 
qpid::broker::Parse::unaryArithExpression(qpid::broker::Tokeniser&)':
/foo/cpp/src/qpid/broker/SelectorExpression.cpp:1041:13: error: '*((void*)& s 
+17)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
 if (s[1]=='b' || s[1]=='B') {
/foo/cpp/src/qpid/broker/SelectorExpression.cpp:1041:13: error: '*((void*)& s 
+17)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
 if (s[1]=='b' || s[1]=='B') {
cc1plus: all warnings being treated as errors
make[2]: *** [src/CMakeFiles/qpidbroker.dir/build.make:3258: 
src/CMakeFiles/qpidbroker.dir/qpid/broker/SelectorExpression.cpp.o] Error 1

> Problem building on Fedora rawhide
> --
>
> Key: QPID-7768
> URL: https://issues.apache.org/jira/browse/QPID-7768
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Build
>Affects Versions: qpid-cpp-1.36.0
> Environment: [ 78%] Building CXX object 
> src/CMakeFiles/qpidbroker.dir/qpid/broker/SessionAdapter.cpp.o
> cd /builddir/build/BUILD/qpid-cpp-1.36.0/src && /usr/bin/c++  
> -DXQ_EFFECTIVE_BOOLEAN_VALUE_HPP -Dqpidbroker_EXPORTS 
> -I/builddir/build/BUILD/qpid-cpp-1.36.0/src 
> -I/builddir/build/BUILD/qpid-cpp-1.36.0/src/../include -I/usr/include/nss3 
> -I/usr/include/nspr4  -std=c++11 -Wno-implicit-fallthrough 
> -Wno-deprecated-declarations -O2 -g -pipe -Wall -Werror=format-security 
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
> --param=ssp-buffer-size=4 -grecord-gcc-switches 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic  
> -fvisibility-inlines-hidden -Werror -pedantic -Wall -Wextra -Wno-shadow 
> -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long 
> -Wvolatile-register-var -Winvalid-pch -Wno-system-headers 
> -Woverloaded-virtual -Wno-error=deprecated-declarations -O2 -g -DNDEBUG -fPIC 
>   -pthread -o CMakeFiles/qpidbroker.dir/qpid/broker/SessionAdapter.cpp.o -c 
> /builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/broker/SessionAdapter.cpp
> In file included from 
> /builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/broker/SelectorToken.cpp:22:0:
> 

[jira] [Assigned] (QPID-7768) Problem building on Fedora rawhide

2017-08-09 Thread Justin Ross (JIRA)

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

Justin Ross reassigned QPID-7768:
-

Assignee: Justin Ross

> Problem building on Fedora rawhide
> --
>
> Key: QPID-7768
> URL: https://issues.apache.org/jira/browse/QPID-7768
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Build
>Affects Versions: qpid-cpp-1.36.0
> Environment: [ 78%] Building CXX object 
> src/CMakeFiles/qpidbroker.dir/qpid/broker/SessionAdapter.cpp.o
> cd /builddir/build/BUILD/qpid-cpp-1.36.0/src && /usr/bin/c++  
> -DXQ_EFFECTIVE_BOOLEAN_VALUE_HPP -Dqpidbroker_EXPORTS 
> -I/builddir/build/BUILD/qpid-cpp-1.36.0/src 
> -I/builddir/build/BUILD/qpid-cpp-1.36.0/src/../include -I/usr/include/nss3 
> -I/usr/include/nspr4  -std=c++11 -Wno-implicit-fallthrough 
> -Wno-deprecated-declarations -O2 -g -pipe -Wall -Werror=format-security 
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
> --param=ssp-buffer-size=4 -grecord-gcc-switches 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic  
> -fvisibility-inlines-hidden -Werror -pedantic -Wall -Wextra -Wno-shadow 
> -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long 
> -Wvolatile-register-var -Winvalid-pch -Wno-system-headers 
> -Woverloaded-virtual -Wno-error=deprecated-declarations -O2 -g -DNDEBUG -fPIC 
>   -pthread -o CMakeFiles/qpidbroker.dir/qpid/broker/SessionAdapter.cpp.o -c 
> /builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/broker/SessionAdapter.cpp
> In file included from 
> /builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/broker/SelectorToken.cpp:22:0:
> /builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/broker/SelectorToken.h: In 
> member function 'const qpid::broker::Token& 
> qpid::broker::Tokeniser::nextToken()':
> /builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/broker/SelectorToken.h:67:8: 
> error: '.qpid::broker::Token::type' may be used uninitialized in 
> this function [-Werror=maybe-uninitialized]
>  struct Token {
> ^
> cc1plus: all warnings being treated as errors
> make[2]: *** [src/CMakeFiles/qpidbroker.dir/build.make:3282: 
> src/CMakeFiles/qpidbroker.dir/qpid/broker/SelectorToken.cpp.o] Error 1
>Reporter: Irina Boverman
>Assignee: Justin Ross
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (QPID-7884) Python client should not raise exception on close() after stop.

2017-08-09 Thread Alan Conway (JIRA)

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

Alan Conway commented on QPID-7884:
---


master origin/master origin/HEAD 7c968c8318f4c4a70fbe0ebbcdbe0a09d8cfbb3e
Author: Alan Conway 
AuthorDate: Wed Aug 9 16:06:35 2017 -0400
Commit: Alan Conway 
CommitDate: Wed Aug 9 16:06:35 2017 -0400

Parent: 0c3c82b QPID-7809: Python 0-10 messaging driver does not handle 
heartbeat timeouts, "assert rcv.received < rcv.impending" occurs
Merged: master py-deadlock-new
Containing: master

QUID-7884: Python client should not raise on close() after stop.

The python client throws exceptions out of AMQP object methods (Connection, 
Session and Link objects) if the selector has been stopped, to prevent hanging 
(see QPID-7317 Deadlock on publish)

However to be robust to shut-down order, the close() method should not throw an 
exception in this case, but should be a no-op.


> Python client should not raise exception on close() after stop.
> ---
>
> Key: QPID-7884
> URL: https://issues.apache.org/jira/browse/QPID-7884
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Affects Versions: qpid-python-1.36.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: qpid-python-1.37.0
>
>
> The python client throws exceptions out of AMQP object methods (Connection, 
> Session and Link objects) if the selector has been stopped, to prevent 
> hanging (see QPID-7317 Deadlock on publish)
> However to be robust to shut-down order, the close() method should *not* 
> throw an exception in this case, but should be a no-op.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (PROTON-1533) Swig deprecation warnings with recent versions of cmake

2017-08-09 Thread ASF subversion and git services (JIRA)

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

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

Commit bdac005a999ffded075eafc61877515edf236b38 in qpid-proton's branch 
refs/heads/master from [~jr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=bdac005 ]

PROTON-1533: Fix swig deprecation warnings


> Swig deprecation warnings with recent versions of cmake
> ---
>
> Key: PROTON-1533
> URL: https://issues.apache.org/jira/browse/PROTON-1533
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: build
> Environment: Fedora 25, 26
> Cmake 3.8+
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Minor
> Fix For: proton-c-0.18.0
>
>
> Same output as described in https://issues.apache.org/jira/browse/QPID-7860



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (QPID-7867) Authentication using expired certificate

2017-08-09 Thread ASF subversion and git services (JIRA)

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

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

Commit f267226ab091ce1ff08bec9f42e8be9ac66019b0 in qpid-broker-j's branch 
refs/heads/master from Oleksandr Rudyy
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=f267226 ]

QPID-7867: [Java Broker] Address review comments


> Authentication using expired certificate
> 
>
> Key: QPID-7867
> URL: https://issues.apache.org/jira/browse/QPID-7867
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
> Environment: * qpid-jms-client version 0.23.0
> * java qpid broker 7.0.0
>Reporter: Martin Krasa
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Using qpid-jms-client version 0.23.0 and (as of July 17 2017) expired 
> self-signed certificate (Valid until: Sat Dec 17 10:46:56 CET 2016) user can 
> _successfully authenticate_ against the java qpid broker 7.0.0 
> {code:title=extract from Java broker log file|borderStyle=solid} 2017-07-14 
> 16:34:58,022 INFO [Broker-Config] (q.m.c.open) - [con:0(/XXX.XX.XX.XX:54268)] 
> CON-1001 : Open : Destination : amqps(XXX.XX.XX.XXX:10202) : Protocol Version 
> : 1.0 : SSL 2017-07-14 16:34:58,093 INFO [IO-/172.23.38.21:54268] 
> (q.m.c.open) - [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)] CON-1001 : 
> Open : Destination : amqps(XXX.XX.XX.XXX:10202) : Protocol Version : 1.0 : 
> SSL : Client ID : ID:6303ba8b-2055-49e5-9bf8-80336865a672:1 : Client Version 
> : 0.23.0 : Client Product : QpidJMS 2017-07-14 16:34:58,124 INFO 
> [IO-/XXX.XX.XX.XX:54268] (q.m.c.create) - 
> [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)/ch:0] CHN-1001 : Create 
> 2017-07-14 16:34:58,155 INFO [IO-/XXX.XX.XX.XX:54268] (q.m.c.create) - 
> [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)/ch:1] CHN-1001 : Create 
> {code} {color:blue}*NOTE:* The same behaviour rings true with expired node 
> certificate{color}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Resolved] (QPID-7867) Authentication using expired certificate

2017-08-09 Thread Alex Rudyy (JIRA)

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

Alex Rudyy resolved QPID-7867.
--
Resolution: Fixed
  Assignee: (was: Keith Wall)

> Authentication using expired certificate
> 
>
> Key: QPID-7867
> URL: https://issues.apache.org/jira/browse/QPID-7867
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
> Environment: * qpid-jms-client version 0.23.0
> * java qpid broker 7.0.0
>Reporter: Martin Krasa
> Fix For: qpid-java-broker-7.0.0
>
>
> Using qpid-jms-client version 0.23.0 and (as of July 17 2017) expired 
> self-signed certificate (Valid until: Sat Dec 17 10:46:56 CET 2016) user can 
> _successfully authenticate_ against the java qpid broker 7.0.0 
> {code:title=extract from Java broker log file|borderStyle=solid} 2017-07-14 
> 16:34:58,022 INFO [Broker-Config] (q.m.c.open) - [con:0(/XXX.XX.XX.XX:54268)] 
> CON-1001 : Open : Destination : amqps(XXX.XX.XX.XXX:10202) : Protocol Version 
> : 1.0 : SSL 2017-07-14 16:34:58,093 INFO [IO-/172.23.38.21:54268] 
> (q.m.c.open) - [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)] CON-1001 : 
> Open : Destination : amqps(XXX.XX.XX.XXX:10202) : Protocol Version : 1.0 : 
> SSL : Client ID : ID:6303ba8b-2055-49e5-9bf8-80336865a672:1 : Client Version 
> : 0.23.0 : Client Product : QpidJMS 2017-07-14 16:34:58,124 INFO 
> [IO-/XXX.XX.XX.XX:54268] (q.m.c.create) - 
> [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)/ch:0] CHN-1001 : Create 
> 2017-07-14 16:34:58,155 INFO [IO-/XXX.XX.XX.XX:54268] (q.m.c.create) - 
> [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)/ch:1] CHN-1001 : Create 
> {code} {color:blue}*NOTE:* The same behaviour rings true with expired node 
> certificate{color}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Resolved] (PROTON-749) Refactor Proton C transport code

2017-08-09 Thread Alan Conway (JIRA)

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

Alan Conway resolved PROTON-749.

Resolution: Fixed

> Refactor Proton C transport code
> 
>
> Key: PROTON-749
> URL: https://issues.apache.org/jira/browse/PROTON-749
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.9
>Reporter: Andrew Stitcher
>Assignee: Alan Conway
>  Labels: api
> Fix For: proton-c-0.19.0
>
>
> The proton-c transport code is refactored to improve a bunch of things:
> - Some slimming and simplification of the transport code.
> - More understandable control flow.
> - Less obscure holding of the transport layer state.
> - Allowing a proton server to automatically configure itself for the protocol 
> layers used by attaching clients.
> - Limited new APIs, but some exiting APIs deprecated



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Updated] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class

2017-08-09 Thread Jiri Danek (JIRA)

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

Jiri Danek updated QPIDJMS-313:
---
Affects Version/s: 0.24.0

> Message#getBody does not throw when attempting to read a BytesMessage as 
> String.class
> -
>
> Key: QPIDJMS-313
> URL: https://issues.apache.org/jira/browse/QPIDJMS-313
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.23.0, 0.24.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Consider the ActiveMQ Artemis test 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
>  adapted to run through multiple JMS ConnectionFactories in turn. This test 
> passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
> OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.
> {noformat}
>  BytesMessage bytesMessage = sess.createBytesMessage();
>  producer.send(bytesMessage);
>  Message msg = cons.receiveNoWait();
>  assertNotNull(msg);
>  try {
> msg.getBody(String.class);
> fail("Exception expected");
>  } catch (MessageFormatException e) {
>  }
> {noformat}
> The failing line is the {{fail("Exception expected");}}, because qpid-jms 
> does not throw {{MessageFormatException}} where it is supposed to.
> According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If 
> the message is a BytesMessage then this parameter must be set to byte[].class 
> (or java.lang.Object.class). This method will reset the BytesMessage before 
> and after use." ... "Throws: MessageFormatException" ... "if the message body 
> cannot be assigned to the specified type."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class

2017-08-09 Thread ASF subversion and git services (JIRA)

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

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

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

QPIDJMS-313 Add some additional tests to show the issue is not valid

Add a few more tests that check in different contexts that the getBody
method does throw when expected.

> Message#getBody does not throw when attempting to read a BytesMessage as 
> String.class
> -
>
> Key: QPIDJMS-313
> URL: https://issues.apache.org/jira/browse/QPIDJMS-313
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.23.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Consider the ActiveMQ Artemis test 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
>  adapted to run through multiple JMS ConnectionFactories in turn. This test 
> passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
> OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.
> {noformat}
>  BytesMessage bytesMessage = sess.createBytesMessage();
>  producer.send(bytesMessage);
>  Message msg = cons.receiveNoWait();
>  assertNotNull(msg);
>  try {
> msg.getBody(String.class);
> fail("Exception expected");
>  } catch (MessageFormatException e) {
>  }
> {noformat}
> The failing line is the {{fail("Exception expected");}}, because qpid-jms 
> does not throw {{MessageFormatException}} where it is supposed to.
> According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If 
> the message is a BytesMessage then this parameter must be set to byte[].class 
> (or java.lang.Object.class). This method will reset the BytesMessage before 
> and after use." ... "Throws: MessageFormatException" ... "if the message body 
> cannot be assigned to the specified type."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Reopened] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class

2017-08-09 Thread Jiri Danek (JIRA)

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

Jiri Danek reopened QPIDJMS-313:


> Message#getBody does not throw when attempting to read a BytesMessage as 
> String.class
> -
>
> Key: QPIDJMS-313
> URL: https://issues.apache.org/jira/browse/QPIDJMS-313
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.23.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Consider the ActiveMQ Artemis test 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
>  adapted to run through multiple JMS ConnectionFactories in turn. This test 
> passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
> OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.
> {noformat}
>  BytesMessage bytesMessage = sess.createBytesMessage();
>  producer.send(bytesMessage);
>  Message msg = cons.receiveNoWait();
>  assertNotNull(msg);
>  try {
> msg.getBody(String.class);
> fail("Exception expected");
>  } catch (MessageFormatException e) {
>  }
> {noformat}
> The failing line is the {{fail("Exception expected");}}, because qpid-jms 
> does not throw {{MessageFormatException}} where it is supposed to.
> According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If 
> the message is a BytesMessage then this parameter must be set to byte[].class 
> (or java.lang.Object.class). This method will reset the BytesMessage before 
> and after use." ... "Throws: MessageFormatException" ... "if the message body 
> cannot be assigned to the specified type."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class

2017-08-09 Thread Timothy Bish (JIRA)

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

Timothy Bish commented on QPIDJMS-313:
--

Give the initial source of the test I'd assert that the Artemis JMS client is 
probably in violation of the spec if it is throwing the exception when there is 
no body. 

> Message#getBody does not throw when attempting to read a BytesMessage as 
> String.class
> -
>
> Key: QPIDJMS-313
> URL: https://issues.apache.org/jira/browse/QPIDJMS-313
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.23.0, 0.24.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Consider the ActiveMQ Artemis test 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
>  adapted to run through multiple JMS ConnectionFactories in turn. This test 
> passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
> OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.
> {noformat}
>  BytesMessage bytesMessage = sess.createBytesMessage();
>  producer.send(bytesMessage);
>  Message msg = cons.receiveNoWait();
>  assertNotNull(msg);
>  try {
> msg.getBody(String.class);
> fail("Exception expected");
>  } catch (MessageFormatException e) {
>  }
> {noformat}
> The failing line is the {{fail("Exception expected");}}, because qpid-jms 
> does not throw {{MessageFormatException}} where it is supposed to.
> According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If 
> the message is a BytesMessage then this parameter must be set to byte[].class 
> (or java.lang.Object.class). This method will reset the BytesMessage before 
> and after use." ... "Throws: MessageFormatException" ... "if the message body 
> cannot be assigned to the specified type."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (QPID-7867) Authentication using expired certificate

2017-08-09 Thread Alex Rudyy (JIRA)

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

Alex Rudyy commented on QPID-7867:
--

I reviewed the changes. Here are my comments about minor issues
# # It looks like that constant {{PEERS_ONLY}} was moved from interface  
{{FileTrustStore}} into interface  {{TrustStore}} by mistake. Only 
{{FileTrustStore}} has managed attribute {{peersOnly}}. Thus, the constant with 
an attribute name should be declared in {{FileTrustStore}} rather in its parent
# Abstract method {{AbstrauctTrustore#getTrustManagersInternal()}} is declared 
protected but its visibility is changed to public in inherited classes 
{{FileTrustStoreImpl}}, {{ManagedPeerCertificateTrustStoreImpl}}, 
{{NonJavaTrustStoreImpl}} and {{SiteSpecificTrustStoreImpl}}


> Authentication using expired certificate
> 
>
> Key: QPID-7867
> URL: https://issues.apache.org/jira/browse/QPID-7867
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
> Environment: * qpid-jms-client version 0.23.0
> * java qpid broker 7.0.0
>Reporter: Martin Krasa
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Using qpid-jms-client version 0.23.0 and (as of July 17 2017) expired 
> self-signed certificate (Valid until: Sat Dec 17 10:46:56 CET 2016) user can 
> _successfully authenticate_ against the java qpid broker 7.0.0 
> {code:title=extract from Java broker log file|borderStyle=solid} 2017-07-14 
> 16:34:58,022 INFO [Broker-Config] (q.m.c.open) - [con:0(/XXX.XX.XX.XX:54268)] 
> CON-1001 : Open : Destination : amqps(XXX.XX.XX.XXX:10202) : Protocol Version 
> : 1.0 : SSL 2017-07-14 16:34:58,093 INFO [IO-/172.23.38.21:54268] 
> (q.m.c.open) - [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)] CON-1001 : 
> Open : Destination : amqps(XXX.XX.XX.XXX:10202) : Protocol Version : 1.0 : 
> SSL : Client ID : ID:6303ba8b-2055-49e5-9bf8-80336865a672:1 : Client Version 
> : 0.23.0 : Client Product : QpidJMS 2017-07-14 16:34:58,124 INFO 
> [IO-/XXX.XX.XX.XX:54268] (q.m.c.create) - 
> [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)/ch:0] CHN-1001 : Create 
> 2017-07-14 16:34:58,155 INFO [IO-/XXX.XX.XX.XX:54268] (q.m.c.create) - 
> [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)/ch:1] CHN-1001 : Create 
> {code} {color:blue}*NOTE:* The same behaviour rings true with expired node 
> certificate{color}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Resolved] (PROTON-1533) Swig deprecation warnings with recent versions of cmake

2017-08-09 Thread Justin Ross (JIRA)

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

Justin Ross resolved PROTON-1533.
-
Resolution: Fixed

> Swig deprecation warnings with recent versions of cmake
> ---
>
> Key: PROTON-1533
> URL: https://issues.apache.org/jira/browse/PROTON-1533
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: build
> Environment: Fedora 25, 26
> Cmake 3.8+
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Minor
> Fix For: proton-c-0.18.0
>
>
> Same output as described in https://issues.apache.org/jira/browse/QPID-7860



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (PROTON-1176) Core dump if reactor creation fails

2017-08-09 Thread Alan Conway (JIRA)

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

Alan Conway commented on PROTON-1176:
-

[~jr...@redhat.com] I don't think this has changed, probably it's the first 
time someone's tried the out-of-fds case. Should be simple to fix.

> Core dump if reactor creation fails
> ---
>
> Key: PROTON-1176
> URL: https://issues.apache.org/jira/browse/PROTON-1176
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.12.0
>Reporter: Cliff Jansen
>Assignee: Alan Conway
>  Labels: crash
> Fix For: proton-c-0.18.0
>
>
> If a BlockingConnection fails creating a reactor from Proton-C, the wrapper 
> constructor for the container fails on a null "impl" value, causing a core 
> dump rather than an exception.
> This can happen if the process runs out of file descriptors and cannot 
> allocate the self-pipes needed by the reactor.
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1319165



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Updated] (PROTON-749) Refactor Proton C transport code

2017-08-09 Thread Justin Ross (JIRA)

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

Justin Ross updated PROTON-749:
---
Fix Version/s: (was: proton-c-0.19.0)
   proton-c-0.18.0

> Refactor Proton C transport code
> 
>
> Key: PROTON-749
> URL: https://issues.apache.org/jira/browse/PROTON-749
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.9
>Reporter: Andrew Stitcher
>Assignee: Alan Conway
>  Labels: api
> Fix For: proton-c-0.18.0
>
>
> The proton-c transport code is refactored to improve a bunch of things:
> - Some slimming and simplification of the transport code.
> - More understandable control flow.
> - Less obscure holding of the transport layer state.
> - Allowing a proton server to automatically configure itself for the protocol 
> layers used by attaching clients.
> - Limited new APIs, but some exiting APIs deprecated



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class

2017-08-09 Thread Jiri Danek (JIRA)

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

Jiri Danek commented on QPIDJMS-313:


Oh, I haven't read the whole document. Thanks.

> Message#getBody does not throw when attempting to read a BytesMessage as 
> String.class
> -
>
> Key: QPIDJMS-313
> URL: https://issues.apache.org/jira/browse/QPIDJMS-313
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.23.0, 0.24.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Consider the ActiveMQ Artemis test 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
>  adapted to run through multiple JMS ConnectionFactories in turn. This test 
> passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
> OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.
> {noformat}
>  BytesMessage bytesMessage = sess.createBytesMessage();
>  producer.send(bytesMessage);
>  Message msg = cons.receiveNoWait();
>  assertNotNull(msg);
>  try {
> msg.getBody(String.class);
> fail("Exception expected");
>  } catch (MessageFormatException e) {
>  }
> {noformat}
> The failing line is the {{fail("Exception expected");}}, because qpid-jms 
> does not throw {{MessageFormatException}} where it is supposed to.
> According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If 
> the message is a BytesMessage then this parameter must be set to byte[].class 
> (or java.lang.Object.class). This method will reset the BytesMessage before 
> and after use." ... "Throws: MessageFormatException" ... "if the message body 
> cannot be assigned to the specified type."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Closed] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class

2017-08-09 Thread Jiri Danek (JIRA)

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

Jiri Danek closed QPIDJMS-313.
--
Resolution: Invalid

> Message#getBody does not throw when attempting to read a BytesMessage as 
> String.class
> -
>
> Key: QPIDJMS-313
> URL: https://issues.apache.org/jira/browse/QPIDJMS-313
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.23.0, 0.24.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Consider the ActiveMQ Artemis test 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
>  adapted to run through multiple JMS ConnectionFactories in turn. This test 
> passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
> OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.
> {noformat}
>  BytesMessage bytesMessage = sess.createBytesMessage();
>  producer.send(bytesMessage);
>  Message msg = cons.receiveNoWait();
>  assertNotNull(msg);
>  try {
> msg.getBody(String.class);
> fail("Exception expected");
>  } catch (MessageFormatException e) {
>  }
> {noformat}
> The failing line is the {{fail("Exception expected");}}, because qpid-jms 
> does not throw {{MessageFormatException}} where it is supposed to.
> According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If 
> the message is a BytesMessage then this parameter must be set to byte[].class 
> (or java.lang.Object.class). This method will reset the BytesMessage before 
> and after use." ... "Throws: MessageFormatException" ... "if the message body 
> cannot be assigned to the specified type."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[GitHub] qpid-proton pull request #115: PROTON-1533: Fix swig deprecation warnings

2017-08-09 Thread ssorj
Github user ssorj closed the pull request at:

https://github.com/apache/qpid-proton/pull/115


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

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



[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...

2017-08-09 Thread ganeshmurthy
Github user ganeshmurthy commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/185#discussion_r132308131
  
--- Diff: python/qpid_dispatch/management/qdrouter.json ---
@@ -504,6 +504,13 @@
 "deprecated": true,
 "description": "(DEPRECATED) This value is no longer 
used in the router.",
 "create": true
+},
+"defaultDistribution": {
+"type": ["multicast", "closest", "balanced", 
"forbidden"],
+"description": "Default forwarding treatment for any 
address without a specified treatment. multicast - one copy of each message 
delivered to all subscribers; closest - messages delivered to only the closest 
subscriber; balanced - messages delivered to one subscriber with load balanced 
across subscribers; linkBalanced - for link-routing, link attaches balanced 
across destinations; forbidden - this address is forbidden, link attaches to an 
address of forbidden distribution will be rejected.",
--- End diff --

Removed linkBalanced from comment


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

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



[jira] [Commented] (DISPATCH-803) refuse attach to undefined addresses

2017-08-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on DISPATCH-803:
-

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

https://github.com/apache/qpid-dispatch/pull/185#discussion_r132308131
  
--- Diff: python/qpid_dispatch/management/qdrouter.json ---
@@ -504,6 +504,13 @@
 "deprecated": true,
 "description": "(DEPRECATED) This value is no longer 
used in the router.",
 "create": true
+},
+"defaultDistribution": {
+"type": ["multicast", "closest", "balanced", 
"forbidden"],
+"description": "Default forwarding treatment for any 
address without a specified treatment. multicast - one copy of each message 
delivered to all subscribers; closest - messages delivered to only the closest 
subscriber; balanced - messages delivered to one subscriber with load balanced 
across subscribers; linkBalanced - for link-routing, link attaches balanced 
across destinations; forbidden - this address is forbidden, link attaches to an 
address of forbidden distribution will be rejected.",
--- End diff --

Removed linkBalanced from comment


> refuse attach to undefined addresses
> 
>
> Key: DISPATCH-803
> URL: https://issues.apache.org/jira/browse/DISPATCH-803
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> At present, if you attach to an address in the router whose semantics have 
> not been specifically defined, you get balanced message routing semantics.
> It would be useful to be able to configure the router such that it would 
> refuse links whose source/target was not explicitly defined. E.g. by being 
> able to configure the default semantics to be of type 'invalid' (or anything 
> similar). (Being able to explicitly blacklist certain addresses might also be 
> nice, but is a more exotic use case I think).
> Messages sent through an anonymous link to these 'invalid' addresses would be 
> rejected.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (DISPATCH-803) refuse attach to undefined addresses

2017-08-09 Thread Alan Conway (JIRA)

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

Alan Conway commented on DISPATCH-803:
--

[~gsim] et al. I retract my retraction. Ignore [#16120352] and carry on. Been 
on holiday too long.

> refuse attach to undefined addresses
> 
>
> Key: DISPATCH-803
> URL: https://issues.apache.org/jira/browse/DISPATCH-803
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> At present, if you attach to an address in the router whose semantics have 
> not been specifically defined, you get balanced message routing semantics.
> It would be useful to be able to configure the router such that it would 
> refuse links whose source/target was not explicitly defined. E.g. by being 
> able to configure the default semantics to be of type 'invalid' (or anything 
> similar). (Being able to explicitly blacklist certain addresses might also be 
> nice, but is a more exotic use case I think).
> Messages sent through an anonymous link to these 'invalid' addresses would be 
> rejected.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Issue Comment Deleted] (DISPATCH-803) refuse attach to undefined addresses

2017-08-09 Thread Alan Conway (JIRA)

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

Alan Conway updated DISPATCH-803:
-
Comment: was deleted

(was: I want to back up a bit, I think my suggestion was not right. The 
original requirement is to prevent auto-creation of addresses. This proposal 
sounds like the router will auto-create *forbidden* addresses which is quite 
different: Not auto-creating address X means client connecting/sending to X 
gets a 'not-found' error.  Creating X with {distribution=forbidden} creates a 
permanently unusable address named X, which would have to be explicitly deleted 
or modified to use it later.  We could make a special case meaning for 
defaultDistribution=forbidden but that is confusing. I think separate config is 
better:

autoLink = True|False # default True
autoCreateDistribution # default balanced

With these two attributes we don't need "forbidden" for this JIRA (but can 
still introduce it later if we want to)

Sorry for leading the conversation astray. )

> refuse attach to undefined addresses
> 
>
> Key: DISPATCH-803
> URL: https://issues.apache.org/jira/browse/DISPATCH-803
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> At present, if you attach to an address in the router whose semantics have 
> not been specifically defined, you get balanced message routing semantics.
> It would be useful to be able to configure the router such that it would 
> refuse links whose source/target was not explicitly defined. E.g. by being 
> able to configure the default semantics to be of type 'invalid' (or anything 
> similar). (Being able to explicitly blacklist certain addresses might also be 
> nice, but is a more exotic use case I think).
> Messages sent through an anonymous link to these 'invalid' addresses would be 
> rejected.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Created] (PROTON-1534) Python client BlockingConnection fails cleanup on LinkDetached exception with socket in close_wait and straggling pipe

2017-08-09 Thread Cliff Jansen (JIRA)
Cliff Jansen created PROTON-1534:


 Summary: Python client BlockingConnection fails cleanup on 
LinkDetached exception with socket in close_wait and straggling pipe
 Key: PROTON-1534
 URL: https://issues.apache.org/jira/browse/PROTON-1534
 Project: Qpid Proton
  Issue Type: Bug
  Components: python-binding
Affects Versions: 0.17.0, 0.16.0, 0.15.0, 0.14.0, 0.13.0, 0.12.0, 0.11.0, 
0.10, 0.9
Reporter: Cliff Jansen
Assignee: Cliff Jansen
 Fix For: proton-c-0.18.0


goferd tries to clean up after an interrupted receive operation, but the 
LinkDetached exception is not cleared from the BlockingConnection and the 
underlying C reactor fails to progress through its cleanup mechanism.

When BlockingConnection.close() is called, the code should muscle through to 
full resource cleanup.  The application is no longer interested in reactor 
events or exceptions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (DISPATCH-803) refuse attach to undefined addresses

2017-08-09 Thread Alan Conway (JIRA)

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

Alan Conway commented on DISPATCH-803:
--

I want to back up a bit, I think my suggestion was not right. The original 
requirement is to prevent auto-creation of addresses. This proposal sounds like 
the router will auto-create *forbidden* addresses which is quite different: Not 
auto-creating address X means client connecting/sending to X gets a 'not-found' 
error.  Creating X with {distribution=forbidden} creates a permanently unusable 
address named X, which would have to be explicitly deleted or modified to use 
it later.  We could make a special case meaning for 
defaultDistribution=forbidden but that is confusing. I think separate config is 
better:

autoLink = True|False # default True
autoCreateDistribution # default balanced

With these two attributes we don't need "forbidden" for this JIRA (but can 
still introduce it later if we want to)

Sorry for leading the conversation astray. 

> refuse attach to undefined addresses
> 
>
> Key: DISPATCH-803
> URL: https://issues.apache.org/jira/browse/DISPATCH-803
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> At present, if you attach to an address in the router whose semantics have 
> not been specifically defined, you get balanced message routing semantics.
> It would be useful to be able to configure the router such that it would 
> refuse links whose source/target was not explicitly defined. E.g. by being 
> able to configure the default semantics to be of type 'invalid' (or anything 
> similar). (Being able to explicitly blacklist certain addresses might also be 
> nice, but is a more exotic use case I think).
> Messages sent through an anonymous link to these 'invalid' addresses would be 
> rejected.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (DISPATCH-731) Support wildcard tenant vhosts in address prefix configuration

2017-08-09 Thread ASF subversion and git services (JIRA)

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

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

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

DISPATCH-731: support wildcard configured addresses


> Support wildcard tenant vhosts in address prefix configuration
> --
>
> Key: DISPATCH-731
> URL: https://issues.apache.org/jira/browse/DISPATCH-731
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 0.7.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Minor
> Fix For: 1.0.0
>
>
> When specifying address prefix patterns it should be possible to use a 
> wildcard match for the vhost.  Example:
> address {
> prefix: a_prefix   # matches current vhost (from open frame)
> }
> address {
> prefix: /my-vhost.com/other_prefix  # matched only if vhost=my-vhost
> }
> address {
> prefix:  /*.#.domain1.com/prefix_3 # matched if vhost ends with 
> domain1.com
> }
> address {
> prefix: /my.vhost.*.com/prefix_4  #matched if vhost starts with 
> 'my.vhost', has a single wildcard component, and ends with '.com'
> }
> Or something like that, I think.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (DISPATCH-731) Support wildcard tenant vhosts in address prefix configuration

2017-08-09 Thread ASF subversion and git services (JIRA)

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

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

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

DISPATCH-731: add parse tree unit tests


> Support wildcard tenant vhosts in address prefix configuration
> --
>
> Key: DISPATCH-731
> URL: https://issues.apache.org/jira/browse/DISPATCH-731
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 0.7.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Minor
> Fix For: 1.0.0
>
>
> When specifying address prefix patterns it should be possible to use a 
> wildcard match for the vhost.  Example:
> address {
> prefix: a_prefix   # matches current vhost (from open frame)
> }
> address {
> prefix: /my-vhost.com/other_prefix  # matched only if vhost=my-vhost
> }
> address {
> prefix:  /*.#.domain1.com/prefix_3 # matched if vhost ends with 
> domain1.com
> }
> address {
> prefix: /my.vhost.*.com/prefix_4  #matched if vhost starts with 
> 'my.vhost', has a single wildcard component, and ends with '.com'
> }
> Or something like that, I think.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (DISPATCH-731) Support wildcard tenant vhosts in address prefix configuration

2017-08-09 Thread ASF subversion and git services (JIRA)

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

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

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

DISPATCH-731: fix an iterator leak


> Support wildcard tenant vhosts in address prefix configuration
> --
>
> Key: DISPATCH-731
> URL: https://issues.apache.org/jira/browse/DISPATCH-731
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 0.7.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Minor
> Fix For: 1.0.0
>
>
> When specifying address prefix patterns it should be possible to use a 
> wildcard match for the vhost.  Example:
> address {
> prefix: a_prefix   # matches current vhost (from open frame)
> }
> address {
> prefix: /my-vhost.com/other_prefix  # matched only if vhost=my-vhost
> }
> address {
> prefix:  /*.#.domain1.com/prefix_3 # matched if vhost ends with 
> domain1.com
> }
> address {
> prefix: /my.vhost.*.com/prefix_4  #matched if vhost starts with 
> 'my.vhost', has a single wildcard component, and ends with '.com'
> }
> Or something like that, I think.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (DISPATCH-731) Support wildcard tenant vhosts in address prefix configuration

2017-08-09 Thread ASF subversion and git services (JIRA)

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

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

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

Merge branch 'master' into DISPATCH-731


> Support wildcard tenant vhosts in address prefix configuration
> --
>
> Key: DISPATCH-731
> URL: https://issues.apache.org/jira/browse/DISPATCH-731
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 0.7.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Minor
> Fix For: 1.0.0
>
>
> When specifying address prefix patterns it should be possible to use a 
> wildcard match for the vhost.  Example:
> address {
> prefix: a_prefix   # matches current vhost (from open frame)
> }
> address {
> prefix: /my-vhost.com/other_prefix  # matched only if vhost=my-vhost
> }
> address {
> prefix:  /*.#.domain1.com/prefix_3 # matched if vhost ends with 
> domain1.com
> }
> address {
> prefix: /my.vhost.*.com/prefix_4  #matched if vhost starts with 
> 'my.vhost', has a single wildcard component, and ends with '.com'
> }
> Or something like that, I think.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (DISPATCH-731) Support wildcard tenant vhosts in address prefix configuration

2017-08-09 Thread ASF subversion and git services (JIRA)

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

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

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

DISPATCH-731: add functional tests


> Support wildcard tenant vhosts in address prefix configuration
> --
>
> Key: DISPATCH-731
> URL: https://issues.apache.org/jira/browse/DISPATCH-731
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 0.7.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Minor
> Fix For: 1.0.0
>
>
> When specifying address prefix patterns it should be possible to use a 
> wildcard match for the vhost.  Example:
> address {
> prefix: a_prefix   # matches current vhost (from open frame)
> }
> address {
> prefix: /my-vhost.com/other_prefix  # matched only if vhost=my-vhost
> }
> address {
> prefix:  /*.#.domain1.com/prefix_3 # matched if vhost ends with 
> domain1.com
> }
> address {
> prefix: /my.vhost.*.com/prefix_4  #matched if vhost starts with 
> 'my.vhost', has a single wildcard component, and ends with '.com'
> }
> Or something like that, I think.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (DISPATCH-731) Support wildcard tenant vhosts in address prefix configuration

2017-08-09 Thread ASF subversion and git services (JIRA)

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

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

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

Merge branch 'DISPATCH-731'

This closes #181


> Support wildcard tenant vhosts in address prefix configuration
> --
>
> Key: DISPATCH-731
> URL: https://issues.apache.org/jira/browse/DISPATCH-731
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 0.7.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Minor
> Fix For: 1.0.0
>
>
> When specifying address prefix patterns it should be possible to use a 
> wildcard match for the vhost.  Example:
> address {
> prefix: a_prefix   # matches current vhost (from open frame)
> }
> address {
> prefix: /my-vhost.com/other_prefix  # matched only if vhost=my-vhost
> }
> address {
> prefix:  /*.#.domain1.com/prefix_3 # matched if vhost ends with 
> domain1.com
> }
> address {
> prefix: /my.vhost.*.com/prefix_4  #matched if vhost starts with 
> 'my.vhost', has a single wildcard component, and ends with '.com'
> }
> Or something like that, I think.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (DISPATCH-731) Support wildcard tenant vhosts in address prefix configuration

2017-08-09 Thread ASF subversion and git services (JIRA)

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

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

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

Merge branch 'master' into DISPATCH-731


> Support wildcard tenant vhosts in address prefix configuration
> --
>
> Key: DISPATCH-731
> URL: https://issues.apache.org/jira/browse/DISPATCH-731
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 0.7.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Minor
> Fix For: 1.0.0
>
>
> When specifying address prefix patterns it should be possible to use a 
> wildcard match for the vhost.  Example:
> address {
> prefix: a_prefix   # matches current vhost (from open frame)
> }
> address {
> prefix: /my-vhost.com/other_prefix  # matched only if vhost=my-vhost
> }
> address {
> prefix:  /*.#.domain1.com/prefix_3 # matched if vhost ends with 
> domain1.com
> }
> address {
> prefix: /my.vhost.*.com/prefix_4  #matched if vhost starts with 
> 'my.vhost', has a single wildcard component, and ends with '.com'
> }
> Or something like that, I think.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (PROTON-1517) SyncRequestResponse(BlockingConnection).call() fails with timeout

2017-08-09 Thread Justin Ross (JIRA)

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

Justin Ross commented on PROTON-1517:
-

I can reproduce this problem, but near as I can tell, it's not a bug in the 
python binding really.  With print debugging, I see a numeric correlation ID 
(intentionally) sent  in the request to the qpidd agent, and I see a string 
correlation ID returned.  Everything works with the patch because it makes the 
correlation ID a string in every instance.

My theory is that the qpidd qmf code assumes and requires string correlation 
IDs, and implicitly converts to a string internally, but it's hard for me to 
tell from the C++ code.  [~tr...@redhat.com], is that a reasonable theory?



> SyncRequestResponse(BlockingConnection).call() fails with timeout
> -
>
> Key: PROTON-1517
> URL: https://issues.apache.org/jira/browse/PROTON-1517
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.17.0
> Environment: macOS Sierra 10.12.5
> Python 3.6.1
>Reporter: aikchar
>Assignee: Justin Ross
>  Labels: easyfix, patch
> Fix For: proton-c-0.18.0
>
>
> Send a QMFv2 message using SyncRequestResponse.call(). The response times out.
> h2. Repro
> This repro uses the example from 
> https://qpid.apache.org/releases/qpid-proton-0.17.0/proton/python/examples/sync_client.py.html.
> {noformat}
> $ python
> Python 3.6.1 (default, Apr 24 2017, 09:59:45)
> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> address = 
> >>> 'amqps://REDACTED_USERNAME:REDACTED_PASSWORD@REDACTED_IP_ADDR:5672/qmf.default.direct'
> >>> from proton import Url
> >>> url = Url(address)
> >>>
> >>> from proton.utils import SyncRequestResponse, BlockingConnection
> >>> client = SyncRequestResponse(BlockingConnection(url, timeout=15, 
> >>> target='qmf.default.direct', sasl_enabled=True, allowed_mechs='PLAIN'), 
> >>> 'qmf.default.direct')
> >>>
> >>> content = {'_what': 'OBJECT', '_schema_id': {'_class_name': 'queue'}}
> >>> properties = {'x-amqp-0-10.app-id': 'qmf2', 'qmf.opcode': 
> >>> '_query_request', 'method': 'request'}
> >>>
> >>> from proton import Message
> >>> m = Message(reply_to=client.receiver.remote_source.address, 
> >>> address=address, body=content, properties=properties, subject='broker')
> >>> r = client.call(m)
> Traceback (most recent call last):
>   File "", line 1, in 
>   File 
> "/Users/hamza.sheikh/virtualenvs/flight-test-py36/lib/python3.6/site-packages/proton/utils.py",
>  line 400, in call
> self.connection.wait(wakeup, msg="Waiting for response")
>   File 
> "/Users/hamza.sheikh/virtualenvs/flight-test-py36/lib/python3.6/site-packages/proton/utils.py",
>  line 288, in wait
> raise Timeout(txt)
> proton.Timeout: Connection 
> amqps://REDACTED_USERNAME:REDACTED_PASSWORD@REDACTED_IP_ADDR:5672/qmf.default.direct
>  timed out: Waiting for response
> >>>
> {noformat}
> h2. Patch
> Patch is to make sure correlation_id is a string.
> {noformat}
> $ git diff
> diff --git a/proton-c/bindings/python/proton/utils.py 
> b/proton-c/bindings/python/proton/utils.py
> index 05ef80df..528ce338 100644
> --- a/proton-c/bindings/python/proton/utils.py
> +++ b/proton-c/bindings/python/proton/utils.py
> @@ -349,7 +349,7 @@ class SyncRequestResponse(IncomingMessageHandler):
>  if not self.address and not request.address:
>  raise ValueError("Request message has no address: %s" % request)
>  request.reply_to = self.reply_to
> -request.correlation_id = correlation_id = self.correlation_id.next()
> +request.correlation_id = correlation_id = 
> str(self.correlation_id.next())
>  self.sender.send(request)
>  def wakeup():
>  return self.response and (self.response.correlation_id == 
> correlation_id)
> {noformat}
> After applying the patch, the response does not time out.
> {noformat}
> $ python
> Python 3.6.1 (default, Apr 24 2017, 09:59:45)
> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> address = 
> >>> 'amqps://REDACTED_USERNAME:REDACTED_PASSWORD@REDACTED_IP_ADDR:5672/qmf.default.direct'
> >>> from proton import Url
> >>> url = Url(address)
> >>>
> >>> from proton.utils import SyncRequestResponse, BlockingConnection
> >>> client = SyncRequestResponse(BlockingConnection(url, timeout=15, 
> >>> target='qmf.default.direct', sasl_enabled=True, allowed_mechs='PLAIN'), 
> >>> 'qmf.default.direct')
> >>>
> >>> content = {'_what': 'OBJECT', '_schema_id': {'_class_name': 'queue'}}
> >>> properties = {'x-amqp-0-10.app-id': 'qmf2', 

[jira] [Commented] (QPID-7434) Mature the AMQP message conversion layer (headers and content)

2017-08-09 Thread ASF subversion and git services (JIRA)

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

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

Commit 20c9c58c9469abd6398f16644c5b0e5c751a06dc in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=20c9c58 ]

QPID-7434: [Java Broker] Improve AMQP 0-8 to 1.0 content conversion and unit 
tests


> Mature the AMQP message conversion layer (headers and content)
> --
>
> Key: QPID-7434
> URL: https://issues.apache.org/jira/browse/QPID-7434
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> There are a number of gaps in our message converters that mean some message 
> are not converted with complete fidelity (particularly in the treatment of 
> application headers), and where complete fidelity cannot be acheived we need 
> sensible rules, uniformly implemented to decide how aspects degrade.
> For instance, for AMQP 0-8..0-10 allow application headers whose values were 
> complex types (e.g. map).  AMQP 1.0 disallows this.  What should the 
> behaviour be?  Should the header be dropped?
> Another instance is the length and constituency of the keys of application 
> headers.  AMQP 0-8..0-10 have a protocol restriction of 255 UTF8 bytes.  AMQP 
> has supports longer strings.  Also AMQP 0-9 says further restricts the key to 
> be formed like a Java identifier.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (QPID-7434) Mature the AMQP message conversion layer (headers and content)

2017-08-09 Thread ASF subversion and git services (JIRA)

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

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

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

QPID-7434: [Java Broker] Improve AMQP 0-10 to 1.0 content conversion and add 
unit tests


> Mature the AMQP message conversion layer (headers and content)
> --
>
> Key: QPID-7434
> URL: https://issues.apache.org/jira/browse/QPID-7434
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> There are a number of gaps in our message converters that mean some message 
> are not converted with complete fidelity (particularly in the treatment of 
> application headers), and where complete fidelity cannot be acheived we need 
> sensible rules, uniformly implemented to decide how aspects degrade.
> For instance, for AMQP 0-8..0-10 allow application headers whose values were 
> complex types (e.g. map).  AMQP 1.0 disallows this.  What should the 
> behaviour be?  Should the header be dropped?
> Another instance is the length and constituency of the keys of application 
> headers.  AMQP 0-8..0-10 have a protocol restriction of 255 UTF8 bytes.  AMQP 
> has supports longer strings.  Also AMQP 0-9 says further restricts the key to 
> be formed like a Java identifier.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Updated] (QPIDJMS-312) Exception is not thrown when user attempts to create context with invalid session mode value

2017-08-09 Thread Timothy Bish (JIRA)

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

Timothy Bish updated QPIDJMS-312:
-
Affects Version/s: (was: 0.23.0)
   0.24.0

> Exception is not thrown when user attempts to create context with invalid 
> session mode value
> 
>
> Key: QPIDJMS-312
> URL: https://issues.apache.org/jira/browse/QPIDJMS-312
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.24.0
>Reporter: Jiri Danek
>Priority: Trivial
>
> Consider Apache ActiveMQ Artemis tests 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.JmsContextTest#testInvalidSessionModesValueMinusOne}}
>  and {{#testInvalidSessionModesValue4}} (in the same class).
> When it is adapted to run with multiple JMS clients, or when run from the 
> standalone reproducer at 
> https://github.com/jdanekrh/jms-reproducers/blob/master/src/test/java/org/apache/activemq/artemis/tests/integration/jms/jms2client/JmsContextTest.java
> (the standalone reproducer requires a running broker to connect to), the test 
> passes with Core, is skipped on OpenWire (because that is not a JMS 2.0 
> client) and fails on AMQP protocol (with qpid-jms-client as the JMS library):
> {noformat}
>@Test(expected = JMSRuntimeException.class)
>public void testInvalidSessionModesValueMinusOne() {
>   context.createContext(-1);
>}
>@Test(expected = JMSRuntimeException.class)
>public void testInvalidSessionModesValue4() {
>   context.createContext(4);
>}
> {noformat}
> with exception
> {noformat}
> java.lang.AssertionError: Expected exception: 
> javax.jms.JMSRuntimeException
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (QPIDJMS-312) Exception is not thrown when user attempts to create context with invalid session mode value

2017-08-09 Thread ASF subversion and git services (JIRA)

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

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

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

QPIDJMS-312 Add check for session mode range

Update JmsContext with missing check for session mode range

> Exception is not thrown when user attempts to create context with invalid 
> session mode value
> 
>
> Key: QPIDJMS-312
> URL: https://issues.apache.org/jira/browse/QPIDJMS-312
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.24.0
>Reporter: Jiri Danek
>Priority: Trivial
> Fix For: 0.25.0
>
>
> Consider Apache ActiveMQ Artemis tests 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.JmsContextTest#testInvalidSessionModesValueMinusOne}}
>  and {{#testInvalidSessionModesValue4}} (in the same class).
> When it is adapted to run with multiple JMS clients, or when run from the 
> standalone reproducer at 
> https://github.com/jdanekrh/jms-reproducers/blob/master/src/test/java/org/apache/activemq/artemis/tests/integration/jms/jms2client/JmsContextTest.java
> (the standalone reproducer requires a running broker to connect to), the test 
> passes with Core, is skipped on OpenWire (because that is not a JMS 2.0 
> client) and fails on AMQP protocol (with qpid-jms-client as the JMS library):
> {noformat}
>@Test(expected = JMSRuntimeException.class)
>public void testInvalidSessionModesValueMinusOne() {
>   context.createContext(-1);
>}
>@Test(expected = JMSRuntimeException.class)
>public void testInvalidSessionModesValue4() {
>   context.createContext(4);
>}
> {noformat}
> with exception
> {noformat}
> java.lang.AssertionError: Expected exception: 
> javax.jms.JMSRuntimeException
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Resolved] (QPIDJMS-312) Exception is not thrown when user attempts to create context with invalid session mode value

2017-08-09 Thread Timothy Bish (JIRA)

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

Timothy Bish resolved QPIDJMS-312.
--
   Resolution: Fixed
 Assignee: Timothy Bish
Fix Version/s: 0.25.0

> Exception is not thrown when user attempts to create context with invalid 
> session mode value
> 
>
> Key: QPIDJMS-312
> URL: https://issues.apache.org/jira/browse/QPIDJMS-312
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.24.0
>Reporter: Jiri Danek
>Assignee: Timothy Bish
>Priority: Trivial
> Fix For: 0.25.0
>
>
> Consider Apache ActiveMQ Artemis tests 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.JmsContextTest#testInvalidSessionModesValueMinusOne}}
>  and {{#testInvalidSessionModesValue4}} (in the same class).
> When it is adapted to run with multiple JMS clients, or when run from the 
> standalone reproducer at 
> https://github.com/jdanekrh/jms-reproducers/blob/master/src/test/java/org/apache/activemq/artemis/tests/integration/jms/jms2client/JmsContextTest.java
> (the standalone reproducer requires a running broker to connect to), the test 
> passes with Core, is skipped on OpenWire (because that is not a JMS 2.0 
> client) and fails on AMQP protocol (with qpid-jms-client as the JMS library):
> {noformat}
>@Test(expected = JMSRuntimeException.class)
>public void testInvalidSessionModesValueMinusOne() {
>   context.createContext(-1);
>}
>@Test(expected = JMSRuntimeException.class)
>public void testInvalidSessionModesValue4() {
>   context.createContext(4);
>}
> {noformat}
> with exception
> {noformat}
> java.lang.AssertionError: Expected exception: 
> javax.jms.JMSRuntimeException
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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



[jira] [Commented] (PROTON-1519) qpid_proton 0.17.0 Ruby gem does not work with Ruby 2.4.1

2017-08-09 Thread Alan Conway (JIRA)

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

Alan Conway commented on PROTON-1519:
-

Thanks for this - just back from vacation hence late response. Will get your PR 
in and take a look at travis setup - you are correct that it was never properly 
set up for ruby version tests.

> qpid_proton 0.17.0 Ruby gem does not work with Ruby 2.4.1
> -
>
> Key: PROTON-1519
> URL: https://issues.apache.org/jira/browse/PROTON-1519
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Affects Versions: 0.17.0
> Environment: Ruby 2.4.1 on macOS Sierra 10.12.5
>Reporter: Jason Frey
>Assignee: Justin Ross
>  Labels: patch
>
> qpid_proton 0.17.0 was built successfully from source with
> {code}
> > cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DLIB_INSTALL_DIR=/usr/local/lib
> > make install
> {code}
> Installing the gem with Ruby 2.4.1 from rubygems.org was successful
> {code}
> > gem install qpid_proton
> Building native extensions.  This could take a while...
> Successfully installed qpid_proton-0.17.0
> 1 gem installed
> {code}
> However, using the gem fails with: "RuntimeError: entry exists for Integer"
> {code}
> > irb
> [1] pry(main)> RUBY_DESCRIPTION
> => "ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin15]"
> [2] pry(main)> require 'qpid_proton'
> /Users/jfrey/.gem/ruby/2.4.1/gems/qpid_proton-0.17.0/lib/codec/mapping.rb:99: 
> warning: constant ::Fixnum is deprecated
> /Users/jfrey/.gem/ruby/2.4.1/gems/qpid_proton-0.17.0/lib/codec/mapping.rb:99: 
> warning: constant ::Bignum is deprecated
> RuntimeError: entry exists for Integer
> from (qpid_proton-0.17.0) lib/codec/mapping.rb:55:in `block in initialize'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:54:in `each'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:54:in `initialize'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:99:in `new'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:99:in `'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:20:in `'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in 
> `require'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in 
> `require'
> (qpid_proton-0.17.0) lib/qpid_proton.rb:54:in `'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:133:in 
> `require'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:133:in 
> `rescue in require'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:40:in 
> `require'
> (pry):1:in `'
> {code}
> Note that the above steps are all successful with Ruby 2.3.3
> {code}
> > irb
> [1] pry(main)> RUBY_DESCRIPTION
> => "ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-darwin15]"
> [2] pry(main)> require 'qpid_proton'
> => true
> [3] pry(main)> Qpid::Proton
> => Qpid::Proton
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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