[jira] [Commented] (QPIDJMS-332) enable defining destination names in tomcat resource definitions

[Bernhard Seidl (JIRA)]

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

Bernhard Seidl commented on QPIDJMS-332:


The snapshot works like charm. Thx

> enable defining destination names in tomcat resource definitions
> 
>
> Key: QPIDJMS-332
> URL: https://issues.apache.org/jira/browse/QPIDJMS-332
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Bernhard Seidl
>Assignee: Robbie Gemmell
> Fix For: 0.26.0
>
>
> Since a few days i am trying to define a queue resource in Tomcat's 
> context.xml. The attribute "name" defines the jndi name. Looking at 
> org.apache.qpid.jms.JmsDestination 
> the attribute is called "name", too. This seems to me as a  naming conflict. 
> I tried to use  the attribute "physicalName" due to the fact that some of the 
> classes are based on ActiveMQ. However I am not sure if I am missing a point 
> somewhere else:
> This is my setup:
> Context.xml
> {code:xml}
>type="org.apache.qpid.jms.JmsConnectionFactory" 
> factory="org.apache.qpid.jms.jndi.JNDIReferenceFactory"
>   remoteURI="amqp://10.10.10.1:5672" username="a" password="a"
>   maxPoolSize="20" connectionTimeout="6" />
>  type="org.apache.qpid.jms.JmsQueue" 
> factory="org.apache.qpid.jms.jndi.JNDIReferenceFactory"
>   physicalName="name"/>
> {code}
> Init-code using spring:
> {code:java}
> @Configuration
> @EnableJms
> public class MessagingConfiguration {
>   @Bean
>   public ConnectionFactory connectionFactory() throws NamingException {
>   ConnectionFactory connectionFactory =  (new JndiTemplate())
>   
> .lookup("java:/comp/env/jms/ConnectionFactory",ConnectionFactory.class);
>   return connectionFactory;
>   }
>   
>   @Bean
>   public DestinationResolver destinationResolver() {
>   JndiDestinationResolver jdr = new JndiDestinationResolver();
>   try {
>   // testing
>   Queue q = 
> jdr.getJndiTemplate().lookup("java:/comp/env/jms/queue", Queue.class);
>   System.out.println("A: " + q.getQueueName());
>   System.out.println("B: " + (new 
> JndiTemplate()).lookup("java:/comp/env/jms/queue", 
> Destination.class).getClass());
>   } catch (Exception e) {
>   // TODO Auto-generated catch block
>   e.printStackTrace();
>   }
>   return jdr; 
>   }
>   @Bean
>   public JmsTemplate jmsTemplate() throws NamingException {
>   JmsTemplate template = new JmsTemplate();
>   template.setConnectionFactory(connectionFactory());
>   template.setDestinationResolver(destinationResolver());
>   return template;
>   }
> }
> {code}
> Running the code prints out:
> {noformat}
> ...
> A:
> B: class org.apache.qpid.jms.JmsQueue
> {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-1609) build C examples with c90 flag for older compilers

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1609: build C examples with c90 flag for older compilers

- Get rid of // comments in public header files, not allowed in c90
- Simplify/clarify cmake variables exported from proton-c/CMakeLists for 
examples
- Set -std=c90 for gcc/clang example builds
- Fix examples to build with c90 - // comments and variable declarations in 
front


> build C examples with c90 flag for older compilers
> --
>
> Key: PROTON-1609
> URL: https://issues.apache.org/jira/browse/PROTON-1609
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: examples
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> The main proton library requires a c99 compiler (actually the overlap of c90 
> and c++03) but the examples should compile with c90 to ensure they work with 
> older compiolers.
> Fix CMakeLists to use the -std=c90 flag for examples with clang and gcc 
> compilers, to get early warning of c90-incompatible code in the examples.



--
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-1609) build C examples with c90 flag for older compilers

[Alan Conway (JIRA)]

Alan Conway created PROTON-1609:
---

 Summary: build C examples with c90 flag for older compilers
 Key: PROTON-1609
 URL: https://issues.apache.org/jira/browse/PROTON-1609
 Project: Qpid Proton
  Issue Type: Improvement
  Components: examples
Affects Versions: 0.17.0
Reporter: Alan Conway
Assignee: Alan Conway
 Fix For: proton-c-0.18.0


The main proton library requires a c99 compiler (actually the overlap of c90 
and c++03) but the examples should compile with c90 to ensure they work with 
older compiolers.

Fix CMakeLists to use the -std=c90 flag for examples with clang and gcc 
compilers, to get early warning of c90-incompatible code in the examples.



--
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] (QPIDIT-96) Improvements in Java component management

[Kim van der Riet (JIRA)]

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

Kim van der Riet resolved QPIDIT-96.

Resolution: Fixed

> Improvements in Java component management
> -
>
> Key: QPIDIT-96
> URL: https://issues.apache.org/jira/browse/QPIDIT-96
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Improvement
>  Components: Installation
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>
> Robbie Gemmell has pointed out that there are some issues around handling of 
> the Java components in the pom files, also in the QUICKSTART.md instructions.
> The instructions should not instruct the local build of qpid-jms, rather rely 
> on Maven to find the artifacts it needs.
> The dependencies in the jms shim pom file should be moved to the project pom 
> file, and use properties to define the version numbers, this allows for the 
> versions of artifacts to be modified from the command-line.



--
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-1512) Expose the "aborted" flag for transferred deliveries

[Alan Conway (JIRA)]

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

Alan Conway resolved PROTON-1512.
-
Resolution: Fixed

> Expose the "aborted" flag for transferred deliveries
> 
>
> Key: PROTON-1512
> URL: https://issues.apache.org/jira/browse/PROTON-1512
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-c
>Reporter: Ted Ross
>Assignee: Alan Conway
>  Labels: api
> Fix For: proton-c-0.18.0
>
>
> As we develop support for message streaming in Qpid Dispatch Router (i.e. 
> frames for large multi-frame messages are forwarded to destinations as they 
> arrive, before the complete message is received), there is a need to handle 
> the case where a received message is never completed.
> The AMQP protocol has a provision for this in the "aborted" flag in the 
> transfer performative.  If the router is in the process of streaming a large 
> message from sender to receiver and the sender drops before completing the 
> delivery, the router can send a transfer to the downstream receivers with the 
> "aborted" flag set.  This would indicate that the message should not be 
> processed and would not cause any framing errors on the link.
> Proton does not currently expose this capability in its API (There is a 
> pn_link_abort in the C header file, but it is commented out and not 
> implemented).
> In order to properly handle the failure cases for message streaming, this 
> feature must be usable in Proton.



--
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-1560) Cannot install qpid_proton-0.18.0.gem

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1560: ruby: fix cmake test names


> Cannot install qpid_proton-0.18.0.gem
> -
>
> Key: PROTON-1560
> URL: https://issues.apache.org/jira/browse/PROTON-1560
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> Snapshot of master at commit 8c3ba5.
> When using these specific flags, compilation fails:
> CONFIGURE_ARGS='--with-cflags='\''-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
> -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 
> -grecord-gcc-switches   -m64 -mtune=generic'\'' '
> + gem install -V --local --install-dir ./usr/share/gems --bindir ./usr/bin 
> --force --document=ri,rdoc qpid_proton-0.18.0.gem
> 
> gcc -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I. 
> -DHAVE_PROTON_ENGINE_H -DHAVE_PROTON_MESSAGE_H -DHAVE_PROTON_SASL_H 
> -DHAVE_PROTON_MESSENGER_H-fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
> -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 
> -grecord-gcc-switches   -m64 -mtune=generic -DRUBY20 -m64 -o cproton.o -c 
> cproton.c
> Linked Applications
> JBoss Issue Tracker
> Dashboards
> Projects
> Issues
> Boards
> Portfolio
> Create
> Help
> Administration
> User profile for Alan Conway
> AMQ ClientsIcon indicating the project type
> AMQ Clients
> A-MQ Clients
> Backlog
> Active sprints
> Releases
> Reports
> Issues
> Components
> Uploaded image for project: 'AMQ Clients'
> AMQ ClientsENTMQCL-530
> Cannot install qpid_proton-0.18.0.gem
> Edit
> Comment
> Assign
> More
> Ready for Dev
> Closed
> Export
> Details
> Type:
> Task
> Status:
> Ready for Triage (View Workflow)
> Priority:
> Major
> Resolution:
> Unresolved
> Affects Version/s:
> Future GA
> Fix Version/s:
> None
> Component/s:
> proton-c
> Labels:
> None
> Environment:
> RHEL 7, RPM Build
> Description
> Snapshot of master at commit 8c3ba5.
> When using these specific flags, compilation fails:
> CONFIGURE_ARGS='--with-cflags='\''-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
> -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 
> -grecord-gcc-switches -m64 -mtune=generic'\'' '
> + gem install -V --local --install-dir ./usr/share/gems --bindir ./usr/bin 
> --force --document=ri,rdoc qpid_proton-0.18.0.gem
> 
> gcc -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I. 
> -DHAVE_PROTON_ENGINE_H -DHAVE_PROTON_MESSAGE_H -DHAVE_PROTON_SASL_H 
> -DHAVE_PROTON_MESSENGER_H -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
> -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 
> -grecord-gcc-switches -m64 -mtune=generic -DRUBY20 -m64 -o cproton.o -c 
> cproton.c
> 
> cproton.c:6540:12: warning: 'check_trace' defined but not used 
> [-Wunused-function]
> static int check_trace(int x) {
> ^
> make: *** [cproton.o] Error 1
> ERROR: Error installing qpid_proton-0.18.0.gem:
> ERROR: Failed to build gem native extension.
> Building has failed. See above output for more information on the failure.
> Attachments
> Drop files to attach, or
> Activity
> All
> Comments
> Work Log
> History
> Activity
> Links Hierarchy
> Linked Cases
> There are no comments yet on this issue.
> Comment
> People
> Assignee:
> aconway Alan Conway 
> Reporter:
> iboverma Irina Boverman 
> Votes:
> 0 Vote for this issue 
> Watchers:
> 1
> Start watching this issue 
> Dates
> Created:
> 4 days ago 
> Updated:
> 2 days ago 
> Agile
> View on Board
> 
> cproton.c:6540:12: warning: 'check_trace' defined but not used 
> [-Wunused-function]
>  static int check_trace(int x) {
> ^
> make: *** [cproton.o] Error 1
> ERROR:  Error installing qpid_proton-0.18.0.gem:
> ERROR: Failed to build gem native extension.
> Building has failed. See above output for more information on the failure.



--
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-1512) Expose the "aborted" flag for transferred deliveries

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1512: aborted messages: handle credit and empty messages.

The AMQP spec says: "The delivery-count is initialized by the sender when a link
endpoint is created, and is incremented whenever a message is sent."
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-flow-control

We interpret this to mean when the *first* frame of a message is sent/received,
so if any frames of an aborted message are sent, it consumes a credit and
increases the delivery count exactly like a successful message.

However: if a proton sender calls pn_delivery_abort() *before* any frames have
been sent, the delivery is dropped locally, no frames sent, no link-state
updates. This means pn_delivery_abort() will either cancel a local,
partially-constructed message with no side effects, or send an aborted=true
frame as required. Proton will never send a message consisting of a single
aborted frame.

A proton receiver will handle a message consisting of a single aborted frame
correctly - i.e. do credit calculations but consider the delivery aborted.


> Expose the "aborted" flag for transferred deliveries
> 
>
> Key: PROTON-1512
> URL: https://issues.apache.org/jira/browse/PROTON-1512
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-c
>Reporter: Ted Ross
>Assignee: Alan Conway
>  Labels: api
> Fix For: proton-c-0.18.0
>
>
> As we develop support for message streaming in Qpid Dispatch Router (i.e. 
> frames for large multi-frame messages are forwarded to destinations as they 
> arrive, before the complete message is received), there is a need to handle 
> the case where a received message is never completed.
> The AMQP protocol has a provision for this in the "aborted" flag in the 
> transfer performative.  If the router is in the process of streaming a large 
> message from sender to receiver and the sender drops before completing the 
> delivery, the router can send a transfer to the downstream receivers with the 
> "aborted" flag set.  This would indicate that the message should not be 
> processed and would not cause any framing errors on the link.
> Proton does not currently expose this capability in its API (There is a 
> pn_link_abort in the C header file, but it is commented out and not 
> implemented).
> In order to properly handle the failure cases for message streaming, this 
> feature must be usable in Proton.



--
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-846) Memory leaks in ctest with valgrind

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-846: Fix leak in qd_server_connection


> Memory leaks in ctest with valgrind
> ---
>
> Key: DISPATCH-846
> URL: https://issues.apache.org/jira/browse/DISPATCH-846
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Alan Conway
>Assignee: Ted Ross
> Fix For: 0.8.1, 1.0.0
>
>
> There are several memory leaks reported by ctest with valigrind, example 
> below. The exact set of leaks is not always the same, so there is probably a 
> race condition involved, but I get some leaks on pretty much every run.
> Aside: we stared using the gcc/clang sanitizers with proton, they require 
> special build flags but are *way* faster than valgrind's memcheck/helgrind 
> with similar error-detection.
> {code}
> make && ctest 
> [ 70%] Built target qpid-dispatch
> [ 78%] Built target unit_tests_size
> [ 85%] Built target qdrouterd
> [ 93%] Built target unit_tests
> [100%] Built target doc_gen
> Test project /home/aconway/dispatch/reldbg
>   Start  1: unit_tests_size_1
>  1/35 Test  #1: unit_tests_size_1 .   Passed1.18 
> sec
>   Start  2: unit_tests_size_512
>  2/35 Test  #2: unit_tests_size_512 ...   Passed1.14 
> sec
>   Start  3: unit_tests_size_10
>  3/35 Test  #3: unit_tests_size_10    Passed1.18 
> sec
>   Start  4: unit_tests_size_7
>  4/35 Test  #4: unit_tests_size_7 .   Passed1.13 
> sec
>   Start  5: unit_tests_size_5
>  5/35 Test  #5: unit_tests_size_5 .   Passed1.21 
> sec
>   Start  6: unit_tests_size_3
>  6/35 Test  #6: unit_tests_size_3 .   Passed1.20 
> sec
>   Start  7: unit_tests_size_2
>  7/35 Test  #7: unit_tests_size_2 .   Passed1.20 
> sec
>   Start  8: unit_tests_size_1
>  8/35 Test  #8: unit_tests_size_1 .   Passed1.15 
> sec
>   Start  9: unit_tests
>  9/35 Test  #9: unit_tests    Passed4.47 
> sec
>   Start 10: router_engine_test
> 10/35 Test #10: router_engine_test    Passed0.05 
> sec
>   Start 11: management_test
> 11/35 Test #11: management_test ...   Passed0.04 
> sec
>   Start 12: router_policy_test
> 12/35 Test #12: router_policy_test    Passed0.10 
> sec
>   Start 13: system_tests_link_routes
> 13/35 Test #13: system_tests_link_routes ..***Failed   24.66 
> sec
> test_aaa_qdmanage_query_link_route (system_tests_link_routes.LinkRouteTest) 
> ... ok
> test_bbb_qdstat_link_routes_routerB (system_tests_link_routes.LinkRouteTest) 
> ... FAIL
> test_ccc_qdstat_link_routes_routerC (system_tests_link_routes.LinkRouteTest) 
> ... ok
> test_close_with_unsettled (system_tests_link_routes.LinkRouteTest) ... ok
> test_custom_annotations_match (system_tests_link_routes.LinkRouteTest) ... ok
> test_ddd_partial_link_route_match (system_tests_link_routes.LinkRouteTest) 
> ... ok
> test_detach_mixed_close (system_tests_link_routes.LinkRouteTest) ... ok
> test_detach_without_close (system_tests_link_routes.LinkRouteTest) ... ok
> test_dynamic_source (system_tests_link_routes.LinkRouteTest) ... ok
> test_dynamic_target (system_tests_link_routes.LinkRouteTest) ... ok
> test_full_link_route_match (system_tests_link_routes.LinkRouteTest) ... ok
> test_full_link_route_match_1 (system_tests_link_routes.LinkRouteTest) ... ok
> test_link_route_pattern_match (system_tests_link_routes.LinkRouteTest) ... ok
> test_link_route_terminus_address (system_tests_link_routes.LinkRouteTest) ... 
> ok
> test_partial_link_route_match_1 (system_tests_link_routes.LinkRouteTest) ... 
> ok
> test_www_drain_support_all_messages (system_tests_link_routes.LinkRouteTest) 
> ... ok
> test_www_drain_support_no_messages (system_tests_link_routes.LinkRouteTest) 
> ... ok
> test_www_drain_support_no_more_messages 
> (system_tests_link_routes.LinkRouteTest) ... ok
> test_www_drain_support_one_message (system_tests_link_routes.LinkRouteTest) 
> ... ok
> test_yyy_delivery_tag (system_tests_link_routes.LinkRouteTest) ... ok
> test_zzz_qdmanage_delete_link_route (system_tests_link_routes.LinkRouteTest) 
> ... FAIL
> ERROR
> ==
> 

[jira] [Commented] (DISPATCH-846) Memory leaks in ctest with valgrind

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-846: Fix memory leak in router config.

qd_dispatch_set_router_default_distribution() was not freeing its argument.

Also removed some other dispatch.c private configuration functions from
dispatch-private.h and made them static.


> Memory leaks in ctest with valgrind
> ---
>
> Key: DISPATCH-846
> URL: https://issues.apache.org/jira/browse/DISPATCH-846
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Alan Conway
>Assignee: Ted Ross
> Fix For: 0.8.1, 1.0.0
>
>
> There are several memory leaks reported by ctest with valigrind, example 
> below. The exact set of leaks is not always the same, so there is probably a 
> race condition involved, but I get some leaks on pretty much every run.
> Aside: we stared using the gcc/clang sanitizers with proton, they require 
> special build flags but are *way* faster than valgrind's memcheck/helgrind 
> with similar error-detection.
> {code}
> make && ctest 
> [ 70%] Built target qpid-dispatch
> [ 78%] Built target unit_tests_size
> [ 85%] Built target qdrouterd
> [ 93%] Built target unit_tests
> [100%] Built target doc_gen
> Test project /home/aconway/dispatch/reldbg
>   Start  1: unit_tests_size_1
>  1/35 Test  #1: unit_tests_size_1 .   Passed1.18 
> sec
>   Start  2: unit_tests_size_512
>  2/35 Test  #2: unit_tests_size_512 ...   Passed1.14 
> sec
>   Start  3: unit_tests_size_10
>  3/35 Test  #3: unit_tests_size_10    Passed1.18 
> sec
>   Start  4: unit_tests_size_7
>  4/35 Test  #4: unit_tests_size_7 .   Passed1.13 
> sec
>   Start  5: unit_tests_size_5
>  5/35 Test  #5: unit_tests_size_5 .   Passed1.21 
> sec
>   Start  6: unit_tests_size_3
>  6/35 Test  #6: unit_tests_size_3 .   Passed1.20 
> sec
>   Start  7: unit_tests_size_2
>  7/35 Test  #7: unit_tests_size_2 .   Passed1.20 
> sec
>   Start  8: unit_tests_size_1
>  8/35 Test  #8: unit_tests_size_1 .   Passed1.15 
> sec
>   Start  9: unit_tests
>  9/35 Test  #9: unit_tests    Passed4.47 
> sec
>   Start 10: router_engine_test
> 10/35 Test #10: router_engine_test    Passed0.05 
> sec
>   Start 11: management_test
> 11/35 Test #11: management_test ...   Passed0.04 
> sec
>   Start 12: router_policy_test
> 12/35 Test #12: router_policy_test    Passed0.10 
> sec
>   Start 13: system_tests_link_routes
> 13/35 Test #13: system_tests_link_routes ..***Failed   24.66 
> sec
> test_aaa_qdmanage_query_link_route (system_tests_link_routes.LinkRouteTest) 
> ... ok
> test_bbb_qdstat_link_routes_routerB (system_tests_link_routes.LinkRouteTest) 
> ... FAIL
> test_ccc_qdstat_link_routes_routerC (system_tests_link_routes.LinkRouteTest) 
> ... ok
> test_close_with_unsettled (system_tests_link_routes.LinkRouteTest) ... ok
> test_custom_annotations_match (system_tests_link_routes.LinkRouteTest) ... ok
> test_ddd_partial_link_route_match (system_tests_link_routes.LinkRouteTest) 
> ... ok
> test_detach_mixed_close (system_tests_link_routes.LinkRouteTest) ... ok
> test_detach_without_close (system_tests_link_routes.LinkRouteTest) ... ok
> test_dynamic_source (system_tests_link_routes.LinkRouteTest) ... ok
> test_dynamic_target (system_tests_link_routes.LinkRouteTest) ... ok
> test_full_link_route_match (system_tests_link_routes.LinkRouteTest) ... ok
> test_full_link_route_match_1 (system_tests_link_routes.LinkRouteTest) ... ok
> test_link_route_pattern_match (system_tests_link_routes.LinkRouteTest) ... ok
> test_link_route_terminus_address (system_tests_link_routes.LinkRouteTest) ... 
> ok
> test_partial_link_route_match_1 (system_tests_link_routes.LinkRouteTest) ... 
> ok
> test_www_drain_support_all_messages (system_tests_link_routes.LinkRouteTest) 
> ... ok
> test_www_drain_support_no_messages (system_tests_link_routes.LinkRouteTest) 
> ... ok
> test_www_drain_support_no_more_messages 
> (system_tests_link_routes.LinkRouteTest) ... ok
> test_www_drain_support_one_message (system_tests_link_routes.LinkRouteTest) 
> ... ok
> test_yyy_delivery_tag 

[jira] [Assigned] (DISPATCH-846) Memory leaks in ctest with valgrind

[Alan Conway (JIRA)]

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

Alan Conway reassigned DISPATCH-846:


Assignee: Ted Ross

> Memory leaks in ctest with valgrind
> ---
>
> Key: DISPATCH-846
> URL: https://issues.apache.org/jira/browse/DISPATCH-846
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Alan Conway
>Assignee: Ted Ross
> Fix For: 0.8.1, 1.0.0
>
>
> There are several memory leaks reported by ctest with valigrind, example 
> below. The exact set of leaks is not always the same, so there is probably a 
> race condition involved, but I get some leaks on pretty much every run.
> Aside: we stared using the gcc/clang sanitizers with proton, they require 
> special build flags but are *way* faster than valgrind's memcheck/helgrind 
> with similar error-detection.
> {code}
> make && ctest 
> [ 70%] Built target qpid-dispatch
> [ 78%] Built target unit_tests_size
> [ 85%] Built target qdrouterd
> [ 93%] Built target unit_tests
> [100%] Built target doc_gen
> Test project /home/aconway/dispatch/reldbg
>   Start  1: unit_tests_size_1
>  1/35 Test  #1: unit_tests_size_1 .   Passed1.18 
> sec
>   Start  2: unit_tests_size_512
>  2/35 Test  #2: unit_tests_size_512 ...   Passed1.14 
> sec
>   Start  3: unit_tests_size_10
>  3/35 Test  #3: unit_tests_size_10    Passed1.18 
> sec
>   Start  4: unit_tests_size_7
>  4/35 Test  #4: unit_tests_size_7 .   Passed1.13 
> sec
>   Start  5: unit_tests_size_5
>  5/35 Test  #5: unit_tests_size_5 .   Passed1.21 
> sec
>   Start  6: unit_tests_size_3
>  6/35 Test  #6: unit_tests_size_3 .   Passed1.20 
> sec
>   Start  7: unit_tests_size_2
>  7/35 Test  #7: unit_tests_size_2 .   Passed1.20 
> sec
>   Start  8: unit_tests_size_1
>  8/35 Test  #8: unit_tests_size_1 .   Passed1.15 
> sec
>   Start  9: unit_tests
>  9/35 Test  #9: unit_tests    Passed4.47 
> sec
>   Start 10: router_engine_test
> 10/35 Test #10: router_engine_test    Passed0.05 
> sec
>   Start 11: management_test
> 11/35 Test #11: management_test ...   Passed0.04 
> sec
>   Start 12: router_policy_test
> 12/35 Test #12: router_policy_test    Passed0.10 
> sec
>   Start 13: system_tests_link_routes
> 13/35 Test #13: system_tests_link_routes ..***Failed   24.66 
> sec
> test_aaa_qdmanage_query_link_route (system_tests_link_routes.LinkRouteTest) 
> ... ok
> test_bbb_qdstat_link_routes_routerB (system_tests_link_routes.LinkRouteTest) 
> ... FAIL
> test_ccc_qdstat_link_routes_routerC (system_tests_link_routes.LinkRouteTest) 
> ... ok
> test_close_with_unsettled (system_tests_link_routes.LinkRouteTest) ... ok
> test_custom_annotations_match (system_tests_link_routes.LinkRouteTest) ... ok
> test_ddd_partial_link_route_match (system_tests_link_routes.LinkRouteTest) 
> ... ok
> test_detach_mixed_close (system_tests_link_routes.LinkRouteTest) ... ok
> test_detach_without_close (system_tests_link_routes.LinkRouteTest) ... ok
> test_dynamic_source (system_tests_link_routes.LinkRouteTest) ... ok
> test_dynamic_target (system_tests_link_routes.LinkRouteTest) ... ok
> test_full_link_route_match (system_tests_link_routes.LinkRouteTest) ... ok
> test_full_link_route_match_1 (system_tests_link_routes.LinkRouteTest) ... ok
> test_link_route_pattern_match (system_tests_link_routes.LinkRouteTest) ... ok
> test_link_route_terminus_address (system_tests_link_routes.LinkRouteTest) ... 
> ok
> test_partial_link_route_match_1 (system_tests_link_routes.LinkRouteTest) ... 
> ok
> test_www_drain_support_all_messages (system_tests_link_routes.LinkRouteTest) 
> ... ok
> test_www_drain_support_no_messages (system_tests_link_routes.LinkRouteTest) 
> ... ok
> test_www_drain_support_no_more_messages 
> (system_tests_link_routes.LinkRouteTest) ... ok
> test_www_drain_support_one_message (system_tests_link_routes.LinkRouteTest) 
> ... ok
> test_yyy_delivery_tag (system_tests_link_routes.LinkRouteTest) ... ok
> test_zzz_qdmanage_delete_link_route (system_tests_link_routes.LinkRouteTest) 
> ... FAIL
> ERROR
> ==
> ERROR: tearDownClass (system_tests_link_routes.LinkRouteTest)
> --
> Traceback (most recent call last):
>   File "/home/aconway/dispatch/tests/system_test.py", line 606, in 
> tearDownClass
> cls.tester.teardown()

[jira] [Created] (DISPATCH-846) Memory leaks in ctest with valgrind

[Alan Conway (JIRA)]

Alan Conway created DISPATCH-846:


 Summary: Memory leaks in ctest with valgrind
 Key: DISPATCH-846
 URL: https://issues.apache.org/jira/browse/DISPATCH-846
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Container
Affects Versions: 0.8.0
Reporter: Alan Conway
 Fix For: 0.8.1, 1.0.0


There are several memory leaks reported by ctest with valigrind, example below. 
The exact set of leaks is not always the same, so there is probably a race 
condition involved, but I get some leaks on pretty much every run.

Aside: we stared using the gcc/clang sanitizers with proton, they require 
special build flags but are *way* faster than valgrind's memcheck/helgrind with 
similar error-detection.

{code}
make && ctest 
[ 70%] Built target qpid-dispatch
[ 78%] Built target unit_tests_size
[ 85%] Built target qdrouterd
[ 93%] Built target unit_tests
[100%] Built target doc_gen
Test project /home/aconway/dispatch/reldbg
  Start  1: unit_tests_size_1
 1/35 Test  #1: unit_tests_size_1 .   Passed1.18 sec
  Start  2: unit_tests_size_512
 2/35 Test  #2: unit_tests_size_512 ...   Passed1.14 sec
  Start  3: unit_tests_size_10
 3/35 Test  #3: unit_tests_size_10    Passed1.18 sec
  Start  4: unit_tests_size_7
 4/35 Test  #4: unit_tests_size_7 .   Passed1.13 sec
  Start  5: unit_tests_size_5
 5/35 Test  #5: unit_tests_size_5 .   Passed1.21 sec
  Start  6: unit_tests_size_3
 6/35 Test  #6: unit_tests_size_3 .   Passed1.20 sec
  Start  7: unit_tests_size_2
 7/35 Test  #7: unit_tests_size_2 .   Passed1.20 sec
  Start  8: unit_tests_size_1
 8/35 Test  #8: unit_tests_size_1 .   Passed1.15 sec
  Start  9: unit_tests
 9/35 Test  #9: unit_tests    Passed4.47 sec
  Start 10: router_engine_test
10/35 Test #10: router_engine_test    Passed0.05 sec
  Start 11: management_test
11/35 Test #11: management_test ...   Passed0.04 sec
  Start 12: router_policy_test
12/35 Test #12: router_policy_test    Passed0.10 sec
  Start 13: system_tests_link_routes
13/35 Test #13: system_tests_link_routes ..***Failed   24.66 sec
test_aaa_qdmanage_query_link_route (system_tests_link_routes.LinkRouteTest) ... 
ok
test_bbb_qdstat_link_routes_routerB (system_tests_link_routes.LinkRouteTest) 
... FAIL
test_ccc_qdstat_link_routes_routerC (system_tests_link_routes.LinkRouteTest) 
... ok
test_close_with_unsettled (system_tests_link_routes.LinkRouteTest) ... ok
test_custom_annotations_match (system_tests_link_routes.LinkRouteTest) ... ok
test_ddd_partial_link_route_match (system_tests_link_routes.LinkRouteTest) ... 
ok
test_detach_mixed_close (system_tests_link_routes.LinkRouteTest) ... ok
test_detach_without_close (system_tests_link_routes.LinkRouteTest) ... ok
test_dynamic_source (system_tests_link_routes.LinkRouteTest) ... ok
test_dynamic_target (system_tests_link_routes.LinkRouteTest) ... ok
test_full_link_route_match (system_tests_link_routes.LinkRouteTest) ... ok
test_full_link_route_match_1 (system_tests_link_routes.LinkRouteTest) ... ok
test_link_route_pattern_match (system_tests_link_routes.LinkRouteTest) ... ok
test_link_route_terminus_address (system_tests_link_routes.LinkRouteTest) ... ok
test_partial_link_route_match_1 (system_tests_link_routes.LinkRouteTest) ... ok
test_www_drain_support_all_messages (system_tests_link_routes.LinkRouteTest) 
... ok
test_www_drain_support_no_messages (system_tests_link_routes.LinkRouteTest) ... 
ok
test_www_drain_support_no_more_messages 
(system_tests_link_routes.LinkRouteTest) ... ok
test_www_drain_support_one_message (system_tests_link_routes.LinkRouteTest) ... 
ok
test_yyy_delivery_tag (system_tests_link_routes.LinkRouteTest) ... ok
test_zzz_qdmanage_delete_link_route (system_tests_link_routes.LinkRouteTest) 
... FAIL
ERROR

==
ERROR: tearDownClass (system_tests_link_routes.LinkRouteTest)
--
Traceback (most recent call last):
  File "/home/aconway/dispatch/tests/system_test.py", line 606, in tearDownClass
cls.tester.teardown()
  File "/home/aconway/dispatch/tests/system_test.py", line 544, in teardown
raise RuntimeError("Errors during teardown: \n\n%s" % "\n\n".join([str(e) 
for e in errors]))
RuntimeError: Errors during teardown: 

Process 30360 error: exit code 42, expected 0
qdrouterd -c D.conf -I /home/aconway/dispatch/python

[jira] [Commented] (DISPATCH-845) Allow connecting containers to declare their availability for link routes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-845:
-

Github user ted-ross commented on the issue:

https://github.com/apache/qpid-dispatch/pull/204
  
Note that this feature is targeted at the 1.1.0 release.


> Allow connecting containers to declare their availability for link routes
> -
>
> Key: DISPATCH-845
> URL: https://issues.apache.org/jira/browse/DISPATCH-845
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 1.1.0
>
>
> In the case where a container wishes to connect to a router network and 
> accept incoming routed link attaches (i.e. become a destination for link 
> routes), it is now quite complicated to do so.  First, the connected router 
> must be configured with a listener in the route-container role.  Second, 
> there must be linkRoute objects configured for each prefix or pattern for the 
> connected container.
> A more efficient mechanism for dynamic/ephemeral link routes can be supported 
> as follows:
> * A container opening a connection to the router may provide a connection 
> property that contains a list of prefixes and/or patterns for link routes.
> * During the lifecycle of that connection, the router maintains active 
> link-route addresses targeting that container.
> This feature allows for lightweight establishment of link-route destinations 
> without the need for connection roles and configured link-routes with 
> independently managed lifecycles (active, inactive, etc.).



--
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 issue #204: DISPATCH-845 - Added connection-scoped link-route ...

[ted-ross]

Github user ted-ross commented on the issue:

https://github.com/apache/qpid-dispatch/pull/204
  
Note that this feature is targeted at the 1.1.0 release.


---

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

[jira] [Commented] (DISPATCH-845) Allow connecting containers to declare their availability for link routes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-845:
-

GitHub user ted-ross opened a pull request:

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

DISPATCH-845 - Added connection-scoped link-route destinations.

Link route destinations can be dynamically created for a connection based 
on a connection property in the OPEN frame.  The lifecycle of the link-route 
addresses tracks the connection.


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

$ git pull https://github.com/ted-ross/qpid-dispatch tross-DISPATCH-845

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

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


commit a7752a37f3c2f6ce5e1df3377d2a5173b9e9324a
Author: Ted Ross 
Date:   2017-10-03T18:22:58Z

DISPATCH-845 - Added connection-scoped link-route destinations.




> Allow connecting containers to declare their availability for link routes
> -
>
> Key: DISPATCH-845
> URL: https://issues.apache.org/jira/browse/DISPATCH-845
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 1.1.0
>
>
> In the case where a container wishes to connect to a router network and 
> accept incoming routed link attaches (i.e. become a destination for link 
> routes), it is now quite complicated to do so.  First, the connected router 
> must be configured with a listener in the route-container role.  Second, 
> there must be linkRoute objects configured for each prefix or pattern for the 
> connected container.
> A more efficient mechanism for dynamic/ephemeral link routes can be supported 
> as follows:
> * A container opening a connection to the router may provide a connection 
> property that contains a list of prefixes and/or patterns for link routes.
> * During the lifecycle of that connection, the router maintains active 
> link-route addresses targeting that container.
> This feature allows for lightweight establishment of link-route destinations 
> without the need for connection roles and configured link-routes with 
> independently managed lifecycles (active, inactive, etc.).



--
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 #204: DISPATCH-845 - Added connection-scoped link...

[ted-ross]

GitHub user ted-ross opened a pull request:

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

DISPATCH-845 - Added connection-scoped link-route destinations.

Link route destinations can be dynamically created for a connection based 
on a connection property in the OPEN frame.  The lifecycle of the link-route 
addresses tracks the connection.


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

$ git pull https://github.com/ted-ross/qpid-dispatch tross-DISPATCH-845

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

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


commit a7752a37f3c2f6ce5e1df3377d2a5173b9e9324a
Author: Ted Ross 
Date:   2017-10-03T18:22:58Z

DISPATCH-845 - Added connection-scoped link-route destinations.




---

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

[jira] [Commented] (QPIDIT-96) Improvements in Java component management

[ASF subversion and git services (JIRA)]

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

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

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

QPIDIT-96: Minor change to QUICKSTART.md


> Improvements in Java component management
> -
>
> Key: QPIDIT-96
> URL: https://issues.apache.org/jira/browse/QPIDIT-96
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Improvement
>  Components: Installation
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>
> Robbie Gemmell has pointed out that there are some issues around handling of 
> the Java components in the pom files, also in the QUICKSTART.md instructions.
> The instructions should not instruct the local build of qpid-jms, rather rely 
> on Maven to find the artifacts it needs.
> The dependencies in the jms shim pom file should be moved to the project pom 
> file, and use properties to define the version numbers, this allows for the 
> versions of artifacts to be modified from the command-line.



--
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-1606) (Proton-J) Using Sasl needs to be optional for Client Role

[tim taylor (JIRA)]

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

tim taylor updated PROTON-1606:
---
Description: 
In order for my application to use Proton-j for amqps messaging, the Sasl layer 
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN 
time. The code below breaks our ability to use proton-j for amqps messaging as 
a CLIENT against our service.

...
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...

I need these three lines of code to be optional in the global handler, or for a 
new API that allows a transport implementation to undo creating the Sasl layer.

Something like:


Transport transport = event.getConnection().getTransport();
transport.disableSasl();


The service I am hitting against is not using Proton-j as the SERVER role.


  was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer 
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN 
time. The code below breaks our ability to use proton-j for amqps messaging as 
a CLIENT against our service (SERVER).

...
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...

I need these three lines of code to be optional in the global handler, or for a 
new API that allows a transport implementation to undo creating the Sasl layer.

Something like:


Transport transport = event.getConnection().getTransport();
transport.disableSasl();




> (Proton-J) Using Sasl needs to be optional for Client Role
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl 
> layer cannot be created by the global handler (IOHandler) at 
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j 
> for amqps messaging as a CLIENT against our service.
> ...
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> ...
> I need these three lines of code to be optional in the global handler, or for 
> a new API that allows a transport implementation to undo creating the Sasl 
> layer.
> Something like:
> 
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
> 
> The service I am hitting against is not using Proton-j as the SERVER role.



--
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] (QPIDIT-96) Improvements in Java component management

[ASF subversion and git services (JIRA)]

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

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

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

QPIDIT-96: Changes to QUICKSTART.md to improve instructions around the Java 
components (particularly Qpid-JMS). Also improvements to dependency version 
management - the version numbers are stored in properties in the main pom file, 
also all dependencies are moved to the main pom file.


> Improvements in Java component management
> -
>
> Key: QPIDIT-96
> URL: https://issues.apache.org/jira/browse/QPIDIT-96
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Improvement
>  Components: Installation
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>
> Robbie Gemmell has pointed out that there are some issues around handling of 
> the Java components in the pom files, also in the QUICKSTART.md instructions.
> The instructions should not instruct the local build of qpid-jms, rather rely 
> on Maven to find the artifacts it needs.
> The dependencies in the jms shim pom file should be moved to the project pom 
> file, and use properties to define the version numbers, this allows for the 
> versions of artifacts to be modified from the command-line.



--
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] (QPIDIT-96) Improvements in Java component management

[Kim van der Riet (JIRA)]

Kim van der Riet created QPIDIT-96:
--

 Summary: Improvements in Java component management
 Key: QPIDIT-96
 URL: https://issues.apache.org/jira/browse/QPIDIT-96
 Project: Apache QPID Interoperability Test Suite
  Issue Type: Improvement
  Components: Installation
Reporter: Kim van der Riet
Assignee: Kim van der Riet


Robbie Gemmell has pointed out that there are some issues around handling of 
the Java components in the pom files, also in the QUICKSTART.md instructions.

The instructions should not instruct the local build of qpid-jms, rather rely 
on Maven to find the artifacts it needs.

The dependencies in the jms shim pom file should be moved to the project pom 
file, and use properties to define the version numbers, this allows for the 
versions of artifacts to be modified from the command-line.



--
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] (QPIDIT-94) Does not install correctly on Python 2.6 (used by early versions of RHEL)

[Kim van der Riet (JIRA)]

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

Kim van der Riet resolved QPIDIT-94.

Resolution: Won't Fix

The current code uses Python 2.7.x features. This issue may be revisited at 
some point in the future, but for now, RHEL6 is not supported.

> Does not install correctly on Python 2.6 (used by early versions of RHEL)
> -
>
> Key: QPIDIT-94
> URL: https://issues.apache.org/jira/browse/QPIDIT-94
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Bug
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>
> The install scripts have Python 2.7 hard-coded into the paths. This is 
> causing parts of the install to fail.  The correct python path needs to be 
> detected and used for installation.



--
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] (QPIDIT-95) update to use the current v18 apache parent pom

[Kim van der Riet (JIRA)]

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

Kim van der Riet resolved QPIDIT-95.

Resolution: Fixed

> update to use the current v18 apache parent pom
> ---
>
> Key: QPIDIT-95
> URL: https://issues.apache.org/jira/browse/QPIDIT-95
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Improvement
>  Components: Installation, Qpid Jms Shim
>Affects Versions: 0.1.0-SNAPSHOT
>Reporter: Robbie Gemmell
>
> update to use the current v18 apache parent pom to better align with all the 
> other components, aiding in consistent use of plugin versions



--
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-7953) [Stress Test Tools] Simple changes to allow running against the qpid-jms-client

[ASF subversion and git services (JIRA)]

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

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

Commit d1b604f53be7a02173900d87bdb5362e3a5100f4 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=d1b604f ]

QPID-7953: [Java Tests] [Stress Test Tool] Superficial refactoring to allow the 
tool to be used with the qpid-jms-client.


> [Stress Test Tools] Simple changes to allow running against the 
> qpid-jms-client
> ---
>
> Key: QPID-7953
> URL: https://issues.apache.org/jira/browse/QPID-7953
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker, Java Tests
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
>
> The StressTestTools currently assume the old Qpid JMS Client's address 
> syntax.   Simply refactor the tools to remove this dependency.



--
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-7953) [Stress Test Tools] Simple changes to allow running against the qpid-jms-client

[Keith Wall (JIRA)]

Keith Wall created QPID-7953:


 Summary: [Stress Test Tools] Simple changes to allow running 
against the qpid-jms-client
 Key: QPID-7953
 URL: https://issues.apache.org/jira/browse/QPID-7953
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker, Java Tests
Reporter: Keith Wall
Assignee: Keith Wall
Priority: Minor


The StressTestTools currently assume the old Qpid JMS Client's address syntax.  
 Simply refactor the tools to remove this dependency.



--
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] (DISPATCH-845) Allow connecting containers to declare their availability for link routes

[Ted Ross (JIRA)]

Ted Ross created DISPATCH-845:
-

 Summary: Allow connecting containers to declare their availability 
for link routes
 Key: DISPATCH-845
 URL: https://issues.apache.org/jira/browse/DISPATCH-845
 Project: Qpid Dispatch
  Issue Type: New Feature
  Components: Router Node
Reporter: Ted Ross
Assignee: Ted Ross
 Fix For: 1.1.0


In the case where a container wishes to connect to a router network and accept 
incoming routed link attaches (i.e. become a destination for link routes), it 
is now quite complicated to do so.  First, the connected router must be 
configured with a listener in the route-container role.  Second, there must be 
linkRoute objects configured for each prefix or pattern for the connected 
container.

A more efficient mechanism for dynamic/ephemeral link routes can be supported 
as follows:

* A container opening a connection to the router may provide a connection 
property that contains a list of prefixes and/or patterns for link routes.
* During the lifecycle of that connection, the router maintains active 
link-route addresses targeting that container.

This feature allows for lightweight establishment of link-route destinations 
without the need for connection roles and configured link-routes with 
independently managed lifecycles (active, inactive, etc.).




--
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: Qpid Broker J tools - mercury, qpidbench etc - anyone still using this code?

[Robbie Gemmell]

On 3 October 2017 at 16:36, Keith W  wrote:
> Hello all,
>
> Does anyone retain any interest in the code beneath qpid-broker-j/tools?
>

Not me.

> https://github.com/apache/qpid-broker-j/tree/master/tools
>
> There are a number of programs under there that appear to be receiving
> no active development and to the best my knowledge are unused.   The
> code has hard-coded dependencies on the internals of Qpid JMS AMQP 0-x
> which is rather pesky.
>

Agreed, so regardless of whether they are being used (which like you,
I don't beleive they are) they are probably in the wrong repo now
either way.

> The programs do not form part release.   The code is nothing to do
> with "qpid-tools" release artefact.
>

Not really important, but the "qpid-tools" bits were themselves
incorporated into the qpid-cpp release previously, given their close
relation.

> The items I see with main entry points which I believe are dead:
>
> org.apache.qpid.testkit.Sender
> org.apache.qpid.testkit.Receiver
> org.apache.qpid.tools.MercuryTestController
> org.apache.qpid.tools.MercuryConsumerController
> org.apache.qpid.tools.QpidBench
> org.apache.qpid.tools.QpidSend
> org.apache.qpid.tools.QpidReceiver
> org.apache.qpid.tools.TestLauncher
> org.apache.qpid.tools.JNDICheck
>
> Unless I hear back that any of these required, I intend to remove
> these and supporting classes on Friday 6th.
>

Sounds good.

> I know the two StressTestClient and RestStressTestClient are still in use.
>
> Thanks Keith.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>

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

Qpid Broker J tools - mercury, qpidbench etc - anyone still using this code?

[Keith W]

Hello all,

Does anyone retain any interest in the code beneath qpid-broker-j/tools?

https://github.com/apache/qpid-broker-j/tree/master/tools

There are a number of programs under there that appear to be receiving
no active development and to the best my knowledge are unused.   The
code has hard-coded dependencies on the internals of Qpid JMS AMQP 0-x
which is rather pesky.

The programs do not form part release.   The code is nothing to do
with "qpid-tools" release artefact.

The items I see with main entry points which I believe are dead:

org.apache.qpid.testkit.Sender
org.apache.qpid.testkit.Receiver
org.apache.qpid.tools.MercuryTestController
org.apache.qpid.tools.MercuryConsumerController
org.apache.qpid.tools.QpidBench
org.apache.qpid.tools.QpidSend
org.apache.qpid.tools.QpidReceiver
org.apache.qpid.tools.TestLauncher
org.apache.qpid.tools.JNDICheck

Unless I hear back that any of these required, I intend to remove
these and supporting classes on Friday 6th.

I know the two StressTestClient and RestStressTestClient are still in use.

Thanks Keith.

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

[jira] [Commented] (DISPATCH-844) Make TLS cipher suites configurable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-844:
-

Github user ganeshmurthy closed the pull request at:

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


> Make TLS cipher suites configurable
> ---
>
> Key: DISPATCH-844
> URL: https://issues.apache.org/jira/browse/DISPATCH-844
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> A security conscious user may wish to restrict the set of ciphers to a 
> minimal set of those that are currently deemed secure.
> Proton now allows TLS cipher suites to be configurable as seen in 
> https://issues.apache.org/jira/browse/PROTON-1582
> Introduce a field called "ciphers" in sslProfile and call 
> pn_ssl_domain_set_ciphers if ciphers field is provided by the user.



--
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 #203: DISPATCH-844 - Added cipher field to sslPro...

[ganeshmurthy]

Github user ganeshmurthy closed the pull request at:

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


---

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

[jira] [Commented] (PROTON-1512) Expose the "aborted" flag for transferred deliveries

[Alan Conway (JIRA)]

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

Alan Conway commented on PROTON-1512:
-

The final, final missing piece: how to account for credit in the presence of 
aborted messages. See 
http://qpid.2158936.n2.nabble.com/AMQP-spec-question-aborted-messages-and-credit-td7667485.html


> Expose the "aborted" flag for transferred deliveries
> 
>
> Key: PROTON-1512
> URL: https://issues.apache.org/jira/browse/PROTON-1512
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-c
>Reporter: Ted Ross
>Assignee: Alan Conway
>  Labels: api
> Fix For: proton-c-0.18.0
>
>
> As we develop support for message streaming in Qpid Dispatch Router (i.e. 
> frames for large multi-frame messages are forwarded to destinations as they 
> arrive, before the complete message is received), there is a need to handle 
> the case where a received message is never completed.
> The AMQP protocol has a provision for this in the "aborted" flag in the 
> transfer performative.  If the router is in the process of streaming a large 
> message from sender to receiver and the sender drops before completing the 
> delivery, the router can send a transfer to the downstream receivers with the 
> "aborted" flag set.  This would indicate that the message should not be 
> processed and would not cause any framing errors on the link.
> Proton does not currently expose this capability in its API (There is a 
> pn_link_abort in the C header file, but it is commented out and not 
> implemented).
> In order to properly handle the failure cases for message streaming, this 
> feature must be usable in Proton.



--
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-7952) [Java Broker, AMQP 1.0] Changes to Terminus on Reattach/Resuming a Link are not persisted

[Lorenz Quack (JIRA)]

Lorenz Quack created QPID-7952:
--

 Summary: [Java Broker, AMQP 1.0] Changes to Terminus on 
Reattach/Resuming a Link are not persisted
 Key: QPID-7952
 URL: https://issues.apache.org/jira/browse/QPID-7952
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Reporter: Lorenz Quack
 Fix For: Future


When establishing a Link we save the terminus in the LinkRegistry.
When we reattach/resume the Link with a modified Terminus we do not update the 
representation in the LinkRegistry.



--
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-7951) [Java Broker, AMQP 1.0] Task on IOThread might cause Config thread to hang indefinitely

[Lorenz Quack (JIRA)]

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

Lorenz Quack updated QPID-7951:
---
Summary: [Java Broker, AMQP 1.0] Task on IOThread might cause Config thread 
to hang indefinitely  (was: [Java Broker, AMQP 1.0] )

> [Java Broker, AMQP 1.0] Task on IOThread might cause Config thread to hang 
> indefinitely
> ---
>
> Key: QPID-7951
> URL: https://issues.apache.org/jira/browse/QPID-7951
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> It seems that it is possible that a Task is submitted to be executed on the 
> IOThread via doOnIOThread but is never being executed because the Connection 
> is already closed. This might result in a Thread hanging indefinetely if it 
> calls ACO.doSync() on the ListeningFuture of the Task.
> This was occurring in the cleanup code to 
> {{TransactionalTransferTest#receiveTransactionalAcquisitionFlowFailsDueToUnknownTransactionId}}.



--
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-7951) [Java Broker, AMQP 1.0] Task on IOThread might cause Config thread to hang indefinitely

[Lorenz Quack (JIRA)]

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

Lorenz Quack updated QPID-7951:
---
Priority: Blocker  (was: Major)

> [Java Broker, AMQP 1.0] Task on IOThread might cause Config thread to hang 
> indefinitely
> ---
>
> Key: QPID-7951
> URL: https://issues.apache.org/jira/browse/QPID-7951
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
>Priority: Blocker
> Fix For: qpid-java-broker-7.0.0
>
>
> It seems that it is possible that a Task is submitted to be executed on the 
> IOThread via doOnIOThread but is never being executed because the Connection 
> is already closed. This might result in a Thread hanging indefinetely if it 
> calls ACO.doSync() on the ListeningFuture of the Task.
> This was occurring in the cleanup code to 
> {{TransactionalTransferTest#receiveTransactionalAcquisitionFlowFailsDueToUnknownTransactionId}}.



--
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-7951) [Java Broker, AMQP 1.0]

[Lorenz Quack (JIRA)]

Lorenz Quack created QPID-7951:
--

 Summary: [Java Broker, AMQP 1.0] 
 Key: QPID-7951
 URL: https://issues.apache.org/jira/browse/QPID-7951
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Reporter: Lorenz Quack
 Fix For: qpid-java-broker-7.0.0


It seems that it is possible that a Task is submitted to be executed on the 
IOThread via doOnIOThread but is never being executed because the Connection is 
already closed. This might result in a Thread hanging indefinetely if it calls 
ACO.doSync() on the ListeningFuture of the Task.

This was occurring in the cleanup code to 
{{TransactionalTransferTest#receiveTransactionalAcquisitionFlowFailsDueToUnknownTransactionId}}.



--
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-7950) [Java Broker, AMQP 1.0] Discharging transaction after consumer link detach does not apply the correct outcomes

[Lorenz Quack (JIRA)]

Lorenz Quack created QPID-7950:
--

 Summary: [Java Broker, AMQP 1.0] Discharging transaction after 
consumer link detach does not apply the correct outcomes
 Key: QPID-7950
 URL: https://issues.apache.org/jira/browse/QPID-7950
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Reporter: Lorenz Quack
Priority: Blocker
 Fix For: qpid-java-broker-7.0.0


Consider the following scenario:
 * declare transaction
 * receive a delivery
 * detach the consumer
 * send disposition with txn-state and Accepted outcome
 * discharge the transaction

After this message should be deleted from the broker. It currently is not.
Currently, detaching the link applies the Modified outcome to all unsettled 
messages therefore the disposition and discharge have no effect on them.



--
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-332) enable defining destination names in tomcat resource definitions

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated QPIDJMS-332:
---
Summary: enable defining destination names in tomcat resource definitions  
(was: Defining queue's name as tomcat resource conflichts resource definition)

> enable defining destination names in tomcat resource definitions
> 
>
> Key: QPIDJMS-332
> URL: https://issues.apache.org/jira/browse/QPIDJMS-332
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Bernhard Seidl
>Assignee: Robbie Gemmell
> Fix For: 0.26.0
>
>
> Since a few days i am trying to define a queue resource in Tomcat's 
> context.xml. The attribute "name" defines the jndi name. Looking at 
> org.apache.qpid.jms.JmsDestination 
> the attribute is called "name", too. This seems to me as a  naming conflict. 
> I tried to use  the attribute "physicalName" due to the fact that some of the 
> classes are based on ActiveMQ. However I am not sure if I am missing a point 
> somewhere else:
> This is my setup:
> Context.xml
> {code:xml}
>type="org.apache.qpid.jms.JmsConnectionFactory" 
> factory="org.apache.qpid.jms.jndi.JNDIReferenceFactory"
>   remoteURI="amqp://10.10.10.1:5672" username="a" password="a"
>   maxPoolSize="20" connectionTimeout="6" />
>  type="org.apache.qpid.jms.JmsQueue" 
> factory="org.apache.qpid.jms.jndi.JNDIReferenceFactory"
>   physicalName="name"/>
> {code}
> Init-code using spring:
> {code:java}
> @Configuration
> @EnableJms
> public class MessagingConfiguration {
>   @Bean
>   public ConnectionFactory connectionFactory() throws NamingException {
>   ConnectionFactory connectionFactory =  (new JndiTemplate())
>   
> .lookup("java:/comp/env/jms/ConnectionFactory",ConnectionFactory.class);
>   return connectionFactory;
>   }
>   
>   @Bean
>   public DestinationResolver destinationResolver() {
>   JndiDestinationResolver jdr = new JndiDestinationResolver();
>   try {
>   // testing
>   Queue q = 
> jdr.getJndiTemplate().lookup("java:/comp/env/jms/queue", Queue.class);
>   System.out.println("A: " + q.getQueueName());
>   System.out.println("B: " + (new 
> JndiTemplate()).lookup("java:/comp/env/jms/queue", 
> Destination.class).getClass());
>   } catch (Exception e) {
>   // TODO Auto-generated catch block
>   e.printStackTrace();
>   }
>   return jdr; 
>   }
>   @Bean
>   public JmsTemplate jmsTemplate() throws NamingException {
>   JmsTemplate template = new JmsTemplate();
>   template.setConnectionFactory(connectionFactory());
>   template.setDestinationResolver(destinationResolver());
>   return template;
>   }
> }
> {code}
> Running the code prints out:
> {noformat}
> ...
> A:
> B: class org.apache.qpid.jms.JmsQueue
> {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] [Comment Edited] (QPIDJMS-332) Defining queue's name as tomcat resource conflichts resource definition

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell edited comment on QPIDJMS-332 at 10/3/17 12:43 PM:
--

We've made some updates to hopefully enable this to work, changing the client 
to use "address" for storing the destination name details rather than "name" 
(though that is still used if given, for compatibility for other existing 
usages).

I hope to do a 0.26.0 release very soon, perhaps even later today or tomorrow, 
so it would be useful if you could give this a try on the 0.26.0-SNAPSHOT. You 
can either build the current master yourself locally (its mirrored at 
https://github.com/apache/qpid-jms) or alternatively snapshots are deployed to 
https://repository.apache.org/content/repositories/snapshots/ for testing and 
the latest build just went in.


was (Author: gemmellr):
We've made some updates to hopefully enable this to work, changing the client 
to use "address" for storing the destination name details rather than "name" 
(though that is still used if given, for compatibility for other existing 
usages).

I hope to do a 0.26.0 release very soon, perhaps even later today or tomorrow, 
so it would be useful if you could give this a try on the 0.26.0-SNAPSHOT. You 
can either build the current master yourself locally (its mirrored at 
https://github.com/apache/qpid-jms) or alternatively snapshots are deployed to 
https://repository.apache.org/content/repositories/snapshots/ for testing and 
the latest build just went run.

> Defining queue's name as tomcat resource conflichts resource definition
> ---
>
> Key: QPIDJMS-332
> URL: https://issues.apache.org/jira/browse/QPIDJMS-332
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Bernhard Seidl
>Assignee: Robbie Gemmell
> Fix For: 0.26.0
>
>
> Since a few days i am trying to define a queue resource in Tomcat's 
> context.xml. The attribute "name" defines the jndi name. Looking at 
> org.apache.qpid.jms.JmsDestination 
> the attribute is called "name", too. This seems to me as a  naming conflict. 
> I tried to use  the attribute "physicalName" due to the fact that some of the 
> classes are based on ActiveMQ. However I am not sure if I am missing a point 
> somewhere else:
> This is my setup:
> Context.xml
> {code:xml}
>type="org.apache.qpid.jms.JmsConnectionFactory" 
> factory="org.apache.qpid.jms.jndi.JNDIReferenceFactory"
>   remoteURI="amqp://10.10.10.1:5672" username="a" password="a"
>   maxPoolSize="20" connectionTimeout="6" />
>  type="org.apache.qpid.jms.JmsQueue" 
> factory="org.apache.qpid.jms.jndi.JNDIReferenceFactory"
>   physicalName="name"/>
> {code}
> Init-code using spring:
> {code:java}
> @Configuration
> @EnableJms
> public class MessagingConfiguration {
>   @Bean
>   public ConnectionFactory connectionFactory() throws NamingException {
>   ConnectionFactory connectionFactory =  (new JndiTemplate())
>   
> .lookup("java:/comp/env/jms/ConnectionFactory",ConnectionFactory.class);
>   return connectionFactory;
>   }
>   
>   @Bean
>   public DestinationResolver destinationResolver() {
>   JndiDestinationResolver jdr = new JndiDestinationResolver();
>   try {
>   // testing
>   Queue q = 
> jdr.getJndiTemplate().lookup("java:/comp/env/jms/queue", Queue.class);
>   System.out.println("A: " + q.getQueueName());
>   System.out.println("B: " + (new 
> JndiTemplate()).lookup("java:/comp/env/jms/queue", 
> Destination.class).getClass());
>   } catch (Exception e) {
>   // TODO Auto-generated catch block
>   e.printStackTrace();
>   }
>   return jdr; 
>   }
>   @Bean
>   public JmsTemplate jmsTemplate() throws NamingException {
>   JmsTemplate template = new JmsTemplate();
>   template.setConnectionFactory(connectionFactory());
>   template.setDestinationResolver(destinationResolver());
>   return template;
>   }
> }
> {code}
> Running the code prints out:
> {noformat}
> ...
> A:
> B: class org.apache.qpid.jms.JmsQueue
> {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-332) Defining queue's name as tomcat resource conflichts resource definition

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell commented on QPIDJMS-332:


We've made some updates to hopefully enable this to work, changing the client 
to use "address" for storing the destination name details rather than "name" 
(though that is still used if given, for compatibility for other existing 
usages).

I hope to do a 0.26.0 release very soon, perhaps even later today or tomorrow, 
so it would be useful if you could give this a try on the 0.26.0-SNAPSHOT. You 
can either build the current master yourself locally (its mirrored at 
https://github.com/apache/qpid-jms) or alternatively snapshots are deployed to 
https://repository.apache.org/content/repositories/snapshots/ for testing and 
the latest build just went run.

> Defining queue's name as tomcat resource conflichts resource definition
> ---
>
> Key: QPIDJMS-332
> URL: https://issues.apache.org/jira/browse/QPIDJMS-332
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Bernhard Seidl
>Assignee: Robbie Gemmell
> Fix For: 0.26.0
>
>
> Since a few days i am trying to define a queue resource in Tomcat's 
> context.xml. The attribute "name" defines the jndi name. Looking at 
> org.apache.qpid.jms.JmsDestination 
> the attribute is called "name", too. This seems to me as a  naming conflict. 
> I tried to use  the attribute "physicalName" due to the fact that some of the 
> classes are based on ActiveMQ. However I am not sure if I am missing a point 
> somewhere else:
> This is my setup:
> Context.xml
> {code:xml}
>type="org.apache.qpid.jms.JmsConnectionFactory" 
> factory="org.apache.qpid.jms.jndi.JNDIReferenceFactory"
>   remoteURI="amqp://10.10.10.1:5672" username="a" password="a"
>   maxPoolSize="20" connectionTimeout="6" />
>  type="org.apache.qpid.jms.JmsQueue" 
> factory="org.apache.qpid.jms.jndi.JNDIReferenceFactory"
>   physicalName="name"/>
> {code}
> Init-code using spring:
> {code:java}
> @Configuration
> @EnableJms
> public class MessagingConfiguration {
>   @Bean
>   public ConnectionFactory connectionFactory() throws NamingException {
>   ConnectionFactory connectionFactory =  (new JndiTemplate())
>   
> .lookup("java:/comp/env/jms/ConnectionFactory",ConnectionFactory.class);
>   return connectionFactory;
>   }
>   
>   @Bean
>   public DestinationResolver destinationResolver() {
>   JndiDestinationResolver jdr = new JndiDestinationResolver();
>   try {
>   // testing
>   Queue q = 
> jdr.getJndiTemplate().lookup("java:/comp/env/jms/queue", Queue.class);
>   System.out.println("A: " + q.getQueueName());
>   System.out.println("B: " + (new 
> JndiTemplate()).lookup("java:/comp/env/jms/queue", 
> Destination.class).getClass());
>   } catch (Exception e) {
>   // TODO Auto-generated catch block
>   e.printStackTrace();
>   }
>   return jdr; 
>   }
>   @Bean
>   public JmsTemplate jmsTemplate() throws NamingException {
>   JmsTemplate template = new JmsTemplate();
>   template.setConnectionFactory(connectionFactory());
>   template.setDestinationResolver(destinationResolver());
>   return template;
>   }
> }
> {code}
> Running the code prints out:
> {noformat}
> ...
> A:
> B: class org.apache.qpid.jms.JmsQueue
> {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-332) Defining queue's name as tomcat resource conflichts resource definition

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved QPIDJMS-332.

Resolution: Fixed

> Defining queue's name as tomcat resource conflichts resource definition
> ---
>
> Key: QPIDJMS-332
> URL: https://issues.apache.org/jira/browse/QPIDJMS-332
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Bernhard Seidl
>Assignee: Robbie Gemmell
> Fix For: 0.26.0
>
>
> Since a few days i am trying to define a queue resource in Tomcat's 
> context.xml. The attribute "name" defines the jndi name. Looking at 
> org.apache.qpid.jms.JmsDestination 
> the attribute is called "name", too. This seems to me as a  naming conflict. 
> I tried to use  the attribute "physicalName" due to the fact that some of the 
> classes are based on ActiveMQ. However I am not sure if I am missing a point 
> somewhere else:
> This is my setup:
> Context.xml
> {code:xml}
>type="org.apache.qpid.jms.JmsConnectionFactory" 
> factory="org.apache.qpid.jms.jndi.JNDIReferenceFactory"
>   remoteURI="amqp://10.10.10.1:5672" username="a" password="a"
>   maxPoolSize="20" connectionTimeout="6" />
>  type="org.apache.qpid.jms.JmsQueue" 
> factory="org.apache.qpid.jms.jndi.JNDIReferenceFactory"
>   physicalName="name"/>
> {code}
> Init-code using spring:
> {code:java}
> @Configuration
> @EnableJms
> public class MessagingConfiguration {
>   @Bean
>   public ConnectionFactory connectionFactory() throws NamingException {
>   ConnectionFactory connectionFactory =  (new JndiTemplate())
>   
> .lookup("java:/comp/env/jms/ConnectionFactory",ConnectionFactory.class);
>   return connectionFactory;
>   }
>   
>   @Bean
>   public DestinationResolver destinationResolver() {
>   JndiDestinationResolver jdr = new JndiDestinationResolver();
>   try {
>   // testing
>   Queue q = 
> jdr.getJndiTemplate().lookup("java:/comp/env/jms/queue", Queue.class);
>   System.out.println("A: " + q.getQueueName());
>   System.out.println("B: " + (new 
> JndiTemplate()).lookup("java:/comp/env/jms/queue", 
> Destination.class).getClass());
>   } catch (Exception e) {
>   // TODO Auto-generated catch block
>   e.printStackTrace();
>   }
>   return jdr; 
>   }
>   @Bean
>   public JmsTemplate jmsTemplate() throws NamingException {
>   JmsTemplate template = new JmsTemplate();
>   template.setConnectionFactory(connectionFactory());
>   template.setDestinationResolver(destinationResolver());
>   return template;
>   }
> }
> {code}
> Running the code prints out:
> {noformat}
> ...
> A:
> B: class org.apache.qpid.jms.JmsQueue
> {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] [Assigned] (QPIDJMS-332) Defining queue's name as tomcat resource conflichts resource definition

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell reassigned QPIDJMS-332:
--

Assignee: Robbie Gemmell

> Defining queue's name as tomcat resource conflichts resource definition
> ---
>
> Key: QPIDJMS-332
> URL: https://issues.apache.org/jira/browse/QPIDJMS-332
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Bernhard Seidl
>Assignee: Robbie Gemmell
> Fix For: 0.26.0
>
>
> Since a few days i am trying to define a queue resource in Tomcat's 
> context.xml. The attribute "name" defines the jndi name. Looking at 
> org.apache.qpid.jms.JmsDestination 
> the attribute is called "name", too. This seems to me as a  naming conflict. 
> I tried to use  the attribute "physicalName" due to the fact that some of the 
> classes are based on ActiveMQ. However I am not sure if I am missing a point 
> somewhere else:
> This is my setup:
> Context.xml
> {code:xml}
>type="org.apache.qpid.jms.JmsConnectionFactory" 
> factory="org.apache.qpid.jms.jndi.JNDIReferenceFactory"
>   remoteURI="amqp://10.10.10.1:5672" username="a" password="a"
>   maxPoolSize="20" connectionTimeout="6" />
>  type="org.apache.qpid.jms.JmsQueue" 
> factory="org.apache.qpid.jms.jndi.JNDIReferenceFactory"
>   physicalName="name"/>
> {code}
> Init-code using spring:
> {code:java}
> @Configuration
> @EnableJms
> public class MessagingConfiguration {
>   @Bean
>   public ConnectionFactory connectionFactory() throws NamingException {
>   ConnectionFactory connectionFactory =  (new JndiTemplate())
>   
> .lookup("java:/comp/env/jms/ConnectionFactory",ConnectionFactory.class);
>   return connectionFactory;
>   }
>   
>   @Bean
>   public DestinationResolver destinationResolver() {
>   JndiDestinationResolver jdr = new JndiDestinationResolver();
>   try {
>   // testing
>   Queue q = 
> jdr.getJndiTemplate().lookup("java:/comp/env/jms/queue", Queue.class);
>   System.out.println("A: " + q.getQueueName());
>   System.out.println("B: " + (new 
> JndiTemplate()).lookup("java:/comp/env/jms/queue", 
> Destination.class).getClass());
>   } catch (Exception e) {
>   // TODO Auto-generated catch block
>   e.printStackTrace();
>   }
>   return jdr; 
>   }
>   @Bean
>   public JmsTemplate jmsTemplate() throws NamingException {
>   JmsTemplate template = new JmsTemplate();
>   template.setConnectionFactory(connectionFactory());
>   template.setDestinationResolver(destinationResolver());
>   return template;
>   }
> }
> {code}
> Running the code prints out:
> {noformat}
> ...
> A:
> B: class org.apache.qpid.jms.JmsQueue
> {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] (QPIDJMS-332) Defining queue's name as tomcat resource conflichts resource definition

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated QPIDJMS-332:
---
Fix Version/s: 0.26.0

> Defining queue's name as tomcat resource conflichts resource definition
> ---
>
> Key: QPIDJMS-332
> URL: https://issues.apache.org/jira/browse/QPIDJMS-332
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Bernhard Seidl
>Assignee: Robbie Gemmell
> Fix For: 0.26.0
>
>
> Since a few days i am trying to define a queue resource in Tomcat's 
> context.xml. The attribute "name" defines the jndi name. Looking at 
> org.apache.qpid.jms.JmsDestination 
> the attribute is called "name", too. This seems to me as a  naming conflict. 
> I tried to use  the attribute "physicalName" due to the fact that some of the 
> classes are based on ActiveMQ. However I am not sure if I am missing a point 
> somewhere else:
> This is my setup:
> Context.xml
> {code:xml}
>type="org.apache.qpid.jms.JmsConnectionFactory" 
> factory="org.apache.qpid.jms.jndi.JNDIReferenceFactory"
>   remoteURI="amqp://10.10.10.1:5672" username="a" password="a"
>   maxPoolSize="20" connectionTimeout="6" />
>  type="org.apache.qpid.jms.JmsQueue" 
> factory="org.apache.qpid.jms.jndi.JNDIReferenceFactory"
>   physicalName="name"/>
> {code}
> Init-code using spring:
> {code:java}
> @Configuration
> @EnableJms
> public class MessagingConfiguration {
>   @Bean
>   public ConnectionFactory connectionFactory() throws NamingException {
>   ConnectionFactory connectionFactory =  (new JndiTemplate())
>   
> .lookup("java:/comp/env/jms/ConnectionFactory",ConnectionFactory.class);
>   return connectionFactory;
>   }
>   
>   @Bean
>   public DestinationResolver destinationResolver() {
>   JndiDestinationResolver jdr = new JndiDestinationResolver();
>   try {
>   // testing
>   Queue q = 
> jdr.getJndiTemplate().lookup("java:/comp/env/jms/queue", Queue.class);
>   System.out.println("A: " + q.getQueueName());
>   System.out.println("B: " + (new 
> JndiTemplate()).lookup("java:/comp/env/jms/queue", 
> Destination.class).getClass());
>   } catch (Exception e) {
>   // TODO Auto-generated catch block
>   e.printStackTrace();
>   }
>   return jdr; 
>   }
>   @Bean
>   public JmsTemplate jmsTemplate() throws NamingException {
>   JmsTemplate template = new JmsTemplate();
>   template.setConnectionFactory(connectionFactory());
>   template.setDestinationResolver(destinationResolver());
>   return template;
>   }
> }
> {code}
> Running the code prints out:
> {noformat}
> ...
> A:
> B: class org.apache.qpid.jms.JmsQueue
> {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-332) Defining queue's name as tomcat resource conflichts resource definition

[ASF subversion and git services (JIRA)]

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

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

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

QPIDJMS-332: change property used for JNDI storage of destination names

Stop using "name" to allow for Tomcat context.xml resource definition, where 
"name" is the JNDI lookup. Use "address" going forward but continue to accept 
both, allowing other existing configuration to still work.

Changes by myself and Tim.


> Defining queue's name as tomcat resource conflichts resource definition
> ---
>
> Key: QPIDJMS-332
> URL: https://issues.apache.org/jira/browse/QPIDJMS-332
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Bernhard Seidl
>
> Since a few days i am trying to define a queue resource in Tomcat's 
> context.xml. The attribute "name" defines the jndi name. Looking at 
> org.apache.qpid.jms.JmsDestination 
> the attribute is called "name", too. This seems to me as a  naming conflict. 
> I tried to use  the attribute "physicalName" due to the fact that some of the 
> classes are based on ActiveMQ. However I am not sure if I am missing a point 
> somewhere else:
> This is my setup:
> Context.xml
> {code:xml}
>type="org.apache.qpid.jms.JmsConnectionFactory" 
> factory="org.apache.qpid.jms.jndi.JNDIReferenceFactory"
>   remoteURI="amqp://10.10.10.1:5672" username="a" password="a"
>   maxPoolSize="20" connectionTimeout="6" />
>  type="org.apache.qpid.jms.JmsQueue" 
> factory="org.apache.qpid.jms.jndi.JNDIReferenceFactory"
>   physicalName="name"/>
> {code}
> Init-code using spring:
> {code:java}
> @Configuration
> @EnableJms
> public class MessagingConfiguration {
>   @Bean
>   public ConnectionFactory connectionFactory() throws NamingException {
>   ConnectionFactory connectionFactory =  (new JndiTemplate())
>   
> .lookup("java:/comp/env/jms/ConnectionFactory",ConnectionFactory.class);
>   return connectionFactory;
>   }
>   
>   @Bean
>   public DestinationResolver destinationResolver() {
>   JndiDestinationResolver jdr = new JndiDestinationResolver();
>   try {
>   // testing
>   Queue q = 
> jdr.getJndiTemplate().lookup("java:/comp/env/jms/queue", Queue.class);
>   System.out.println("A: " + q.getQueueName());
>   System.out.println("B: " + (new 
> JndiTemplate()).lookup("java:/comp/env/jms/queue", 
> Destination.class).getClass());
>   } catch (Exception e) {
>   // TODO Auto-generated catch block
>   e.printStackTrace();
>   }
>   return jdr; 
>   }
>   @Bean
>   public JmsTemplate jmsTemplate() throws NamingException {
>   JmsTemplate template = new JmsTemplate();
>   template.setConnectionFactory(connectionFactory());
>   template.setDestinationResolver(destinationResolver());
>   return template;
>   }
> }
> {code}
> Running the code prints out:
> {noformat}
> ...
> A:
> B: class org.apache.qpid.jms.JmsQueue
> {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] (QPID-7946) [Java Broker] ProtocolNegotiationTest only works by accident on AMQP 1.0

[ASF subversion and git services (JIRA)]

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

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

Commit 9f92eedde466217d013e6fb9ac1aa8c3568d1e74 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=9f92eed ]

QPID-7946: Ensure that ProtocolNegotiationTest continues to send heartbeats for 
AMQP 0-9 and 0-91 (Fixes defect added by 
526019c750fed803ccd16a01177009cc0bfee1ff)


> [Java Broker] ProtocolNegotiationTest only works by accident on AMQP 1.0 
> -
>
> Key: QPID-7946
> URL: https://issues.apache.org/jira/browse/QPID-7946
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>Priority: Minor
>
> ProtocolNegotiationTest.testNoConnectionOpenSent_BrokerClosesConnection 
> attempts to send heartbeats to the broker after sending the first protocol 
> header but before authenticating.
> In AMQP 1.0 you cannot send empty (heartbeat) frames while establishing a 
> SASL layer - empty (heartbeat) frames are only defined for AMQP frames.  To 
> compound this error, the test is actually sending AMQP 0-8 heartbeat frames 
> anyway :-)
> The test also fails on Windows seemingly because windows does not report the 
> connection has closed unless you try to read from 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] (QPID-7904) [Java Broker] ensure ACLs work with AMQP 1.0

[ASF subversion and git services (JIRA)]

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

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

Commit 2382c699eeca6afae34cb1b8e8a6fb5687ae79c7 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=2382c69 ]

QPID-7904: [Java Broker] [ACL] Change the AMQP 1.0 layer so it no longer 
activates dynamically created queues

Added ACL temporary topic tests.


> [Java Broker] ensure ACLs work with AMQP 1.0
> 
>
> Key: QPID-7904
> URL: https://issues.apache.org/jira/browse/QPID-7904
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> Currently the {{ExternalACLTest}} and {{ExhaustiveACLTEst}} are excluded in 
> the {{Jav10UninvestigatedTestsExcludes}}.
> Enabling and fixing the first cause of failure (use {{ConnectionBuilder}} 
> instead of assuming {{AMQConnection}}) reveals that at least one test 
> genuinely fails  ({{testClientCreateTemporaryQueueFailed}} because we create 
> the temp queue in {{Session_1_0}} with the SystemPrinciple. See QPID-7625).



--
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-7949) [c++ client]msg::Connection.open() never return when FQDN url is provided and broker not started

[Gerald Guillaume (JIRA)]

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

Gerald Guillaume updated QPID-7949:
---
Summary: [c++ client]msg::Connection.open() never return when FQDN url is 
provided and broker not started  (was: msg::Connection.open() never return when 
FQDN url is provided and broker not started)

> [c++ client]msg::Connection.open() never return when FQDN url is provided and 
> broker not started
> 
>
> Key: QPID-7949
> URL: https://issues.apache.org/jira/browse/QPID-7949
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Client
>Affects Versions: qpid-cpp-1.36.0
> Environment: Debian Jessie 7 (64 bits)
> We are using the debian package provided here
> https://launchpad.net/~qpid/+archive/ubuntu/testing/+packages
> Publishing details
> Published on 2017-05-19
> Changelog
> qpid-cpp (1.36.0-1qpid+xenial1) xenial; urgency=medium
>Reporter: Gerald Guillaume
>
> h2. Test 1
> The conditions are :
> * the broker is not started. 
> * the IP address is set in the url.
> * the IP is reachable by ping
> Output : the open() function exit and isOpen() returns false.
> Result : {color:#8eb021}=> Expected behavior{color}
> source code:
> {code}
> msg::Connection *connection = new 
> msg::Connection("amqp:tcp:166.99.224.88:5672", "{protocol: amqp1.0}");
> connection->setOption("transport", "tcp");
> connection->setOption("reconnect", false);
> connection->open();
> printf("connection %s to AMQP broker \n",(connection->isOpen()) ? "OK" : 
> "KO");
> {code}
> logs are
> {code}
> 2017-10-03 08:54:00 [Messaging] debug Protocol defaults:
> 2017-10-03 08:57:31 [Messaging] debug Trying versions amqp1.0
> 2017-10-03 08:57:31 [Messaging] debug Driver started
> 2017-10-03 08:57:31 [Messaging] debug tcp:166.99.224.88:5672 Connecting ...
> 2017-10-03 08:57:31 [Client] debug Set TCP_NODELAY
> 2017-10-03 08:57:31 [Messaging] debug Failed to connect: Connection refused
> connection KO to AMQP broker
> {code}
> h2. Test 2
> The conditions are :
> * the broker is not started. 
> * the FQDN address is set in the url.
> * the FQDN  is reachable by ping
> Output : the open() function never exit, and EpollPoller.cpp:357 complains 
> "No such file or directory".
> Result : {color:#d04437}=> Failed{color}
> {code}
> ping 
> PING  (166.99.224.88) 56(84) bytes of data.
> 64 bytes from 166.99.224.88: icmp_seq=1 ttl=128 time=2.01 ms
> 64 bytes from 166.99.224.88: icmp_seq=2 ttl=128 time=1.19 ms
> {code}
> source code:
> {code}
> msg::Connection *connection = new msg::Connection("amqp:tcp::5672", 
> "{protocol: amqp1.0}");
> connection->setOption("transport", "tcp");
> connection->setOption("reconnect", false);
> connection->open();
> printf("connection %s to AMQP broker \n",(connection->isOpen()) ? "OK" : 
> "KO");
> {code}
> logs are
> {code}
> 2017-10-03 08:38:04 [Messaging] debug Protocol defaults: 
> 2017-10-03 08:38:05 [Messaging] debug Trying versions amqp1.0
> 2017-10-03 08:38:05 [Messaging] debug Driver started
> 2017-10-03 08:38:05 [Messaging] debug tcp::5672 Connecting 
> ...
> 2017-10-03 08:50:49 [Client] debug Set TCP_NODELAY
> 2017-10-03 08:50:49 [System] debug Ignored socket connect error: Connection 
> refused
> 2017-10-03 08:50:49 [System] debug Exception constructed: Network is 
> unreachable: :5672 
> (/usr/src/packages/BUILD/src/qpid/sys/posix/BSDSocket.cpp:161)
> 2017-10-03 08:50:49 [System] debug Ignored socket connect exception: Network 
> is unreachable: :5672 
> (/usr/src/packages/BUILD/src/qpid/sys/posix/BSDSocket.cpp:161)
> 2017-10-03 08:50:49 [System] debug Exception constructed: No such file or 
> directory (/usr/src/packages/BUILD/src/qpid/sys/epoll/EpollPoller.cpp:357)
> {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

[jira] [Created] (QPID-7949) msg::Connection.open() never return when FQDN url is provided and broker not started

[Gerald Guillaume (JIRA)]

Gerald Guillaume created QPID-7949:
--

 Summary: msg::Connection.open() never return when FQDN url is 
provided and broker not started
 Key: QPID-7949
 URL: https://issues.apache.org/jira/browse/QPID-7949
 Project: Qpid
  Issue Type: Bug
  Components: C++ Client
Affects Versions: qpid-cpp-1.36.0
 Environment: Debian Jessie 7 (64 bits)
We are using the debian package provided here
https://launchpad.net/~qpid/+archive/ubuntu/testing/+packages
Publishing details
Published on 2017-05-19
Changelog
qpid-cpp (1.36.0-1qpid+xenial1) xenial; urgency=medium


Reporter: Gerald Guillaume


h2. Test 1
The conditions are :
* the broker is not started. 
* the IP address is set in the url.
* the IP is reachable by ping
Output : the open() function exit and isOpen() returns false.
Result : {color:#8eb021}=> Expected behavior{color}
source code:
{code}
msg::Connection *connection = new 
msg::Connection("amqp:tcp:166.99.224.88:5672", "{protocol: amqp1.0}");
connection->setOption("transport", "tcp");
connection->setOption("reconnect", false);
connection->open();
printf("connection %s to AMQP broker \n",(connection->isOpen()) ? "OK" : "KO");
{code}
logs are
{code}
2017-10-03 08:54:00 [Messaging] debug Protocol defaults:
2017-10-03 08:57:31 [Messaging] debug Trying versions amqp1.0
2017-10-03 08:57:31 [Messaging] debug Driver started
2017-10-03 08:57:31 [Messaging] debug tcp:166.99.224.88:5672 Connecting ...
2017-10-03 08:57:31 [Client] debug Set TCP_NODELAY
2017-10-03 08:57:31 [Messaging] debug Failed to connect: Connection refused
connection KO to AMQP broker
{code}

h2. Test 2
The conditions are :
* the broker is not started. 
* the FQDN address is set in the url.
* the FQDN  is reachable by ping
Output : the open() function never exit, and EpollPoller.cpp:357 complains "No 
such file or directory".

Result : {color:#d04437}=> Failed{color}
{code}
ping 
PING  (166.99.224.88) 56(84) bytes of data.
64 bytes from 166.99.224.88: icmp_seq=1 ttl=128 time=2.01 ms
64 bytes from 166.99.224.88: icmp_seq=2 ttl=128 time=1.19 ms
{code}
source code:
{code}
msg::Connection *connection = new msg::Connection("amqp:tcp::5672", 
"{protocol: amqp1.0}");
connection->setOption("transport", "tcp");
connection->setOption("reconnect", false);
connection->open();
printf("connection %s to AMQP broker \n",(connection->isOpen()) ? "OK" : "KO");
{code}
logs are
{code}
2017-10-03 08:38:04 [Messaging] debug Protocol defaults: 
2017-10-03 08:38:05 [Messaging] debug Trying versions amqp1.0
2017-10-03 08:38:05 [Messaging] debug Driver started
2017-10-03 08:38:05 [Messaging] debug tcp::5672 Connecting ...
2017-10-03 08:50:49 [Client] debug Set TCP_NODELAY
2017-10-03 08:50:49 [System] debug Ignored socket connect error: Connection 
refused
2017-10-03 08:50:49 [System] debug Exception constructed: Network is 
unreachable: :5672 
(/usr/src/packages/BUILD/src/qpid/sys/posix/BSDSocket.cpp:161)
2017-10-03 08:50:49 [System] debug Ignored socket connect exception: Network is 
unreachable: :5672 
(/usr/src/packages/BUILD/src/qpid/sys/posix/BSDSocket.cpp:161)
2017-10-03 08:50:49 [System] debug Exception constructed: No such file or 
directory (/usr/src/packages/BUILD/src/qpid/sys/epoll/EpollPoller.cpp:357)
{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

[jira] [Resolved] (QPIDJMS-333) update ActiveMQ test dependency to 5.15.1

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved QPIDJMS-333.

Resolution: Fixed

> update ActiveMQ test dependency to 5.15.1
> -
>
> Key: QPIDJMS-333
> URL: https://issues.apache.org/jira/browse/QPIDJMS-333
> Project: Qpid JMS
>  Issue Type: Task
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Minor
> Fix For: 0.26.0
>
>
> Update the ActiveMQ test dependency to 5.15.1. In particular this should 
> address the sporadic interop test failures around WebSockets due to 
> containing a fix for AMQ-6801.



--
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-7948) [Java Broker] [AMQP0-9] [Publish Confirms] Client hangs if message sent to topic within no subscribers

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-7948:
--

I don't yet know if this is a client or broker side issue, or both.

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



--
This message was sent by Atlassian JIRA
(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-7948) [Java Broker] [AMQP0-9] [Publish Confirms] Client hangs if message sent to topic within no subscribers

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7948:
-
Component/s: Java Client
 Java Broker

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



--
This message was sent by Atlassian JIRA
(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-7948) [Java Broker] [AMQP0-9] [Publish Confirms] Client hangs if message sent to topic within no subscribers

[Keith Wall (JIRA)]

Keith Wall created QPID-7948:


 Summary: [Java Broker] [AMQP0-9] [Publish Confirms] Client hangs 
if message sent to topic within no subscribers
 Key: QPID-7948
 URL: https://issues.apache.org/jira/browse/QPID-7948
 Project: Qpid
  Issue Type: Bug
Reporter: Keith Wall


Testing on master today, If publish confirms is enabled, if I sent to a topic 
with no subscribers, the client hangs in the following way:

{noformat}
javax.jms.JMSException: Server did not respond in a timely fashion
at 
org.apache.qpid.client.BasicMessageProducer_0_8.sendMessage(BasicMessageProducer_0_8.java:386)
at 
org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:549)
at 
org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:333)
at 
org.apache.qpid.server.security.acl.MessagingACLTest.testPublishToTempTopicSuccess(MessagingACLTest.java:483)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.qpid.test.utils.QpidTestCase.runTest(QpidTestCase.java:181)
at junit.framework.TestCase.runBare(TestCase.java:141)
at 
org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:91)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:165)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{noformat}

Currently, the Broker does not send a nack in this case, but the client awaits 
all the same.




--
This message was sent by Atlassian JIRA
(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-333) update ActiveMQ test dependency to 5.15.1

[ASF subversion and git services (JIRA)]

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

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

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

QPIDJMS-333: update test dep to activemq-5.15.1


> update ActiveMQ test dependency to 5.15.1
> -
>
> Key: QPIDJMS-333
> URL: https://issues.apache.org/jira/browse/QPIDJMS-333
> Project: Qpid JMS
>  Issue Type: Task
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Minor
> Fix For: 0.26.0
>
>
> Update the ActiveMQ test dependency to 5.15.1. In particular this should 
> address the sporadic interop test failures around WebSockets due to 
> containing a fix for AMQ-6801.



--
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-333) update ActiveMQ test dependency to 5.15.1

[Robbie Gemmell (JIRA)]

Robbie Gemmell created QPIDJMS-333:
--

 Summary: update ActiveMQ test dependency to 5.15.1
 Key: QPIDJMS-333
 URL: https://issues.apache.org/jira/browse/QPIDJMS-333
 Project: Qpid JMS
  Issue Type: Task
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
Priority: Minor
 Fix For: 0.26.0


Update the ActiveMQ test dependency to 5.15.1. In particular this should 
address the sporadic interop test failures around WebSockets due to containing 
a fix for AMQ-6801.



--
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-1298) [proton-c] SyncRequestResponseTest.test_allowed_mechs_external is very slow

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell closed PROTON-1298.
--
   Resolution: Fixed
Fix Version/s: (was: proton-c-0.18.0)

No there was nothing particularly interesting about the systems.

Something has changed since, as I can still reproduce this (using a different 
system than before) using 0.14.0 as reported against, but it isn't showing this 
on master for me, nor is it showing in Travis CI any more.

Either the test code or the proton behaviour causing it has has changed in a 
way that resolved this at some point so I'll just close this out (without a 
fix-version as its not important enough to track down).

> [proton-c] SyncRequestResponseTest.test_allowed_mechs_external is very slow
> ---
>
> Key: PROTON-1298
> URL: https://issues.apache.org/jira/browse/PROTON-1298
> Project: Qpid Proton
>  Issue Type: Test
>  Components: proton-c
>Affects Versions: 0.14.0
>Reporter: Robbie Gemmell
>Assignee: Andrew Stitcher
>
> SyncRequestResponseTest.test_allowed_mechs_external is very slow, the tests 
> seem to sit waiting for it to complete for a long time, to the extent it 
> dominates the overall test run time.
> {noformat}
> 2: proton_tests.utils.SyncRequestResponseTest.test_allowed_mechs_external .. 
> start
> 2:   2016-09-08 10:40:22,513 ERROR amqp:connection:framing-error: connection 
> aborted
> 2: proton_tests.utils.SyncRequestResponseTest.test_allowed_mechs_external .. 
> pass
> 2: proton_tests.utils.SyncRequestResponseTest.test_connection_properties ... 
> pass
> 2: proton_tests.utils.SyncRequestResponseTest.test_request_response  
> pass
> 2: Totals: 422 tests, 407 passed, 15 skipped, 0 ignored, 0 failed
>  2/20 Test  #2: python-test ..   Passed  102.36 sec
> {noformat}
> The proton-j run of the python tests skips that particular test, and takes 30 
> seconds in total on the same system.
> The same delay appears to be present on Travis CI as well, with a run of 
> similar commit taking 128ec on the proton-c python tests, so it doesnt seem 
> to be environment specific.



--
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-7564) Add competing consumer test to the performance test suite

[ASF subversion and git services (JIRA)]

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

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

Commit 7fc0721fb5955e700f485e8da6d858762610c0fa 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=7fc0721 ]

QPID-7564: [Java Performance Tests] Change number of consumers to 30 in 
competing consumers performance test


> Add competing consumer test to the performance test suite
> -
>
> Key: QPID-7564
> URL: https://issues.apache.org/jira/browse/QPID-7564
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Performance Tests
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Competing consumers are a very common pattern. We should have a competing 
> consumer test as part of the standard test suite.



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