[jira] [Commented] (DISPATCH-937) schema.validate(attributes) called 4 times before the router starts

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy commented on DISPATCH-937:


[~chug] I added another commit to address your concern. Please re-test and let 
me know if you still see multiple calls to validate. Thank you for reviewing 
the PR.

> schema.validate(attributes) called 4 times before the router starts
> ---
>
> Key: DISPATCH-937
> URL: https://issues.apache.org/jira/browse/DISPATCH-937
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Management Agent
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.2.0
>
> Attachments: dispatch-937-1_vhost-creation-1.txt
>
>
> Start the router with the config file etc/qdrouterd.conf. This config file 
> has one router entity
> {noformat}
> router {
>     mode: interior
>     id: Router.A
> }{noformat}
>  
> The schema.validate is called 4 times on the router entity. It should be 
> called only once
>  
> Here is the traceback of the 4 times it was called -
>  
> {noformat}
> {'type': u'org.apache.qpid.dispatch.router', u'mode': u'standalone', u'id': 
> u'Router.A'}
> File 
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 142, in configure_dispatch
>     config = Config(filename)
> File 
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 41, in __init__
>     self.load(filename, raw_json)
> File 
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 112, in load
>     self.load(f, raw_json)
> File 
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 120, in load
>     self.schema.validate_all(entities)
> File 
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
>  line 576, in validate_all
>     self.validate_add(a, entities)
> File 
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/qdrouter.py",
>  line 53, in validate_add
>     super(QdSchema, self).validate_add(attributes, entities)
> File 
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
>  line 585, in validate_add
>     self.validate_entity(attributes)
> File 
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
>  line 568, in validate_entity
>     entity_type.validate(attributes)
> File 
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
>  line 396, in validate
>     for line in traceback.format_stack():
> File 
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 164, in configure_dispatch
>     configure(config.by_type('router')[0])
> File 
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
>  line 151, in configure
>     agent.configure(attributes)
> File 
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
>  line 855, in configure
>     self._create(attributes)
> File 
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
>  line 828, in _create
>     self.add_entity(entity)
> File 
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
>  line 859, in add_entity
>     self.entities.add(entity)
> File 
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
>  line 519, in add
>     entity.validate()   # Fill in defaults etc.
> File 
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
>  line 171, in validate
>     super(EntityAdapter, self).validate(**kwargs)
> File 
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
>  line 639, in validate
>     self.entity_type.validate(self.attributes)
> File 
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
>  line 396, in validate
>     for line in traceback.format_stack():
> File 
> 

[jira] [Updated] (PROTON-1801) Strip the version from the /usr/share/proton dir

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1801:

Summary: Strip the version from the /usr/share/proton dir  (was: Don't put 
the version in the /usr/share/proton dir)

> Strip the version from the /usr/share/proton dir
> 
>
> Key: PROTON-1801
> URL: https://issues.apache.org/jira/browse/PROTON-1801
> Project: Qpid Proton
>  Issue Type: Task
>  Components: proton-c
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> It's contrary to the dominant convention, and it litters /usr/share with old 
> dirs.



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

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

[jira] [Created] (PROTON-1801) Don't put the version in the /usr/share/proton dir

[Justin Ross (JIRA)]

Justin Ross created PROTON-1801:
---

 Summary: Don't put the version in the /usr/share/proton dir
 Key: PROTON-1801
 URL: https://issues.apache.org/jira/browse/PROTON-1801
 Project: Qpid Proton
  Issue Type: Task
  Components: proton-c
Reporter: Justin Ross
Assignee: Justin Ross
 Fix For: proton-c-0.23.0


It's contrary to the dominant convention, and it litters /usr/share with old 
dirs.



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

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

[jira] [Updated] (QPID-8078) Error compiling with C++11 enabled

[Justin Ross (JIRA)]

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

Justin Ross updated QPID-8078:
--
Summary: Error compiling with C++11 enabled  (was: error by compiling)

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



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

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

[jira] [Resolved] (QPID-8072) Remove the obsolete Ruby management API

[Justin Ross (JIRA)]

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

Justin Ross resolved QPID-8072.
---
Resolution: Fixed

> Remove the obsolete Ruby management API
> ---
>
> Key: QPID-8072
> URL: https://issues.apache.org/jira/browse/QPID-8072
> Project: Qpid
>  Issue Type: Task
>  Components: C++ Broker
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
> Fix For: qpid-cpp-1.38.0
>
>




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

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

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

[Justin Ross (JIRA)]

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

Justin Ross updated QPID-8078:
--
Fix Version/s: (was: qpid-cpp-1.38.0)

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



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

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

[jira] [Updated] (QPID-5824) Add reset method to qpid::messaging::Session

[Justin Ross (JIRA)]

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

Justin Ross updated QPID-5824:
--
Labels:   (was: patch)

> Add reset method to qpid::messaging::Session
> 
>
> Key: QPID-5824
> URL: https://issues.apache.org/jira/browse/QPID-5824
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Client
>Affects Versions: 0.26
>Reporter: Clive Lilley
>Assignee: Gordon Sim
>Priority: Minor
>
> The qpid::messaging API can reconnect to a broker (automatically or manually) 
> and reset any already created sessions using the reconnect functionality. But 
> an edge case exists where the qpid::messaging::Connection has a valid and 
> open connection to the broker, but one or more associated sessions have an 
> error, due to receiving an exception. The only way to fix this situation is 
> to close the Session that is in error and create a new one. This is not 
> always desirable, as the corresponding set of Senders and Receivers would 
> also need closing and recreating. What is really needed is a reset method on 
> the qpid::messaging::Session Class. This would use some of the functionality 
> already provided in the reconnect implementation.



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

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

[jira] [Closed] (QPID-5824) Add reset method to qpid::messaging::Session

[Justin Ross (JIRA)]

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

Justin Ross closed QPID-5824.
-
Resolution: Won't Fix

> Add reset method to qpid::messaging::Session
> 
>
> Key: QPID-5824
> URL: https://issues.apache.org/jira/browse/QPID-5824
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Client
>Affects Versions: 0.26
>Reporter: Clive Lilley
>Assignee: Gordon Sim
>Priority: Minor
>  Labels: patch
>
> The qpid::messaging API can reconnect to a broker (automatically or manually) 
> and reset any already created sessions using the reconnect functionality. But 
> an edge case exists where the qpid::messaging::Connection has a valid and 
> open connection to the broker, but one or more associated sessions have an 
> error, due to receiving an exception. The only way to fix this situation is 
> to close the Session that is in error and create a new one. This is not 
> always desirable, as the corresponding set of Senders and Receivers would 
> also need closing and recreating. What is really needed is a reset method on 
> the qpid::messaging::Session Class. This would use some of the functionality 
> already provided in the reconnect implementation.



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

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

[jira] [Updated] (QPID-5824) Add reset method to qpid::messaging::Session

[Justin Ross (JIRA)]

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

Justin Ross updated QPID-5824:
--
Fix Version/s: (was: Future)

> Add reset method to qpid::messaging::Session
> 
>
> Key: QPID-5824
> URL: https://issues.apache.org/jira/browse/QPID-5824
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Client
>Affects Versions: 0.26
>Reporter: Clive Lilley
>Assignee: Gordon Sim
>Priority: Minor
>  Labels: patch
>
> The qpid::messaging API can reconnect to a broker (automatically or manually) 
> and reset any already created sessions using the reconnect functionality. But 
> an edge case exists where the qpid::messaging::Connection has a valid and 
> open connection to the broker, but one or more associated sessions have an 
> error, due to receiving an exception. The only way to fix this situation is 
> to close the Session that is in error and create a new one. This is not 
> always desirable, as the corresponding set of Senders and Receivers would 
> also need closing and recreating. What is really needed is a reset method on 
> the qpid::messaging::Session Class. This would use some of the functionality 
> already provided in the reconnect implementation.



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

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

[jira] [Commented] (QPID-8129) Remove the obsolete Python management API

[Justin Ross (JIRA)]

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

Justin Ross commented on QPID-8129:
---

https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;a=commit;h=b569b4d6447408c451fc3167af25c41efce81fd1

> Remove the obsolete Python management API
> -
>
> Key: QPID-8129
> URL: https://issues.apache.org/jira/browse/QPID-8129
> Project: Qpid
>  Issue Type: Task
>  Components: C++ Broker
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
> Fix For: qpid-cpp-1.38.0
>
>




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

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

[jira] [Resolved] (QPID-8129) Remove the obsolete Python management API

[Justin Ross (JIRA)]

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

Justin Ross resolved QPID-8129.
---
Resolution: Fixed

> Remove the obsolete Python management API
> -
>
> Key: QPID-8129
> URL: https://issues.apache.org/jira/browse/QPID-8129
> Project: Qpid
>  Issue Type: Task
>  Components: C++ Broker
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
> Fix For: qpid-cpp-1.38.0
>
>




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

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

[jira] [Resolved] (QPID-7821) Missing man pages

[Justin Ross (JIRA)]

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

Justin Ross resolved QPID-7821.
---
Resolution: Fixed

> Missing man pages
> -
>
> Key: QPID-7821
> URL: https://issues.apache.org/jira/browse/QPID-7821
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Documentation
>Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0
>Reporter: Irina Boverman
>Assignee: Justin Ross
>Priority: Minor
> Fix For: qpid-cpp-1.38.0
>
> Attachments: 0001-Added-man-pages.patch
>
>
> Debian distribution requires all binaries to have man pages. These do not:
> ../build.log:W: qpid-receive: binary-without-manpage usr/bin/qpid-receive
> ../build.log:W: qpid-send: binary-without-manpage usr/bin/qpid-send
> ../build.log:W: qmf-gen: binary-without-manpage usr/bin/qmf-gen
> ../build.log:W: qpid-tools: binary-without-manpage usr/bin/qpid-config
> ../build.log:W: qpid-tools: binary-without-manpage usr/bin/qpid-ha
> ../build.log:W: qpid-tools: binary-without-manpage usr/bin/qpid-printevents
> ../build.log:W: qpid-tools: binary-without-manpage usr/bin/qpid-queue-stats
> ../build.log:W: qpid-tools: binary-without-manpage usr/bin/qpid-route
> ../build.log:W: qpid-tools: binary-without-manpage usr/bin/qpid-stat
> ../build.log:W: qpid-tools: binary-without-manpage usr/bin/qpid-tool



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

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

[jira] [Assigned] (QPID-8050) CMake reports CMP0022

[Justin Ross (JIRA)]

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

Justin Ross reassigned QPID-8050:
-

Assignee: Justin Ross

> CMake reports CMP0022
> -
>
> Key: QPID-8050
> URL: https://issues.apache.org/jira/browse/QPID-8050
> Project: Qpid
>  Issue Type: Improvement
>Affects Versions: qpid-cpp-1.37.0
> Environment: Ubuntu 17, cmake version 3.9.1
>Reporter: Chris Richardson
>Assignee: Justin Ross
>Priority: Major
> Fix For: qpid-cpp-1.38.0
>
>
> CMake output: 
> {quote} CMake Deprecation Warning at CMakeLists.txt:138 (cmake_policy):
>The OLD behavior for policy CMP0022 will be removed from a future version
>of CMake.
>The cmake-policies(7) manual explains that the OLD behaviors of all
>policies are deprecated and that a policy should be set to OLD only under
>specific short-term circumstances.  Projects should be ported to the NEW
>behavior and not rely on setting a policy to OLD.{quote}
> Cmake docs on the subject: 
> https://cmake.org/cmake/help/v3.0/policy/CMP0022.html



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

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

[jira] [Created] (PROTON-1800) BlockingConnection descriptor leak

[Andy Smith (JIRA)]

Andy Smith created PROTON-1800:
--

 Summary: BlockingConnection descriptor leak
 Key: PROTON-1800
 URL: https://issues.apache.org/jira/browse/PROTON-1800
 Project: Qpid Proton
  Issue Type: Bug
Affects Versions: proton-c-0.21.0
Reporter: Andy Smith
 Attachments: sync_client.py

Modified collectd python plugin from using persistent connection to connection 
per read. Following change, detected descriptor leak.

Attached modification to sync_client.py exhibits the issue.



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

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

[jira] [Resolved] (PROTON-1799) Remove deprecated binding and APIs, obsolete code

[Justin Ross (JIRA)]

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

Justin Ross resolved PROTON-1799.
-
Resolution: Fixed

> Remove deprecated binding and APIs, obsolete code
> -
>
> Key: PROTON-1799
> URL: https://issues.apache.org/jira/browse/PROTON-1799
> Project: Qpid Proton
>  Issue Type: Task
>  Components: javascript-binding, perl-binding, php-binding, proton-c
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
> Fix For: proton-c-0.22.0
>
>




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

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

[jira] [Updated] (PROTON-342) installing into custom location doesn't work nicely (and is not properly documented)

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-342:
---
Fix Version/s: (was: proton-c-0.22.0)
   proton-c-0.23.0

> installing into custom location doesn't work nicely (and is not properly 
> documented)
> 
>
> Key: PROTON-342
> URL: https://issues.apache.org/jira/browse/PROTON-342
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.4
>Reporter: Gordon Sim
>Assignee: Justin Ross
>Priority: Major
>  Labels: docs
> Fix For: proton-c-0.23.0
>
>
> The README suggests setting -DCMAKE_INSTALL_PREFIX when running cmake, it 
> does not mention setting DESTDIR when invoking make install.
> If you don't set the DESTDIR on make install it will honour the 
> CMAKE_INSTALL_PREFIX for some parts of the installation (e.g. header files, 
> native libraries, pkg-config file etc) but the python bindings (and I assume 
> other bindings) will still install in the standard location which will fail 
> if you are not running as root.
> However if you set DESTDIR then this alters the location of the headers, 
> libraries and pkg-config , which now install into 
> $DESTDIR/$CMAKE_INSTALL_PREFIX and the pkg-config file no longer has the 
> correct include or library paths in it. 



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

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

[jira] [Updated] (PROTON-1728) [proton-c] Reorganize the source tree now that Proton J is split off

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1728:

Fix Version/s: proton-c-0.23.0

> [proton-c] Reorganize the source tree now that Proton J is split off
> 
>
> Key: PROTON-1728
> URL: https://issues.apache.org/jira/browse/PROTON-1728
> Project: Qpid Proton
>  Issue Type: Task
>  Components: proton-c
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
> Fix For: proton-c-0.23.0
>
>




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

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

[jira] [Closed] (PROTON-941) pn_transport_set_server should fail if invoked after binding.

[Justin Ross (JIRA)]

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

Justin Ross closed PROTON-941.
--
Resolution: Won't Fix

> pn_transport_set_server should fail if invoked after binding. 
> --
>
> Key: PROTON-941
> URL: https://issues.apache.org/jira/browse/PROTON-941
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.10
>Reporter: Ken Giusti
>Assignee: Andrew Stitcher
>Priority: Major
>  Labels: api
>
> Transport server configuration needs to be completed before the transport is 
> bound (and before either the transport's SSL or SASL components are created).
> pn_transport_set_server should fail if called too late in the configuration 
> process.



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

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

[jira] [Reopened] (PROTON-941) pn_transport_set_server should fail if invoked after binding.

[Justin Ross (JIRA)]

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

Justin Ross reopened PROTON-941:


> pn_transport_set_server should fail if invoked after binding. 
> --
>
> Key: PROTON-941
> URL: https://issues.apache.org/jira/browse/PROTON-941
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.10
>Reporter: Ken Giusti
>Assignee: Andrew Stitcher
>Priority: Major
>  Labels: api
>
> Transport server configuration needs to be completed before the transport is 
> bound (and before either the transport's SSL or SASL components are created).
> pn_transport_set_server should fail if called too late in the configuration 
> process.



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

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

[jira] [Updated] (PROTON-941) pn_transport_set_server should fail if invoked after binding.

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-941:
---
Fix Version/s: (was: proton-c-future)

> pn_transport_set_server should fail if invoked after binding. 
> --
>
> Key: PROTON-941
> URL: https://issues.apache.org/jira/browse/PROTON-941
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.10
>Reporter: Ken Giusti
>Assignee: Andrew Stitcher
>Priority: Major
>  Labels: api
>
> Transport server configuration needs to be completed before the transport is 
> bound (and before either the transport's SSL or SASL components are created).
> pn_transport_set_server should fail if called too late in the configuration 
> process.



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

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

[jira] [Commented] (QPIDJMS-366) [Failover] JMS commit hangs forever if peer Closes gracefully and failover.maxReconnectAttempts exhausted

[Timothy Bish (JIRA)]

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

Timothy Bish commented on QPIDJMS-366:
--

This should be resolved now if you want to give it another test using the 
current master.

> [Failover] JMS commit hangs forever if peer Closes gracefully and 
> failover.maxReconnectAttempts exhausted
> -
>
> Key: QPIDJMS-366
> URL: https://issues.apache.org/jira/browse/QPIDJMS-366
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.31.0
>
> Attachments: 4b02297_qpid-366.log, HelloWorld.patch
>
>
> If failover occurs whilst a JMS commit is in-flight, and that failover 
> exhausts its {{failover.maxReconnectAttempts}} the JMS commit call is seen to 
> hang forever.  This problem manifests when the connection attempts are 
> failing with a graceful {{Close}} from the peer.  If the connection failure 
> is at a 'transport' level (e.g. Connection refused) the problem does not 
> appear.
> Reproduction:
> # Start Broker-J 7.0.2
> # Go to http://localhost:8080, double click on virtualhost {{default}} in the 
> virtualhost table to open the virtualhost tab.
> # Create queue {{queue}}
> # Start IDE with qpid-jms project open (master today - 7e7cebe5)
> # Apply HelloWorld patch attached to this JIRA
> # Put a breakpoint in 
> {{org.apache.qpid.jms.provider.amqp.AmqpProvider#commit}} line 693 (i.e. the 
> closing brace of the try/catch the statement immediately following the 
> pumpToProton())
> # Run HelloWorld with attached patch applied under the debugger
> # Once the breakpoint is reached, use the console to stop the virtualhost.  
> Do this by clicking the {{Stop}} button on the virtualhost tab.
> # Resume the debugger
> # Expected : once failover attempts are exhausted, the JMS {{commit()}} call 
> should end with an exception - Actual: {{commit()}} continues to hang 
> indefinitely.
> The blocked main thread looks like this:
> {noformat}
> "main@1" prio=5 tid=0x1 nid=NA waiting
>   java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at 
> org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:103)
> at org.apache.qpid.jms.JmsConnection.commit(JmsConnection.java:766)
> at 
> org.apache.qpid.jms.JmsLocalTransactionContext.commit(JmsLocalTransactionContext.java:171)
> at org.apache.qpid.jms.JmsSession.commit(JmsSession.java:227)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:61)
> {noformat}



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

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

[jira] [Updated] (QPIDJMS-366) [Failover] JMS commit hangs forever if peer Closes gracefully and failover.maxReconnectAttempts exhausted

[Timothy Bish (JIRA)]

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

Timothy Bish updated QPIDJMS-366:
-
Fix Version/s: 0.31.0

> [Failover] JMS commit hangs forever if peer Closes gracefully and 
> failover.maxReconnectAttempts exhausted
> -
>
> Key: QPIDJMS-366
> URL: https://issues.apache.org/jira/browse/QPIDJMS-366
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.31.0
>
> Attachments: 4b02297_qpid-366.log, HelloWorld.patch
>
>
> If failover occurs whilst a JMS commit is in-flight, and that failover 
> exhausts its {{failover.maxReconnectAttempts}} the JMS commit call is seen to 
> hang forever.  This problem manifests when the connection attempts are 
> failing with a graceful {{Close}} from the peer.  If the connection failure 
> is at a 'transport' level (e.g. Connection refused) the problem does not 
> appear.
> Reproduction:
> # Start Broker-J 7.0.2
> # Go to http://localhost:8080, double click on virtualhost {{default}} in the 
> virtualhost table to open the virtualhost tab.
> # Create queue {{queue}}
> # Start IDE with qpid-jms project open (master today - 7e7cebe5)
> # Apply HelloWorld patch attached to this JIRA
> # Put a breakpoint in 
> {{org.apache.qpid.jms.provider.amqp.AmqpProvider#commit}} line 693 (i.e. the 
> closing brace of the try/catch the statement immediately following the 
> pumpToProton())
> # Run HelloWorld with attached patch applied under the debugger
> # Once the breakpoint is reached, use the console to stop the virtualhost.  
> Do this by clicking the {{Stop}} button on the virtualhost tab.
> # Resume the debugger
> # Expected : once failover attempts are exhausted, the JMS {{commit()}} call 
> should end with an exception - Actual: {{commit()}} continues to hang 
> indefinitely.
> The blocked main thread looks like this:
> {noformat}
> "main@1" prio=5 tid=0x1 nid=NA waiting
>   java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at 
> org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:103)
> at org.apache.qpid.jms.JmsConnection.commit(JmsConnection.java:766)
> at 
> org.apache.qpid.jms.JmsLocalTransactionContext.commit(JmsLocalTransactionContext.java:171)
> at org.apache.qpid.jms.JmsSession.commit(JmsSession.java:227)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:61)
> {noformat}



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

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

[jira] [Assigned] (QPIDJMS-366) [Failover] JMS commit hangs forever if peer Closes gracefully and failover.maxReconnectAttempts exhausted

[Timothy Bish (JIRA)]

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

Timothy Bish reassigned QPIDJMS-366:


Assignee: Timothy Bish

> [Failover] JMS commit hangs forever if peer Closes gracefully and 
> failover.maxReconnectAttempts exhausted
> -
>
> Key: QPIDJMS-366
> URL: https://issues.apache.org/jira/browse/QPIDJMS-366
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.31.0
>
> Attachments: 4b02297_qpid-366.log, HelloWorld.patch
>
>
> If failover occurs whilst a JMS commit is in-flight, and that failover 
> exhausts its {{failover.maxReconnectAttempts}} the JMS commit call is seen to 
> hang forever.  This problem manifests when the connection attempts are 
> failing with a graceful {{Close}} from the peer.  If the connection failure 
> is at a 'transport' level (e.g. Connection refused) the problem does not 
> appear.
> Reproduction:
> # Start Broker-J 7.0.2
> # Go to http://localhost:8080, double click on virtualhost {{default}} in the 
> virtualhost table to open the virtualhost tab.
> # Create queue {{queue}}
> # Start IDE with qpid-jms project open (master today - 7e7cebe5)
> # Apply HelloWorld patch attached to this JIRA
> # Put a breakpoint in 
> {{org.apache.qpid.jms.provider.amqp.AmqpProvider#commit}} line 693 (i.e. the 
> closing brace of the try/catch the statement immediately following the 
> pumpToProton())
> # Run HelloWorld with attached patch applied under the debugger
> # Once the breakpoint is reached, use the console to stop the virtualhost.  
> Do this by clicking the {{Stop}} button on the virtualhost tab.
> # Resume the debugger
> # Expected : once failover attempts are exhausted, the JMS {{commit()}} call 
> should end with an exception - Actual: {{commit()}} continues to hang 
> indefinitely.
> The blocked main thread looks like this:
> {noformat}
> "main@1" prio=5 tid=0x1 nid=NA waiting
>   java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at 
> org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:103)
> at org.apache.qpid.jms.JmsConnection.commit(JmsConnection.java:766)
> at 
> org.apache.qpid.jms.JmsLocalTransactionContext.commit(JmsLocalTransactionContext.java:171)
> at org.apache.qpid.jms.JmsSession.commit(JmsSession.java:227)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:61)
> {noformat}



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

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

[jira] [Commented] (QPIDJMS-366) [Failover] JMS commit hangs forever if peer Closes gracefully and failover.maxReconnectAttempts exhausted

[ASF subversion and git services (JIRA)]

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

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

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

QPIDJMS-366 Ensure failover honoers maxReconnectAttempts

Fix case when stuck in repeating remote close cycle the failover
transport can ignore the max reconnect limit

> [Failover] JMS commit hangs forever if peer Closes gracefully and 
> failover.maxReconnectAttempts exhausted
> -
>
> Key: QPIDJMS-366
> URL: https://issues.apache.org/jira/browse/QPIDJMS-366
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Reporter: Keith Wall
>Priority: Major
> Fix For: 0.31.0
>
> Attachments: 4b02297_qpid-366.log, HelloWorld.patch
>
>
> If failover occurs whilst a JMS commit is in-flight, and that failover 
> exhausts its {{failover.maxReconnectAttempts}} the JMS commit call is seen to 
> hang forever.  This problem manifests when the connection attempts are 
> failing with a graceful {{Close}} from the peer.  If the connection failure 
> is at a 'transport' level (e.g. Connection refused) the problem does not 
> appear.
> Reproduction:
> # Start Broker-J 7.0.2
> # Go to http://localhost:8080, double click on virtualhost {{default}} in the 
> virtualhost table to open the virtualhost tab.
> # Create queue {{queue}}
> # Start IDE with qpid-jms project open (master today - 7e7cebe5)
> # Apply HelloWorld patch attached to this JIRA
> # Put a breakpoint in 
> {{org.apache.qpid.jms.provider.amqp.AmqpProvider#commit}} line 693 (i.e. the 
> closing brace of the try/catch the statement immediately following the 
> pumpToProton())
> # Run HelloWorld with attached patch applied under the debugger
> # Once the breakpoint is reached, use the console to stop the virtualhost.  
> Do this by clicking the {{Stop}} button on the virtualhost tab.
> # Resume the debugger
> # Expected : once failover attempts are exhausted, the JMS {{commit()}} call 
> should end with an exception - Actual: {{commit()}} continues to hang 
> indefinitely.
> The blocked main thread looks like this:
> {noformat}
> "main@1" prio=5 tid=0x1 nid=NA waiting
>   java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at 
> org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:103)
> at org.apache.qpid.jms.JmsConnection.commit(JmsConnection.java:766)
> at 
> org.apache.qpid.jms.JmsLocalTransactionContext.commit(JmsLocalTransactionContext.java:171)
> at org.apache.qpid.jms.JmsSession.commit(JmsSession.java:227)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:61)
> {noformat}



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

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

[jira] [Updated] (QPIDIT-8) Implement AMQP type array for ProtonPython shim

[Kim van der Riet (JIRA)]

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

Kim van der Riet updated QPIDIT-8:
--
Fix Version/s: 0.2.0

> Implement AMQP type array for ProtonPython shim
> ---
>
> Key: QPIDIT-8
> URL: https://issues.apache.org/jira/browse/QPIDIT-8
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Task
>  Components: Proton Python Shim
>Affects Versions: 0.1.0
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
> Fix For: 0.2.0
>
>
> The AMQP type array has not been implemented in the ProtonPython shim.



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

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

[jira] [Resolved] (QPIDIT-105) Getting started with AMQP.Net Lite in Fedora

[Kim van der Riet (JIRA)]

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

Kim van der Riet resolved QPIDIT-105.
-
Resolution: Fixed

This was a great help, thanks Chuck!

> Getting started with AMQP.Net Lite in Fedora
> 
>
> Key: QPIDIT-105
> URL: https://issues.apache.org/jira/browse/QPIDIT-105
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: New Feature
>  Components: .Net Lite Shim
>Affects Versions: 0.1.0
> Environment: Fedora 25
> mono 4.4.2
>Reporter: Chuck Rolke
>Assignee: Kim van der Riet
>Priority: Major
>
> h4. Introduction
> With package mono version 4.4.2 installed on Fedora the system is capable of 
> compiling and running the AMQP.Net Lite shim tests. The remaining part of the 
> puzzle is acquiring a pre-compiled AMQP.Net Lite executable library. Here's 
> one solution.
> This note is not a feature request so much as it is a blog about one way to 
> do it.
> h4. Fetch AMQP.Net Lite 2.0.0 from NuGet
> Saved as file *get-lite.sh* in the top level directory it may be dot sourced 
> to pick up the definition of AMQPNETLITE_LIB_DIR.
> {noformat}
> #!/bin/bash
> #
> # file: get-lite.sh
> #
> litedir=amqpnetlite-lib-dir
> if [[ ! -d $litedir ]]; then
> mkdir $litedir
> cd$litedir
> wget https://www.nuget.org/api/v2/package/AMQPNetLite/2.0.0
> mv2.0.0 amqpnetlite.2.0.0.nupkg
> unzip   amqpnetlite.2.0.0.nupkg
> cd ..
> fi
> export AMQPNETLITE_LIB_DIR=`pwd`/$litedir/lib/net45
> {noformat}
> .h4 Build qpid-interop-test including AMQP.Net Lite
> Include the Lite library definition in the CMake command line
> {noformat}
> cmake -DAMQPNETLITE_LIB_DIR=${AMQPNETLITE_LIB_DIR} ...
> {noformat}
> Expect confirmation that the Lite library was picked up by CMake
> {noformat}
> -- BUILD_AMQPNETLITE = ON
> {noformat}
> h4. Run test with the AMQP.Net Lite shims
> Define the library location and specify the shims.
> {noformat}
> export 
> AMQPNETLITE_LIB_DIR=${QPID_INTEROP_TEST_HOME}/amqpnetlite-lib-dir/lib/net45
> ./src/python/qpid_interop_test/amqp_types_test.py \
> --include-shim ProtonCpp \
> --include-shim ProtonPython \
> --include-shim AmqpNetLite 
> {noformat}
> h4. Further integration
> This should get you started with the AMQP.Net Lite library. I've tried a few 
> things to auto-detect the library and use it if present. None of those 
> attempts is yet worthy.



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

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

[jira] [Commented] (DISPATCH-938) Doc: Remove the "Configuration Reference"

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-938:
-

Github user bhardesty commented on the issue:

https://github.com/apache/qpid-dispatch/pull/269
  
@enkeys @fgiorgetti  

This PR is ready for doc testing. The changes are simple, so it should be a 
good candidate to start with.


> Doc: Remove the "Configuration Reference"
> -
>
> Key: DISPATCH-938
> URL: https://issues.apache.org/jira/browse/DISPATCH-938
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>Priority: Major
>
> The "Configuration Reference" appendix in the Dispatch Router user guide is 
> outdated and incorrect. It should be removed, and all references to it should 
> be changed to point to the qdrouterd.conf man page.



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

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

[GitHub] qpid-dispatch issue #269: DISPATCH-938: Remove config ref and add links to q...

[bhardesty]

Github user bhardesty commented on the issue:

https://github.com/apache/qpid-dispatch/pull/269
  
@enkeys @fgiorgetti  

This PR is ready for doc testing. The changes are simple, so it should be a 
good candidate to start with.


---

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

[jira] [Commented] (DISPATCH-945) Crash on shutdown when a http+websocket connection is open

[Chuck Rolke (JIRA)]

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

Chuck Rolke commented on DISPATCH-945:
--

Reproducing this issue results in a hang instead of a crash:

{{(gdb) thread apply all bt}}

{{Thread 1 (Thread 0x7f9e2c1d91c0 (LWP 10896)):}}
{{#0  0x7f9e2b6edbca in __pthread_mutex_lock_full () from 
/lib64/libpthread.so.0}}
{{#1  0x7f9e2bd99735 in sys_mutex_lock (mutex=0xcd7000) at 
/home/chug/git/qpid-dispatch/src/posix/threading.c:56}}
{{#2  0x7f9e2bd85431 in qd_link_free (link=0x7f9e100494e0) at 
/home/chug/git/qpid-dispatch/src/container.c:791}}
{{#3  0x7f9e2bdba536 in AMQP_link_detach_handler (context=0xce40c0, 
link=0x7f9e100494e0, dt=QD_LOST)}}
{{    at /home/chug/git/qpid-dispatch/src/router_node.c:730}}
{{#4  0x7f9e2bd838f4 in close_links (container=0xb6de00, 
conn=0x7f9e100162f0, print_log=true)}}
{{    at /home/chug/git/qpid-dispatch/src/container.c:295}}
{{#5  0x7f9e2bd83943 in close_handler (container=0xb6de00, 
conn=0x7f9e100162f0, qd_conn=0x7f9e1000c9e0)}}
{{    at /home/chug/git/qpid-dispatch/src/container.c:308}}
{{#6  0x7f9e2bd84489 in qd_container_handle_event (container=0xb6de00, 
event=0xcd7010) at /home/chug/git/qpid-dispatch/src/container.c:558}}
{{#7  0x7f9e2bdc0abf in handle (qd_server=0xcfef70, e=0xcd7010) at 
/home/chug/git/qpid-dispatch/src/server.c:940}}
{{#8  0x7f9e2bdc24ee in qd_connection_handle (c=0x7f9e1000c9e0, e=0xcd7010) 
at /home/chug/git/qpid-dispatch/src/server.c:1466}}
{{#9  0x7f9e2bdc3c65 in handle_events (c=0x7f9e1000d330) at 
/home/chug/git/qpid-dispatch/src/http-libwebsockets.c:150}}
{{#10 0x7f9e2bdc4aef in callback_amqpws (wsi=0x7f9e1000ab70, 
reason=LWS_CALLBACK_CLOSED, user=0x7f9e1000d330, in=0x0, len=0)}}
{{    at /home/chug/git/qpid-dispatch/src/http-libwebsockets.c:462}}
{{#11 0x7f9e2ac78fa1 in lws_close_free_wsi () from 
/lib64/libwebsockets.so.11}}
{{#12 0x7f9e2ac80879 in lws_context_destroy.part () from 
/lib64/libwebsockets.so.11}}
{{#13 0x7f9e2bdc4e58 in qd_http_server_free (hs=0xb7ce80) at 
/home/chug/git/qpid-dispatch/src/http-libwebsockets.c:533}}
{{#14 0x7f9e2bdc161c in qd_server_free (qd_server=0xcfef70) at 
/home/chug/git/qpid-dispatch/src/server.c:1176}}
{{#15 0x7f9e2bd86656 in qd_dispatch_free (qd=0xa24280) at 
/home/chug/git/qpid-dispatch/src/dispatch.c:307}}
{{#16 0x004016d4 in main_process (}}
{{    config_path=0x7ffc68bc596f 
"/home/chug/Research/qdr/message-copy/gen-test-network/2017-05-16_13-46-48_2/websocket.conf",
 }}
{{    python_pkgdir=0x7ffc68bc59cd "/home/chug/git/qpid-dispatch/python", fd=2) 
at /home/chug/git/qpid-dispatch/router/src/main.c:115}}
{{#17 0x00401fa8 in main (argc=5, argv=0x7ffc68bc3b08) at 
/home/chug/git/qpid-dispatch/router/src/main.c:318}}

> Crash on shutdown when a http+websocket connection is open
> --
>
> Key: DISPATCH-945
> URL: https://issues.apache.org/jira/browse/DISPATCH-945
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 1.0.1
>Reporter: Ted Ross
>Assignee: Chuck Rolke
>Priority: Major
> Fix For: 1.1.0
>
>
> If the router is shut down when there is an active HTTP+websockets 
> connection, the router segfaults.
> This crash appears to be a result of improper shutdown ordering.  When the 
> connection is closed, the container module has already been freed.  This 
> results in the dereferencing of invalid pointers.



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

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

[jira] [Created] (DISPATCH-946) Detect if npm install needs to be executed and display a message

[Ernest Allen (JIRA)]

Ernest Allen created DISPATCH-946:
-

 Summary: Detect if npm install needs to be executed and display a 
message
 Key: DISPATCH-946
 URL: https://issues.apache.org/jira/browse/DISPATCH-946
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Console
Affects Versions: 1.0.1
Reporter: Ernest Allen
Assignee: Ernest Allen


It may be possible to detect if the console is being displayed with first 
running npm install.

If it is possible, a message should be displayed stating that npm install has 
not been run and instruction on how to do so.

 



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

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

[jira] [Commented] (PROTON-1799) Remove deprecated binding and APIs, obsolete code

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1799: Remove obsolete docs and test code


> Remove deprecated binding and APIs, obsolete code
> -
>
> Key: PROTON-1799
> URL: https://issues.apache.org/jira/browse/PROTON-1799
> Project: Qpid Proton
>  Issue Type: Task
>  Components: javascript-binding, perl-binding, php-binding, proton-c
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
> Fix For: proton-c-0.22.0
>
>




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

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

[jira] [Commented] (PROTON-1799) Remove deprecated bindings and APIs

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1799: Remove deprecated bindings and APIs


> Remove deprecated bindings and APIs
> ---
>
> Key: PROTON-1799
> URL: https://issues.apache.org/jira/browse/PROTON-1799
> Project: Qpid Proton
>  Issue Type: Task
>  Components: javascript-binding, perl-binding, php-binding, proton-c
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
> Fix For: proton-c-0.22.0
>
>




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

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

[jira] [Created] (PROTON-1799) Remove deprecated bindings and APIs

[Justin Ross (JIRA)]

Justin Ross created PROTON-1799:
---

 Summary: Remove deprecated bindings and APIs
 Key: PROTON-1799
 URL: https://issues.apache.org/jira/browse/PROTON-1799
 Project: Qpid Proton
  Issue Type: Task
  Components: javascript-binding, perl-binding, php-binding, proton-c
Reporter: Justin Ross
Assignee: Justin Ross
 Fix For: proton-c-0.22.0






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

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

[jira] [Commented] (DISPATCH-933) Introduce a new RouterStats entity and move all stats from the RouterEntity to the RouterStats entity

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-933:
-

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-933 - Created new RouterStats entity. Moved some attributes …

…from Router entity to RouterStats. Router entity is not handled by the 
Python management agent and the RouterStats entity is handled by the C 
management agent

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

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

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

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






> Introduce a new RouterStats entity and move all stats from the RouterEntity 
> to the RouterStats entity
> -
>
> Key: DISPATCH-933
> URL: https://issues.apache.org/jira/browse/DISPATCH-933
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Management Agent
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.1.0
>
>
> Right now all router statistics attributes like deliveriesIngress, 
> rejectedDeliveries, droppedPresettledDeliveries etc. reside in the router 
> entity..
>  
> Router Config Attributes  like saslConfigPath, saslConfigName, 
> helloIntervalSeconds, helloMaxAgeSeconds etc. also reside in the router entity
>  
> When a qdmanage query is issued, the results do not include the router config 
> attributes. This is because the core does not have access to these attributes
>  
> {noformat}
> [gmurthy@localhost qpid-dispatch]$ qdmanage QUERY --type=router
> [
>   {
>     "linkRouteCount": 0,
>     "droppedPresettledDeliveries": 0,
>     "rejectedDeliveries": 0,
>     "autoLinkCount": 0,
>     "id": "Router.A",
>     "presettledDeliveries": 0,
>     "area": "0",
>     "deliveriesIngress": 1,
>     "deliveriesIngressRouteContainer": 0,
>     "acceptedDeliveries": 1,
>     "version": "1.0.0",
>     "linkCount": 2,
>     "connectionCount": 1,
>     "addrCount": 4,
>     "deliveriesEgressRouteContainer": 0,
>     "nodeCount": 0,
>     "modifiedDeliveries": 0,
>     "identity": "1",
>     "deliveriesEgress": 0,
>     "releasedDeliveries": 0,
>     "name": "Router.A",
>     "type": "org.apache.qpid.dispatch.router",
>     "deliveriesTransit": 0,
>     "mode": "standalone"
>   }
> ]
> {noformat}
>  
> The solution to this problem is to create a new entity called RouterStats and 
> move all the statistics related attributes to RouterStats. This RouterStats 
> entity will be handled by the C management agent.
>  
> The old Router entity which is currently handled by the C agent will be 
> handled by the Python agent instead.



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

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

[GitHub] qpid-dispatch pull request #270: DISPATCH-933 - Created new RouterStats enti...

[ganeshmurthy]

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-933 - Created new RouterStats entity. Moved some attributes …

…from Router entity to RouterStats. Router entity is not handled by the 
Python management agent and the RouterStats entity is handled by the C 
management agent

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

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

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

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






---

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

[jira] [Commented] (QPIDIT-46) Correctly encode AMQP types within complex types list and map

[ASF subversion and git services (JIRA)]

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

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

Commit b87dc72a330724d6d888d87faa567d003a2e5c07 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=b87dc72 ]

QPIDIT-46: Added encoding for AMQP list and map types, and which can contain 
other lists and maps. This has been completed on the ProtonCpp and 
ProtonPython{2,3} shims, and RheaJs and AmqpNetLite have this test disabled for 
now.


> Correctly encode AMQP types within complex types list and map
> -
>
> Key: QPIDIT-46
> URL: https://issues.apache.org/jira/browse/QPIDIT-46
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Bug
>  Components: AMQP Types Test, Proton C++ Shim, Proton Python Shim, 
> Rhea JavaScript Shim
>Affects Versions: 0.1.0
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> Currently the AMQP type tests for list and map are using only strings. An 
> extra step for encoding/decoding these on the Sender/Receiver shims are 
> needed. At present, the list and map keys and elements are created using a 
> string format {{"type:value"}}, but these are simply being used as-is as 
> string literals.
> Currently all shim tests for these types pass.



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

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

[jira] [Resolved] (QPID-8124) [Broker-J][REST] Sucessfully authenticated user is reported as <> in ACL operational logs when checking access to management

[Keith Wall (JIRA)]

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

Keith Wall resolved QPID-8124.
--
Resolution: Fixed

Merged to 7.0.x branch.

> [Broker-J][REST] Sucessfully authenticated user is reported as <> in 
> ACL operational logs when checking access to management
> -
>
> Key: QPID-8124
> URL: https://issues.apache.org/jira/browse/QPID-8124
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0, 
> qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.3
>
>
> When user is successfully authenticated, the user information  in operational 
> log for checking management access is reported as <> for both 
> Allowed and Denied outcomes:
> {noformat}
> INFO  [qtp1675859208-228] (q.m.a.denied) - <> ACL-1002 : Denied : 
> Access Management 
> INFO  [qtp1675859208-64] (q.m.a.allowed) - <> ACL-1001 : Allowed : 
> Access Management 
> INFO  [qtp1675859208-64] (q.m.m.open) - 
> [mng:nyXoe7Io(admin@/127.0.0.1:45666)] MNG-1007 : Open : User admin
> {noformat}
> As result, it is impossible to identify the principal name of authenticated 
> user in operational log when access is denied. 
> Thought, it is possible to get the principal name for "allowed" outcome by 
> looking into the following logs from the same thread, it would be beneficial 
> to print the real principal information in the log for Allowed outcome.



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

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

[jira] [Commented] (QPID-8124) [Broker-J][REST] Sucessfully authenticated user is reported as <> in ACL operational logs when checking access to management

[ASF subversion and git services (JIRA)]

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

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

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

QPID-8124: [Broker-J] Fix ACL logging on checking web management console access 
after REST SASL authentication


> [Broker-J][REST] Sucessfully authenticated user is reported as <> in 
> ACL operational logs when checking access to management
> -
>
> Key: QPID-8124
> URL: https://issues.apache.org/jira/browse/QPID-8124
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0, 
> qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.3
>
>
> When user is successfully authenticated, the user information  in operational 
> log for checking management access is reported as <> for both 
> Allowed and Denied outcomes:
> {noformat}
> INFO  [qtp1675859208-228] (q.m.a.denied) - <> ACL-1002 : Denied : 
> Access Management 
> INFO  [qtp1675859208-64] (q.m.a.allowed) - <> ACL-1001 : Allowed : 
> Access Management 
> INFO  [qtp1675859208-64] (q.m.m.open) - 
> [mng:nyXoe7Io(admin@/127.0.0.1:45666)] MNG-1007 : Open : User admin
> {noformat}
> As result, it is impossible to identify the principal name of authenticated 
> user in operational log when access is denied. 
> Thought, it is possible to get the principal name for "allowed" outcome by 
> looking into the following logs from the same thread, it would be beneficial 
> to print the real principal information in the log for Allowed outcome.



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

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

[jira] [Commented] (QPID-8124) [Broker-J][REST] Sucessfully authenticated user is reported as <> in ACL operational logs when checking access to management

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-8124:
--

Changes look reasonable to me.  Verified both the interactive and preemptive 
authentication paths.

> [Broker-J][REST] Sucessfully authenticated user is reported as <> in 
> ACL operational logs when checking access to management
> -
>
> Key: QPID-8124
> URL: https://issues.apache.org/jira/browse/QPID-8124
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0, 
> qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.3
>
>
> When user is successfully authenticated, the user information  in operational 
> log for checking management access is reported as <> for both 
> Allowed and Denied outcomes:
> {noformat}
> INFO  [qtp1675859208-228] (q.m.a.denied) - <> ACL-1002 : Denied : 
> Access Management 
> INFO  [qtp1675859208-64] (q.m.a.allowed) - <> ACL-1001 : Allowed : 
> Access Management 
> INFO  [qtp1675859208-64] (q.m.m.open) - 
> [mng:nyXoe7Io(admin@/127.0.0.1:45666)] MNG-1007 : Open : User admin
> {noformat}
> As result, it is impossible to identify the principal name of authenticated 
> user in operational log when access is denied. 
> Thought, it is possible to get the principal name for "allowed" outcome by 
> looking into the following logs from the same thread, it would be beneficial 
> to print the real principal information in the log for Allowed outcome.



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

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

[jira] [Updated] (DISPATCH-933) Introduce a new RouterStats entity and move all stats from the RouterEntity to the RouterStats entity

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy updated DISPATCH-933:
---
Fix Version/s: (was: 1.2.0)
   1.1.0

> Introduce a new RouterStats entity and move all stats from the RouterEntity 
> to the RouterStats entity
> -
>
> Key: DISPATCH-933
> URL: https://issues.apache.org/jira/browse/DISPATCH-933
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Management Agent
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.1.0
>
>
> Right now all router statistics attributes like deliveriesIngress, 
> rejectedDeliveries, droppedPresettledDeliveries etc. reside in the router 
> entity..
>  
> Router Config Attributes  like saslConfigPath, saslConfigName, 
> helloIntervalSeconds, helloMaxAgeSeconds etc. also reside in the router entity
>  
> When a qdmanage query is issued, the results do not include the router config 
> attributes. This is because the core does not have access to these attributes
>  
> {noformat}
> [gmurthy@localhost qpid-dispatch]$ qdmanage QUERY --type=router
> [
>   {
>     "linkRouteCount": 0,
>     "droppedPresettledDeliveries": 0,
>     "rejectedDeliveries": 0,
>     "autoLinkCount": 0,
>     "id": "Router.A",
>     "presettledDeliveries": 0,
>     "area": "0",
>     "deliveriesIngress": 1,
>     "deliveriesIngressRouteContainer": 0,
>     "acceptedDeliveries": 1,
>     "version": "1.0.0",
>     "linkCount": 2,
>     "connectionCount": 1,
>     "addrCount": 4,
>     "deliveriesEgressRouteContainer": 0,
>     "nodeCount": 0,
>     "modifiedDeliveries": 0,
>     "identity": "1",
>     "deliveriesEgress": 0,
>     "releasedDeliveries": 0,
>     "name": "Router.A",
>     "type": "org.apache.qpid.dispatch.router",
>     "deliveriesTransit": 0,
>     "mode": "standalone"
>   }
> ]
> {noformat}
>  
> The solution to this problem is to create a new entity called RouterStats and 
> move all the statistics related attributes to RouterStats. This RouterStats 
> entity will be handled by the C management agent.
>  
> The old Router entity which is currently handled by the C agent will be 
> handled by the Python agent instead.



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

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

[jira] [Commented] (QPID-7197) [Broker-J] Prevent deletion of objects that are in use

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-7197:
--

As discussed, I don't think the change looks right:
 * it should be possible to delete a sub-tree where two or more of the nodes 
*within* the sub-tree being deleted have references to each other.
 * the tree traversal code needs to respect the model discontinuities.

 

> [Broker-J] Prevent deletion of objects that are in use
> --
>
> Key: QPID-7197
> URL: https://issues.apache.org/jira/browse/QPID-7197
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments: 
> 0001-QPID-7197-Broker-J-Generalize-a-validation-of-refere.patch
>
>
> Enhance the facilities of the CO framework to prevent the deletion of the 
> objects that are in use elsewhere in the model.  Specifically this means 
> searching for other COs that have an attribute that refers to the object that 
> is about to be deleted,.  



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

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

[jira] [Updated] (PROTON-1790) [ruby] Link name is not generated in open_sender when using hash as parameter

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1790:

Fix Version/s: proton-c-0.22.0

> [ruby] Link name is not generated in open_sender when using hash as parameter
> -
>
> Key: PROTON-1790
> URL: https://issues.apache.org/jira/browse/PROTON-1790
> Project: Qpid Proton
>  Issue Type: Bug
>Affects Versions: proton-c-0.21.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.22.0
>
>
> See https://issues.jboss.org/browse/ENTMQCL-645
> When using:
> container.connect(...).open_sender("")
> Link name is generated and used in attach phase (trace).
> [0x1a41270]:0 -> @attach(18) [name="f32b20d8-236e-4d21-9f0d-50afd0e5a6ad/1", 
> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, 
> source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) 
> [address="", durable=0, timeout=0, dynamic=false], 
> initial-delivery-count=0, max-message-size=0]
> When using:
> container.connect(...).open_sender({:target => ""})
> Link name is NOT generated and is empty in attach phase (trace).
> [0x199f3c0]:0 -> @attach(18) [handle=0, role=false, snd-settle-mode=2, 
> rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], 
> target=@target(41) [address="", durable=0, timeout=0, 
> dynamic=false], initial-delivery-count=0, max-message-size=0]
> Link name is mandatory. If link name is not set, broker immediately closes 
> the connection.



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

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

[jira] [Resolved] (DISPATCH-931) Syntax error and missing dependencies in docker files

[Ken Giusti (JIRA)]

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

Ken Giusti resolved DISPATCH-931.
-
Resolution: Fixed

> Syntax error and missing dependencies in docker files
> -
>
> Key: DISPATCH-931
> URL: https://issues.apache.org/jira/browse/DISPATCH-931
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 1.0.0, 1.0.1
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.1.0
>
>
> Need to add unittest2 dependency and fix a syntax error



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

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

[jira] [Updated] (PROTON-1789) [ruby] `pre_encode': undefined method `symbol_keys!' for Qpid::Proton::Types:Module (NoMethodError)

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1789:

Fix Version/s: proton-c-0.22.0

> [ruby] `pre_encode': undefined method `symbol_keys!' for 
> Qpid::Proton::Types:Module (NoMethodError)
> ---
>
> Key: PROTON-1789
> URL: https://issues.apache.org/jira/browse/PROTON-1789
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Affects Versions: proton-c-0.22.0
> Environment: $ ruby --version
> ruby 2.5.0p0 (2017-12-25) [x86_64-linux]
> commit f1100fea2b67538b277d2f4c60f795de1320c6a3 (upstream/master)
> Author: Alan Conway 
> Date:   Wed Mar 7 23:48:25 2018 -0500
> NO-JIRA: [ruby] extra URI tests, better exception message.
>Reporter: Jiri Daněk
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.22.0
>
>
> When sending a message with message properties set, the following exception 
> is thrown
> {noformat}
> % ruby bin/cli-proton-ruby-sender --msg-property=key1~10.5 :(
> Traceback (most% ruby bin/cli-proton-ruby-sender --msg-property=key1~10.5 :(
> Traceback (most recent call last):
> 15: from bin/cli-proton-ruby-sender:21:in `'
> 14: from bin/cli-proton-ruby-sender:21:in `new'
> 13: from /home/jdanek/Work/repos/cli-proton-ruby/lib/sender_client.rb:52:in 
> `initialize'
> 12: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/core/container.rb:263:in
>  `run'
> 11: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/core/connection_driver.rb:196:in
>  `process'
> 10: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/core/connection_driver.rb:180:in
>  `dispatch'
> 9: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/core/connection_driver.rb:78:in
>  `each_event'
> 8: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/core/connection_driver.rb:185:in
>  `block in dispatch'
> 7: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/core/event.rb:94:in 
> `dispatch'
> 6: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/handler/messaging_adapter.rb:131:in
>  `on_link_flow'
> 5: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/handler/messaging_adapter.rb:27:in
>  `delegate'
> 4: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/handler/adapter.rb:74:in
>  `forward'
> 3: from 
> /home/jdanek/Work/repos/cli-proton-ruby/lib/handlers/sender_handler.rb:165:in 
> `on_sendable'
> 2: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/core/sender.rb:76:in 
> `send'
> 1: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/core/message.rb:60:in
>  `encode'
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/core/message.rb:77:in
>  `pre_encode': undefined method `symbol_keys!' for Qpid::Proton::Types:Module 
> (NoMethodError)
>  recent call last):
> 15: from bin/cli-proton-ruby-sender:21:in `'
> 14: from bin/cli-proton-ruby-sender:21:in `new'
> 13: from /home/jdanek/Work/repos/cli-proton-ruby/lib/sender_client.rb:52:in 
> `initialize'
> 12: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/core/container.rb:263:in
>  `run'
> 11: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/core/connection_driver.rb:196:in
>  `process'
> 10: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/core/connection_driver.rb:180:in
>  `dispatch'
> 9: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/core/connection_driver.rb:78:in
>  `each_event'
> 8: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/core/connection_driver.rb:185:in
>  `block in dispatch'
> 7: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/core/event.rb:94:in 
> `dispatch'
> 6: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/handler/messaging_adapter.rb:131:in
>  `on_link_flow'
> 5: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/handler/messaging_adapter.rb:27:in
>  `delegate'
> 4: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/handler/adapter.rb:74:in
>  `forward'
> 3: from 
> /home/jdanek/Work/repos/cli-proton-ruby/lib/handlers/sender_handler.rb:165:in 
> `on_sendable'
> 2: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/core/sender.rb:76:in 
> `send'
> 1: from 
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/core/message.rb:60:in
>  `encode'
> /home/jdanek/.gem/ruby/2.5.0/gems/qpid_proton-0.22.0/lib/core/message.rb:77:in
>  `pre_encode': undefined method `symbol_keys!' for Qpid::Proton::Types:Module 
> (NoMethodError)
> {noformat}



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

[jira] [Commented] (DISPATCH-933) Introduce a new RouterStats entity and move all stats from the RouterEntity to the RouterStats entity

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-933:
-

Github user ganeshmurthy closed the pull request at:

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


> Introduce a new RouterStats entity and move all stats from the RouterEntity 
> to the RouterStats entity
> -
>
> Key: DISPATCH-933
> URL: https://issues.apache.org/jira/browse/DISPATCH-933
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Management Agent
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.2.0
>
>
> Right now all router statistics attributes like deliveriesIngress, 
> rejectedDeliveries, droppedPresettledDeliveries etc. reside in the router 
> entity..
>  
> Router Config Attributes  like saslConfigPath, saslConfigName, 
> helloIntervalSeconds, helloMaxAgeSeconds etc. also reside in the router entity
>  
> When a qdmanage query is issued, the results do not include the router config 
> attributes. This is because the core does not have access to these attributes
>  
> {noformat}
> [gmurthy@localhost qpid-dispatch]$ qdmanage QUERY --type=router
> [
>   {
>     "linkRouteCount": 0,
>     "droppedPresettledDeliveries": 0,
>     "rejectedDeliveries": 0,
>     "autoLinkCount": 0,
>     "id": "Router.A",
>     "presettledDeliveries": 0,
>     "area": "0",
>     "deliveriesIngress": 1,
>     "deliveriesIngressRouteContainer": 0,
>     "acceptedDeliveries": 1,
>     "version": "1.0.0",
>     "linkCount": 2,
>     "connectionCount": 1,
>     "addrCount": 4,
>     "deliveriesEgressRouteContainer": 0,
>     "nodeCount": 0,
>     "modifiedDeliveries": 0,
>     "identity": "1",
>     "deliveriesEgress": 0,
>     "releasedDeliveries": 0,
>     "name": "Router.A",
>     "type": "org.apache.qpid.dispatch.router",
>     "deliveriesTransit": 0,
>     "mode": "standalone"
>   }
> ]
> {noformat}
>  
> The solution to this problem is to create a new entity called RouterStats and 
> move all the statistics related attributes to RouterStats. This RouterStats 
> entity will be handled by the C management agent.
>  
> The old Router entity which is currently handled by the C agent will be 
> handled by the Python agent instead.



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

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

[GitHub] qpid-dispatch pull request #263: DISPATCH-933 - Created new RouterStats enti...

[ganeshmurthy]

Github user ganeshmurthy closed the pull request at:

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


---

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

[jira] [Created] (QPID-8138) [Broker-J] Report authenticated user principals and groups as part of ACL and/or operational logging

[Alex Rudyy (JIRA)]

Alex Rudyy created QPID-8138:


 Summary: [Broker-J] Report authenticated user principals and 
groups as part of ACL and/or operational logging
 Key: QPID-8138
 URL: https://issues.apache.org/jira/browse/QPID-8138
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J
Reporter: Alex Rudyy


Authenticated user principals and groups can be logged part of ACL and/or 
operational in order to simplify an investigation of ACL related issues



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

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

[jira] [Updated] (QPID-8124) [Broker-J][REST] Sucessfully authenticated user is reported as <> in ACL operational logs when checking access to management

[Alex Rudyy (JIRA)]

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

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

> [Broker-J][REST] Sucessfully authenticated user is reported as <> in 
> ACL operational logs when checking access to management
> -
>
> Key: QPID-8124
> URL: https://issues.apache.org/jira/browse/QPID-8124
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0, 
> qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.3
>
>
> When user is successfully authenticated, the user information  in operational 
> log for checking management access is reported as <> for both 
> Allowed and Denied outcomes:
> {noformat}
> INFO  [qtp1675859208-228] (q.m.a.denied) - <> ACL-1002 : Denied : 
> Access Management 
> INFO  [qtp1675859208-64] (q.m.a.allowed) - <> ACL-1001 : Allowed : 
> Access Management 
> INFO  [qtp1675859208-64] (q.m.m.open) - 
> [mng:nyXoe7Io(admin@/127.0.0.1:45666)] MNG-1007 : Open : User admin
> {noformat}
> As result, it is impossible to identify the principal name of authenticated 
> user in operational log when access is denied. 
> Thought, it is possible to get the principal name for "allowed" outcome by 
> looking into the following logs from the same thread, it would be beneficial 
> to print the real principal information in the log for Allowed outcome.



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

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

[jira] [Commented] (QPID-8124) [Broker-J][REST] Sucessfully authenticated user is reported as <> in ACL operational logs when checking access to management

[ASF subversion and git services (JIRA)]

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

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

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

QPID-8124: [Broker-J] Fix ACL logging on checking web management console access 
after REST SASL authentication


> [Broker-J][REST] Sucessfully authenticated user is reported as <> in 
> ACL operational logs when checking access to management
> -
>
> Key: QPID-8124
> URL: https://issues.apache.org/jira/browse/QPID-8124
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0, 
> qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.3
>
>
> When user is successfully authenticated, the user information  in operational 
> log for checking management access is reported as <> for both 
> Allowed and Denied outcomes:
> {noformat}
> INFO  [qtp1675859208-228] (q.m.a.denied) - <> ACL-1002 : Denied : 
> Access Management 
> INFO  [qtp1675859208-64] (q.m.a.allowed) - <> ACL-1001 : Allowed : 
> Access Management 
> INFO  [qtp1675859208-64] (q.m.m.open) - 
> [mng:nyXoe7Io(admin@/127.0.0.1:45666)] MNG-1007 : Open : User admin
> {noformat}
> As result, it is impossible to identify the principal name of authenticated 
> user in operational log when access is denied. 
> Thought, it is possible to get the principal name for "allowed" outcome by 
> looking into the following logs from the same thread, it would be beneficial 
> to print the real principal information in the log for Allowed outcome.



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

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

[jira] [Updated] (DISPATCH-939) Router aborts transfer, closes connection with error on QIT amqp_large_contnet_test

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-939:
--
Fix Version/s: 1.1.0

> Router aborts transfer, closes connection with error on QIT 
> amqp_large_contnet_test
> ---
>
> Key: DISPATCH-939
> URL: https://issues.apache.org/jira/browse/DISPATCH-939
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Kim van der Riet
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: dispatch.multiframe.06.pcapng, qdrouterd.conf
>
>
> The Qpid Interop Test large content test repeatedly fails when run against a 
> single-node dispatch router (dispatch config file attached).
> The test that reproduces this most readily but without too much length is the 
> following:
> {noformat}
> python -m qpid_interop_test.amqp_large_content_test --include-shim ProtonCpp 
> --include-type list
> WARNING: Rhea Javascript shims not found
> Test Broker: qpid-dispatch-router v.1.0.0 on 
> test_list_ProtonCpp->ProtonCpp (__main__.ListTestCase) ... ERROR
> ==
> ERROR: test_list_ProtonCpp->ProtonCpp (__main__.ListTestCase)
> --
> Traceback (most recent call last):
> File 
> "/home/kvdr/RedHat/install/lib/python2.7/site-packages/qpid_interop_test/amqp_large_content_test.py",
>  line 196, in inner_test_method
> timeout)
> File 
> "/home/kvdr/RedHat/install/lib/python2.7/site-packages/qpid_interop_test/amqp_large_content_test.py",
>  line 121, in run_test
> raise InteropTestError('Receive shim \'%s\':\n%s' % (receive_shim.NAME, 
> receive_obj))
> InteropTestError: Receive shim 'ProtonCpp':
> amqp_large_content_test receiver error: receiver read failure
> --
> Ran 1 test in 0.801s
> FAILED (errors=1)
> {noformat}
> The router left the following message:
> {noformat}
> SERVER (info) Connection from ::1:57020 (to ::1:amqp) failed: 
> amqp:connection:framing-error connection aborted{noformat}
> The attached capture file shows a typical observable sequence of events on 
> the wire that lead up to the failure. The test that created this error 
> consists of 4 messages:
>  # A 1MB message consisting of a list containing a single 1MB string 
> (delivery-id 0);
>  # A 1MB message consisting of a list containing 16 64kB strings (delivery-id 
> 1);
>  # A 10MB message consisting of a list containing a single 10MB string 
> (delivery-id 2);
>  # A 10MB message consisting of a list containing 16 655MB strings 
> (delivery-id 3).
> The following is a summary of what transpires:
>  * *Frame 1527:* The sender completes sending the last message (delivery-id 
> 3) to the router, and closes the connection (without waiting for 
> dispositions). At this point, the receiver is in the process of being sent 
> message-id 2.
>  * *Frame 1539:* Last transfer for message-id 2 from dispatch to receiver.
>  * *Frame 1545 - 1598:* Message-id 3 starts being sent to receiver.
>  * *Frame 1600:* Dispatch router returns close to sender (initiated in *frame 
> 1527*). No errors or arguments.
>  * *Frame 1605:* Receiver sends flow, disposition for delivery-id 2 
> (completed in *frame 1539*).
>  * *Frame 1607 - 1618:* Continue to send message with delivery-id 3 to 
> receiver.
>  * *Frame 1619:* Transfer aborted. A transfer performative with more=False, 
> Settled=True, Aborted=True.
>  * *Frame 1622:* Close sent from Dispatch to Receiver with Condition: 
> {{amqp:connection:framing-error}}, Description: {{connection aborted}}.
> All instances of this error have occurred between dispatch router and the 
> receiver once the sender has closed its connection.
>  



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

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

[jira] [Updated] (DISPATCH-939) Router aborts transfer, closes connection with error on QIT amqp_large_contnet_test

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-939:
--
Priority: Critical  (was: Major)

> Router aborts transfer, closes connection with error on QIT 
> amqp_large_contnet_test
> ---
>
> Key: DISPATCH-939
> URL: https://issues.apache.org/jira/browse/DISPATCH-939
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Kim van der Riet
>Priority: Critical
> Attachments: dispatch.multiframe.06.pcapng, qdrouterd.conf
>
>
> The Qpid Interop Test large content test repeatedly fails when run against a 
> single-node dispatch router (dispatch config file attached).
> The test that reproduces this most readily but without too much length is the 
> following:
> {noformat}
> python -m qpid_interop_test.amqp_large_content_test --include-shim ProtonCpp 
> --include-type list
> WARNING: Rhea Javascript shims not found
> Test Broker: qpid-dispatch-router v.1.0.0 on 
> test_list_ProtonCpp->ProtonCpp (__main__.ListTestCase) ... ERROR
> ==
> ERROR: test_list_ProtonCpp->ProtonCpp (__main__.ListTestCase)
> --
> Traceback (most recent call last):
> File 
> "/home/kvdr/RedHat/install/lib/python2.7/site-packages/qpid_interop_test/amqp_large_content_test.py",
>  line 196, in inner_test_method
> timeout)
> File 
> "/home/kvdr/RedHat/install/lib/python2.7/site-packages/qpid_interop_test/amqp_large_content_test.py",
>  line 121, in run_test
> raise InteropTestError('Receive shim \'%s\':\n%s' % (receive_shim.NAME, 
> receive_obj))
> InteropTestError: Receive shim 'ProtonCpp':
> amqp_large_content_test receiver error: receiver read failure
> --
> Ran 1 test in 0.801s
> FAILED (errors=1)
> {noformat}
> The router left the following message:
> {noformat}
> SERVER (info) Connection from ::1:57020 (to ::1:amqp) failed: 
> amqp:connection:framing-error connection aborted{noformat}
> The attached capture file shows a typical observable sequence of events on 
> the wire that lead up to the failure. The test that created this error 
> consists of 4 messages:
>  # A 1MB message consisting of a list containing a single 1MB string 
> (delivery-id 0);
>  # A 1MB message consisting of a list containing 16 64kB strings (delivery-id 
> 1);
>  # A 10MB message consisting of a list containing a single 10MB string 
> (delivery-id 2);
>  # A 10MB message consisting of a list containing 16 655MB strings 
> (delivery-id 3).
> The following is a summary of what transpires:
>  * *Frame 1527:* The sender completes sending the last message (delivery-id 
> 3) to the router, and closes the connection (without waiting for 
> dispositions). At this point, the receiver is in the process of being sent 
> message-id 2.
>  * *Frame 1539:* Last transfer for message-id 2 from dispatch to receiver.
>  * *Frame 1545 - 1598:* Message-id 3 starts being sent to receiver.
>  * *Frame 1600:* Dispatch router returns close to sender (initiated in *frame 
> 1527*). No errors or arguments.
>  * *Frame 1605:* Receiver sends flow, disposition for delivery-id 2 
> (completed in *frame 1539*).
>  * *Frame 1607 - 1618:* Continue to send message with delivery-id 3 to 
> receiver.
>  * *Frame 1619:* Transfer aborted. A transfer performative with more=False, 
> Settled=True, Aborted=True.
>  * *Frame 1622:* Close sent from Dispatch to Receiver with Condition: 
> {{amqp:connection:framing-error}}, Description: {{connection aborted}}.
> All instances of this error have occurred between dispatch router and the 
> receiver once the sender has closed its connection.
>  



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

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

[jira] [Commented] (PROTON-1160) [Python binding] decimal32 and decimal64 are sent byte reversed

[Kim van der Riet (JIRA)]

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

Kim van der Riet commented on PROTON-1160:
--

Proton Python uses the following types as the parent classes for the decimal 
types:
{noformat}
class decimal32(int): ...
class decimal64(long): ...
class decimal128(bytes): ...{noformat}
but there is a disconnect between these types and an actual decimal value to 
send. Using this approach avoids the issue of how to encode a numeric decimal 
value, and leaves the problem to the user who must convert it to an equivalent 
byte sequence of the correct length.

Qpid Interop Test uses hex values and tests that they are successfully sent and 
received, but this does not test any type of encoding or decoding of a decimal.

The AMQP 1.0 spec simply states that these numbers are decimal 32/64/128-bit 
numbers (IEEE 754-2008 decimal32/64/128).

The C++ bindings use the following:
{noformat}
class decimal32 : public byte_array<4> {};
class decimal64 : public byte_array<8> {};
class decimal128 : public byte_array<16> {};{noformat}
but to my knowledge also does not provide encoding from a decimal number to the 
byte array format.

At some point, we need to extend the APIs to provide useful encoding/decoding 
for these types.

> [Python binding] decimal32 and decimal64 are sent byte reversed
> ---
>
> Key: PROTON-1160
> URL: https://issues.apache.org/jira/browse/PROTON-1160
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> When sending {{decimal32}} and {{decimal64}} types to or from the Python 
> binding, the byte order of the numbers are reversed. This does not apply to 
> the {{decimal128}} type.
> It is noteworthy that this bug was exposed by qpid-interop-test when run 
> against the C++ binding.  In C++, these types are all based on a byte array, 
> whereas in the Python binding, {{decimal32}} and {{decimal64}} are derived 
> from Python types {{int}} and {{long}} respectively, while {{decimal128}} is 
> derived from Python type {{bytes}}.
> Decimal32:
> {noformat}
> sent:['0x', '0x40490fdb', '0xc02df854', '0xff7f']
> received:['0x', '0xdb0f4940', '0x54f82dc0', '0x7fff']
> {noformat}
> Decimal64:
> {noformat}
> sent:['0x', '0x400921fb54442eea', '0xc005bf0a8b145fcf', 
> '0xffef']
> received:['0x', '0xea2e4454fb210940', '0xcf5f148b0abf05c0', 
> '0xefff']
> {noformat}



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

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

[jira] [Updated] (DISPATCH-942) allow resumable link routes to be refused

[Gordon Sim (JIRA)]

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

Gordon Sim updated DISPATCH-942:

Fix Version/s: 1.1.0

> allow resumable link routes to be refused
> -
>
> Key: DISPATCH-942
> URL: https://issues.apache.org/jira/browse/DISPATCH-942
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Major
> Fix For: 1.1.0
>
>
> If link routing through a router network to a set of brokers, it is possible 
> that the client asks for e/g/ a durable subscription - i.e.a link whose 
> terminus state should survive the client being disconnected. However in some 
> deployments it may not be possible (or desirable to keep the necessary state 
> to do so) to reroute the link back to the same broker on the client 
> reconnecting. In such cases, it would be desirable to be able to configure 
> the router such that it refuses to link route such link requests to avoid 
> mis-set expectations and potentially having stale subscriptions growing.



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

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

[jira] [Assigned] (DISPATCH-945) Crash on shutdown when a http+websocket connection is open

[Chuck Rolke (JIRA)]

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

Chuck Rolke reassigned DISPATCH-945:


Assignee: Chuck Rolke

> Crash on shutdown when a http+websocket connection is open
> --
>
> Key: DISPATCH-945
> URL: https://issues.apache.org/jira/browse/DISPATCH-945
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 1.0.1
>Reporter: Ted Ross
>Assignee: Chuck Rolke
>Priority: Major
> Fix For: 1.1.0
>
>
> If the router is shut down when there is an active HTTP+websockets 
> connection, the router segfaults.
> This crash appears to be a result of improper shutdown ordering.  When the 
> connection is closed, the container module has already been freed.  This 
> results in the dereferencing of invalid pointers.



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

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

[jira] [Assigned] (QPID-8124) [Broker-J][REST] Sucessfully authenticated user is reported as <> in ACL operational logs when checking access to management

[Alex Rudyy (JIRA)]

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

Alex Rudyy reassigned QPID-8124:


Assignee: Alex Rudyy

> [Broker-J][REST] Sucessfully authenticated user is reported as <> in 
> ACL operational logs when checking access to management
> -
>
> Key: QPID-8124
> URL: https://issues.apache.org/jira/browse/QPID-8124
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0, 
> qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.3
>
>
> When user is successfully authenticated, the user information  in operational 
> log for checking management access is reported as <> for both 
> Allowed and Denied outcomes:
> {noformat}
> INFO  [qtp1675859208-228] (q.m.a.denied) - <> ACL-1002 : Denied : 
> Access Management 
> INFO  [qtp1675859208-64] (q.m.a.allowed) - <> ACL-1001 : Allowed : 
> Access Management 
> INFO  [qtp1675859208-64] (q.m.m.open) - 
> [mng:nyXoe7Io(admin@/127.0.0.1:45666)] MNG-1007 : Open : User admin
> {noformat}
> As result, it is impossible to identify the principal name of authenticated 
> user in operational log when access is denied. 
> Thought, it is possible to get the principal name for "allowed" outcome by 
> looking into the following logs from the same thread, it would be beneficial 
> to print the real principal information in the log for Allowed outcome.



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

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

[jira] [Resolved] (QPID-8136) [Broker-J] Upgrade Jackson dependencies

[Alex Rudyy (JIRA)]

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

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

Changes look good to me

> [Broker-J] Upgrade Jackson dependencies
> ---
>
> Key: QPID-8136
> URL: https://issues.apache.org/jira/browse/QPID-8136
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-6.1.6, 
> qpid-java-broker-7.0.3
>
>
> CVE-2017-7525 was recently published against the Jackson-databind component.  
>   Broker-J uses the library for the purposes of the persistence of 
> configuration and the interpreting of payloads of some network requests.   
> Whilst Apache Qpid Broker-J distributions include a version of 
> jackson-databind that is affected by the vulnerability, it is believed
>  that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
> vulnerability.  This is because Broker-J code never enables Jackson's
>  polymorphic deserialisation features: specifically it never makes calls to 
> {{ObjectMapper#enableDefaultTyping(...)}} nor does it use
>  TypeResolverBuilders or annotations that enable the feature.
> Even though it is believed the vulnerability cannot be exploited, this Jira 
> will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
> that are not vulnerable to this issue:
> For:
>  * master (upgrade from 2.8.7 to 2.9.4)
>  * 7.0.x (upgrade from  2.8.7 to 2.8.11)
>  * 6.1.x (upgrade from 2.5.3 to 2.8.11)
> There is no release planned for 6.0.x.  Users are recommended to move to the 
> 7.0 line.
> Also see:
> [http://mail-archives.apache.org/mod_mbox/qpid-users/201803.mbox/%3cCAFEMS4tdrS_=st85j+-xqfm8nc3avx4x0ay10jqmpynmdly...@mail.gmail.com%3e]
>  



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

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

[jira] [Updated] (QPIDIT-119) Add AMQP complex type test

[Kim van der Riet (JIRA)]

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

Kim van der Riet updated QPIDIT-119:

Affects Version/s: 0.1.0

> Add AMQP complex type test
> --
>
> Key: QPIDIT-119
> URL: https://issues.apache.org/jira/browse/QPIDIT-119
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Task
>Affects Versions: 0.1.0
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> The AMQP types test cover the simple tests well, but do not do a good job of 
> the complex types. This is because the ability to represent the test data for 
> the complex types is itself a complex issue, as each complex type may contain 
> an arbitrary number of other complex types. For example, a list may contain 
> other lists or maps, and maps may contain other lists and maps as both keys 
> and values.
> Solving this problem requires that a mechanism exist to create and represent 
> an arbitrarily large and complex set of data for testing, and allow the sent 
> and received data to be compared to determine success or failure.



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

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

[jira] [Commented] (PROTON-1791) TCP sockets remain open in CLOSE_WAIT state

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1791: [ruby] Fix test race condition

Fix race in ruby tests causing this error:

NoMethodError: undefined method `virtual_host' for nil:NilClass

/home/travis/build/apache/qpid-proton/proton-c/bindings/ruby/tests/test_container.rb:189:in
`test_connection_options'


> TCP sockets remain open in CLOSE_WAIT state
> ---
>
> Key: PROTON-1791
> URL: https://issues.apache.org/jira/browse/PROTON-1791
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Affects Versions: proton-c-0.21.0
> Environment: Confirmed on Ubuntu 16.04 and RHEL 7.4
> Confirmed on qpid_proton 0.19.0 and 0.21.0
>Reporter: Miha Plesko
>Assignee: Alan Conway
>Priority: Major
>  Labels: bug
> Fix For: proton-c-0.22.0
>
> Attachments: idle-disconnect.png, stderr.txt, stdout.txt
>
>
> Hi guys,
> thanks for developing the awesome qpid_proton ruby gem, we're using it on 
> daily basis!
> However, recently we noticed following error in our server log:
> Too many open files - socket(2) for "172.16.117.189" port 5672
> After some research it turns out that qpid_proton process is having 
> increasingly
> more and more following file descriptors open:
> $ lsof -ap 108533
> ruby108533 miha  116u  IPv4 562438  0t0  TCP 
> 172.16.117.189:53626->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  197u  IPv4 561644  0t0  TCP 
> 172.16.117.189:53630->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  311u  IPv4 560657  0t0  TCP 
> 172.16.117.189:53634->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  549u  IPv4 565342  0t0  TCP 
> 172.16.117.189:53642->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  576u  IPv4 565122  0t0  TCP 
> 172.16.117.189:53650->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  603u  IPv4 565738  0t0  TCP 
> 172.16.117.189:53654->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  630u  IPv4 563021  0t0  TCP 
> 172.16.117.189:53658->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  657u  IPv4 568361  0t0  TCP 
> 172.16.117.189:53662->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  666u  IPv4 563027  0t0  TCP 
> 172.16.117.189:53666->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  675u  IPv4 567538  0t0  TCP 
> 172.16.117.189:53670->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  684u  IPv4 567998  0t0  TCP 
> 172.16.117.189:53678->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  690u  IPv4 574709  0t0  TCP 
> 172.16.117.189:53686->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  693u  IPv4 578725  0t0  TCP 
> 172.16.117.189:53694->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  696u  IPv4 576840  0t0  TCP 
> 172.16.117.189:53698->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  699u  IPv4 577819  0t0  TCP 
> 172.16.117.189:53702->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  702u  IPv4 582192  0t0  TCP 
> 172.16.117.189:53710->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  705u  IPv4 582861  0t0  TCP 
> 172.16.117.189:53714->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  708u  IPv4 577363  0t0  TCP 
> 172.16.117.189:53718->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  711u  IPv4 578175  0t0  TCP 
> 172.16.117.189:53722->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  714u  IPv4 587172  0t0  TCP 
> 172.16.117.189:53730->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha  717u  IPv4 584387  0t0  TCP 
> 172.16.117.189:53734->147.75.102.132:amqp (CLOSE_WAIT)
> ...
> I think the CLOSE_WAIT status of file descriptor indicates that the TCP
> connection has already been closed, but the file descriptor wasn't closed.
> After 9 hours or so there are enough of such file descriptors for OS to
> complain about it.
> We did all we could to close connections gracefully:
> connection.container.stop
> connection.close
> connection = nil
> but nothing seems to help. A simple but expensive workaround is to manually 
> invoke Ruby's 

[jira] [Updated] (QPIDIT-118) Add char and decimal in amqpnetlite shim

[Kim van der Riet (JIRA)]

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

Kim van der Riet updated QPIDIT-118:

Affects Version/s: 0.1.0

> Add char and decimal in amqpnetlite shim
> 
>
> Key: QPIDIT-118
> URL: https://issues.apache.org/jira/browse/QPIDIT-118
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Improvement
>  Components: .Net Lite Shim
>Affects Versions: 0.1.0
>Reporter: Xin Chen
>Assignee: Chuck Rolke
>Priority: Trivial
>
> Encoding support for char and decimal has been added in the .Net Lite 
> library. The decimal type is implemented by Amqp.Types.Decimal. It is not the 
> C# decimal type because .Net does not use the standard IEEE 754 
> decimal32/64/128 encoding.



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

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

[jira] [Resolved] (QPID-8016) [Broker-J] FileKeyStore alias does not select the correct certificate

[Alex Rudyy (JIRA)]

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

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

The changes look releasable to me. Shall we port it into 6.1.x as well

> [Broker-J] FileKeyStore alias does not select the correct certificate
> -
>
> Key: QPID-8016
> URL: https://issues.apache.org/jira/browse/QPID-8016
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.3
>
>
> Keystore provider implementation {{FileKeyStore}} has a {{#certificateAlias}} 
> attribute that is supposed to select a single certificate for use from a 
> store that has many.   This feature does not currently work. It seems that 
> the last certificate is chosen regardless of the alias specified by the user. 
> I reproduced this problem with test resource at 
> {{test-profiles/test_resources/ssl/java_client_keystore.jks}}. It contains 
> two non-CA certs app1 and app2.  app2 was always presented over the TLS 
> enabled socket, regardless of the setting of the {{certificateAlias}}



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

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

[jira] [Comment Edited] (QPID-8016) [Broker-J] FileKeyStore alias does not select the correct certificate

[Alex Rudyy (JIRA)]

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

Alex Rudyy edited comment on QPID-8016 at 3/20/18 1:29 PM:
---

The changes look releasable to me. Shall we port it into 6.1.x as well?


was (Author: alex.rufous):
The changes look releasable to me. Shall we port it into 6.1.x as well

> [Broker-J] FileKeyStore alias does not select the correct certificate
> -
>
> Key: QPID-8016
> URL: https://issues.apache.org/jira/browse/QPID-8016
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.3
>
>
> Keystore provider implementation {{FileKeyStore}} has a {{#certificateAlias}} 
> attribute that is supposed to select a single certificate for use from a 
> store that has many.   This feature does not currently work. It seems that 
> the last certificate is chosen regardless of the alias specified by the user. 
> I reproduced this problem with test resource at 
> {{test-profiles/test_resources/ssl/java_client_keystore.jks}}. It contains 
> two non-CA certs app1 and app2.  app2 was always presented over the TLS 
> enabled socket, regardless of the setting of the {{certificateAlias}}



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

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

[jira] [Closed] (QPIDIT-114) [AMQP.NetLite] AMQP char type is not supported, but is not excluded from test

[Kim van der Riet (JIRA)]

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

Kim van der Riet closed QPIDIT-114.
---
Resolution: Fixed

I am going to close this issue, as another has been opened in QPIDIT-118. Both 
the char and decimal types are now supported in AmqpNetLite, and need to be 
added to the shims.

> [AMQP.NetLite] AMQP char type is not supported, but is not excluded from test
> -
>
> Key: QPIDIT-114
> URL: https://issues.apache.org/jira/browse/QPIDIT-114
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Bug
>  Components: .Net Lite Shim, AMQP Types Test
>Affects Versions: 0.1.0
>Reporter: Kim van der Riet
>Assignee: Chuck Rolke
>Priority: Major
> Fix For: 0.2.0
>
>
> When the amqp_types_test is run against the ActiveMQ broker (which can handle 
> AMQP type char, unlike several other brokers), the tests of AMQP type 
> {{char}} fail with an error message from the AMQP.NetLite shims:
> {noformat}
> System.ApplicationException: Sender can not encode base type: char{noformat}
> As a mechanism exists in each test to exclude AMQP types based on the client 
> being run, this should be added.



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

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

[jira] [Assigned] (QPIDIT-119) Add AMQP complex type test

[Kim van der Riet (JIRA)]

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

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

Assignee: Kim van der Riet

> Add AMQP complex type test
> --
>
> Key: QPIDIT-119
> URL: https://issues.apache.org/jira/browse/QPIDIT-119
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Task
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> The AMQP types test cover the simple tests well, but do not do a good job of 
> the complex types. This is because the ability to represent the test data for 
> the complex types is itself a complex issue, as each complex type may contain 
> an arbitrary number of other complex types. For example, a list may contain 
> other lists or maps, and maps may contain other lists and maps as both keys 
> and values.
> Solving this problem requires that a mechanism exist to create and represent 
> an arbitrarily large and complex set of data for testing, and allow the sent 
> and received data to be compared to determine success or failure.



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

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

[jira] [Created] (QPIDIT-119) Add AMQP complex type test

[Kim van der Riet (JIRA)]

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

 Summary: Add AMQP complex type test
 Key: QPIDIT-119
 URL: https://issues.apache.org/jira/browse/QPIDIT-119
 Project: Apache QPID Interoperability Test Suite
  Issue Type: Task
Reporter: Kim van der Riet


The AMQP types test cover the simple tests well, but do not do a good job of 
the complex types. This is because the ability to represent the test data for 
the complex types is itself a complex issue, as each complex type may contain 
an arbitrary number of other complex types. For example, a list may contain 
other lists or maps, and maps may contain other lists and maps as both keys and 
values.

Solving this problem requires that a mechanism exist to create and represent an 
arbitrarily large and complex set of data for testing, and allow the sent and 
received data to be compared to determine success or failure.



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

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

[jira] [Updated] (QPID-8136) [Broker-J] Upgrade Jackson dependencies

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8136:
-
Description: 
CVE-2017-7525 was recently published against the Jackson-databind component.    
Broker-J uses the library for the purposes of the persistence of configuration 
and the interpreting of payloads of some network requests.   

Whilst Apache Qpid Broker-J distributions include a version of jackson-databind 
that is affected by the vulnerability, it is believed
 that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
vulnerability.  This is because Broker-J code never enables Jackson's
 polymorphic deserialisation features: specifically it never makes calls to 
{{ObjectMapper#enableDefaultTyping(...)}} nor does it use
 TypeResolverBuilders or annotations that enable the feature.

Even though it is believed the vulnerability cannot be exploited, this Jira 
will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
that are not vulnerable to this issue:

For:
 * master (upgrade from 2.8.7 to 2.9.4)
 * 7.0.x (upgrade from  2.8.7 to 2.8.11)
 * 6.1.x (upgrade from 2.5.3 to 2.8.11)

There is no release planned for 6.0.x.  Users are recommended to move to the 
7.0 line.

Also see:

[http://mail-archives.apache.org/mod_mbox/qpid-users/201803.mbox/%3cCAFEMS4tdrS_=st85j+-xqfm8nc3avx4x0ay10jqmpynmdly...@mail.gmail.com%3e]

 

  was:
CVE-2017-7525 was recently published against the Jackson-databind component.    
Broker-J uses the library for the purposes of the persistence of configuration 
and the interpreting of payloads of some network requests.   

Whilst Apache Qpid Broker-J distributions include a version of jackson-databind 
that is affected by the vulnerability, it is believed
 that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
vulnerability.  This is because Broker-J code never enables Jackson's
 polymorphic deserialisation features: specifically it never makes calls to 
{{ObjectMapper#enableDefaultTyping(...)}} nor does it use
 TypeResolverBuilders or annotations that enable the feature.

Even though it is believed the vulnerability cannot be exploited, this Jira 
will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
that are not vulnerable to this issue:

For:
 * master (upgrade from 2.8.7 to 2.9.4)
 * 7.0.x (upgrade from  2.8.7 to 2.8.11)
 * 6.1.x (upgrade from 2.5.3 to 2.8.11)

There is no release planned for 6.0.x.  Users are recommend to move to the 7.0 
line.

Also see:

[http://mail-archives.apache.org/mod_mbox/qpid-users/201803.mbox/%3cCAFEMS4tdrS_=st85j+-xqfm8nc3avx4x0ay10jqmpynmdly...@mail.gmail.com%3e]

 


> [Broker-J] Upgrade Jackson dependencies
> ---
>
> Key: QPID-8136
> URL: https://issues.apache.org/jira/browse/QPID-8136
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-6.1.6, 
> qpid-java-broker-7.0.3
>
>
> CVE-2017-7525 was recently published against the Jackson-databind component.  
>   Broker-J uses the library for the purposes of the persistence of 
> configuration and the interpreting of payloads of some network requests.   
> Whilst Apache Qpid Broker-J distributions include a version of 
> jackson-databind that is affected by the vulnerability, it is believed
>  that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
> vulnerability.  This is because Broker-J code never enables Jackson's
>  polymorphic deserialisation features: specifically it never makes calls to 
> {{ObjectMapper#enableDefaultTyping(...)}} nor does it use
>  TypeResolverBuilders or annotations that enable the feature.
> Even though it is believed the vulnerability cannot be exploited, this Jira 
> will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
> that are not vulnerable to this issue:
> For:
>  * master (upgrade from 2.8.7 to 2.9.4)
>  * 7.0.x (upgrade from  2.8.7 to 2.8.11)
>  * 6.1.x (upgrade from 2.5.3 to 2.8.11)
> There is no release planned for 6.0.x.  Users are recommended to move to the 
> 7.0 line.
> Also see:
> [http://mail-archives.apache.org/mod_mbox/qpid-users/201803.mbox/%3cCAFEMS4tdrS_=st85j+-xqfm8nc3avx4x0ay10jqmpynmdly...@mail.gmail.com%3e]
>  



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

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

[jira] [Updated] (QPID-8136) [Broker-J] Upgrade Jackson dependencies

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8136:
-
Description: 
CVE-2017-7525 was recently published against the Jackson-databind component.    
Broker-J uses the library for the purposes of the persistence of configuration 
and the interpreting of payloads of some network requests.   

Whilst Apache Qpid Broker-J distributions include a version of jackson-databind 
that is affected by the vulnerability, it is believed
 that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
vulnerability.  This is because Broker-J code never enables Jackson's
 polymorphic deserialisation features: specifically it never makes calls to 
{{ObjectMapper#enableDefaultTyping(...)}} nor does it use
 TypeResolverBuilders or annotations that enable the feature.

Even though it is believed the vulnerability cannot be exploited, this Jira 
will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
that are not vulnerable to this issue:

For:
 * master (upgrade from 2.8.7 to 2.9.4)
 * 7.0.x (upgrade from  2.8.7 to 2.8.11)
 * 6.1.x (upgrade from 2.5.3 to 2.8.11)

There is no release planned for 6.0.x.  Users are recommend to move to the 7.0 
line.

Also see:

[http://mail-archives.apache.org/mod_mbox/qpid-users/201803.mbox/%3cCAFEMS4tdrS_=st85j+-xqfm8nc3avx4x0ay10jqmpynmdly...@mail.gmail.com%3e]

 

  was:
CVE-2017-7525 was recently published against the Jackson-databind component.    
Broker-J uses the library for the purposes of the persistence of configuration 
and the interpreting of payloads of some network requests.   

Whilst Apache Qpid Broker-J distributions include a version of jackson-databind 
that is affected by the vulnerability, it is believed
 that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
vulnerability.  This is because Broker-J code never enables Jackson's
 polymorphic deserialisation features: specifically it never makes calls to 
{{ObjectMapper#enableDefaultTyping(...)}} nor does it use
 TypeResolverBuilders or annotations that enable the feature.

Even though it is believed the vulnerability cannot be exploited, this Jira 
will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
that are not vulnerable to this issue:

For:
 * master (upgrade from 2.8.7 to 2.9.4)
 * 7.0.x (upgrade from  2.8.7 to 2.8.11)
 * 6.1.x (upgrade from 2.8.7 to 2.8.11)

There is no release planned for 6.0.x.  Users are recommend to move to the 7.0 
line.

Also see:

[http://mail-archives.apache.org/mod_mbox/qpid-users/201803.mbox/%3cCAFEMS4tdrS_=st85j+-xqfm8nc3avx4x0ay10jqmpynmdly...@mail.gmail.com%3e]

 


> [Broker-J] Upgrade Jackson dependencies
> ---
>
> Key: QPID-8136
> URL: https://issues.apache.org/jira/browse/QPID-8136
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-6.1.6, 
> qpid-java-broker-7.0.3
>
>
> CVE-2017-7525 was recently published against the Jackson-databind component.  
>   Broker-J uses the library for the purposes of the persistence of 
> configuration and the interpreting of payloads of some network requests.   
> Whilst Apache Qpid Broker-J distributions include a version of 
> jackson-databind that is affected by the vulnerability, it is believed
>  that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
> vulnerability.  This is because Broker-J code never enables Jackson's
>  polymorphic deserialisation features: specifically it never makes calls to 
> {{ObjectMapper#enableDefaultTyping(...)}} nor does it use
>  TypeResolverBuilders or annotations that enable the feature.
> Even though it is believed the vulnerability cannot be exploited, this Jira 
> will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
> that are not vulnerable to this issue:
> For:
>  * master (upgrade from 2.8.7 to 2.9.4)
>  * 7.0.x (upgrade from  2.8.7 to 2.8.11)
>  * 6.1.x (upgrade from 2.5.3 to 2.8.11)
> There is no release planned for 6.0.x.  Users are recommend to move to the 
> 7.0 line.
> Also see:
> [http://mail-archives.apache.org/mod_mbox/qpid-users/201803.mbox/%3cCAFEMS4tdrS_=st85j+-xqfm8nc3avx4x0ay10jqmpynmdly...@mail.gmail.com%3e]
>  



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

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

[jira] [Updated] (DISPATCH-930) Edge Router mode for improved scale and efficiency

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-930:
--
Fix Version/s: 1.1.0

> Edge Router mode for improved scale and efficiency
> --
>
> Key: DISPATCH-930
> URL: https://issues.apache.org/jira/browse/DISPATCH-930
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.1.0
>
> Attachments: EdgeRouter.pdf
>
>
> Introduce a new router operating mode called "edge" that allows a router to 
> join a network with a single uplink to an "interior" router.  Such routers 
> can be proliferated without limit and allow for greatly increased network 
> size.
>  



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

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

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

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-89:
-
Fix Version/s: 1.1.0

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



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

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

[jira] [Updated] (QPID-8136) [Broker-J] Upgrade Jackson dependencies

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8136:
-
Description: 
CVE-2017-7525 was recently published against the Jackson-databind component.    
Broker-J uses the library for the purposes of the persistence of configuration 
and the interpreting of payloads of some network requests.   

Whilst Apache Qpid Broker-J distributions include a version of jackson-databind 
that is affected by the vulnerability, it is believed
 that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
vulnerability.  This is because Broker-J code never enables Jackson's
 polymorphic deserialisation features: specifically it never makes calls to 
{{ObjectMapper#enableDefaultTyping(...)}} nor does it use
 TypeResolverBuilders or annotations that enable the feature.

Even though it is believed the vulnerability cannot be exploited, this Jira 
will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
that are not vulnerable to this issue:

For:
 * master (upgrade from 2.8.7 to 2.9.4)
 * 7.0.x (upgrade from  2.8.7 to 2.8.11)
 * 6.1.x (upgrade from 2.8.7 to 2.8.11)

There is no release planned for 6.0.x.  Users are recommend to move to the 7.0 
line.

Also see:

[http://mail-archives.apache.org/mod_mbox/qpid-users/201803.mbox/%3cCAFEMS4tdrS_=st85j+-xqfm8nc3avx4x0ay10jqmpynmdly...@mail.gmail.com%3e]

 

  was:
CVE-2017-7525 was recently published against the Jackson-databind component.    
Broker-J uses the library for the purposes of the persistence of configuration 
and the interpreting of payloads of some network requests.   

Whilst Apache Qpid Broker-J distributions include a version of jackson-databind 
that is affected by the vulnerability, it is believed
 that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
vulnerability.  This is because Broker-J code never enables Jackson's
 polymorphic deserialisation features: specifically it never makes calls to 
Object#enableDefaultTyping(...) nor does it use
 TypeResolverBuilders or annotations that enable the feature.

Even though it is believed the vulnerability cannot be exploited, this Jira 
will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
that are not vulnerable to this issue:

For:
 * master (upgrade from 2.8.7 to 2.9.4)
 * 7.0.x (upgrade from  2.8.7 to 2.8.11)
 * 6.1.x (upgrade from 2.8.7 to 2.8.11)

There is no release planned for 6.0.x.  Users are recommend to move to the 7.0 
line.

Also see:

[http://mail-archives.apache.org/mod_mbox/qpid-users/201803.mbox/%3cCAFEMS4tdrS_=st85j+-xqfm8nc3avx4x0ay10jqmpynmdly...@mail.gmail.com%3e]

 


> [Broker-J] Upgrade Jackson dependencies
> ---
>
> Key: QPID-8136
> URL: https://issues.apache.org/jira/browse/QPID-8136
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-6.1.6, 
> qpid-java-broker-7.0.3
>
>
> CVE-2017-7525 was recently published against the Jackson-databind component.  
>   Broker-J uses the library for the purposes of the persistence of 
> configuration and the interpreting of payloads of some network requests.   
> Whilst Apache Qpid Broker-J distributions include a version of 
> jackson-databind that is affected by the vulnerability, it is believed
>  that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
> vulnerability.  This is because Broker-J code never enables Jackson's
>  polymorphic deserialisation features: specifically it never makes calls to 
> {{ObjectMapper#enableDefaultTyping(...)}} nor does it use
>  TypeResolverBuilders or annotations that enable the feature.
> Even though it is believed the vulnerability cannot be exploited, this Jira 
> will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
> that are not vulnerable to this issue:
> For:
>  * master (upgrade from 2.8.7 to 2.9.4)
>  * 7.0.x (upgrade from  2.8.7 to 2.8.11)
>  * 6.1.x (upgrade from 2.8.7 to 2.8.11)
> There is no release planned for 6.0.x.  Users are recommend to move to the 
> 7.0 line.
> Also see:
> [http://mail-archives.apache.org/mod_mbox/qpid-users/201803.mbox/%3cCAFEMS4tdrS_=st85j+-xqfm8nc3avx4x0ay10jqmpynmdly...@mail.gmail.com%3e]
>  



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

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

[jira] [Updated] (QPID-8136) [Broker-J] Upgrade Jackson dependencies

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8136:
-
Description: 
CVE-2017-7525 was recently published against the Jackson-databind component.    
Broker-J uses the library for the purposes of the persistence of configuration 
and the interpreting of payloads of some network requests.   

Whilst Apache Qpid Broker-J distributions include a version of jackson-databind 
that is affected by the vulnerability, it is believed
 that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
vulnerability.  This is because Broker-J code never enables Jackson's
 polymorphic deserialisation features: specifically it never makes calls to 
Object#enableDefaultTyping(...) nor does it use
 TypeResolverBuilders or annotations that enable the feature.

Even though it is believed the vulnerability cannot be exploited, this Jira 
will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
that are not vulnerable to this issue:

For:
 * master (upgrade from 2.8.7 to 2.9.4)
 * 7.0.x (upgrade from  2.8.7 to 2.8.11)
 * 6.1.x (upgrade from 2.8.7 to 2.8.11)

There is no release planned for 6.0.x.  Users are recommend to move to the 7.0 
line.

Also see:

[http://mail-archives.apache.org/mod_mbox/qpid-users/201803.mbox/%3cCAFEMS4tdrS_=st85j+-xqfm8nc3avx4x0ay10jqmpynmdly...@mail.gmail.com%3e]

 

  was:
CVE-2017-7525 was recently published against the Jackson-databind component.    
Broker-J uses the library for the purposes of the persistence of configuration 
and the interpreting the payloads of some network requests.   

Whilst Apache Qpid Broker-J distributions include a version of jackson-databind 
that is affected by the vulnerability, it is believed
 that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
vulnerability.  This is because Broker-J code never enables Jackson's
 polymorphic deserialisation features: specifically it never makes calls to 
Object#enableDefaultTyping(...) nor does it use
 TypeResolverBuilders or annotations that enable the feature.

Even though it is believed the vulnerability cannot be exploited, this Jira 
will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
that are not vulnerable to this issue:

For:
 * master (upgrade from 2.8.7 to 2.9.4)
 * 7.0.x (upgrade from  2.8.7 to 2.8.11)
 * 6.1.x (upgrade from 2.8.7 to 2.8.11)

There is no release planned for 6.0.x.  Users are recommend to move to the 7.0 
line.

Also see:

http://mail-archives.apache.org/mod_mbox/qpid-users/201803.mbox/%3cCAFEMS4tdrS_=st85j+-xqfm8nc3avx4x0ay10jqmpynmdly...@mail.gmail.com%3e

 


> [Broker-J] Upgrade Jackson dependencies
> ---
>
> Key: QPID-8136
> URL: https://issues.apache.org/jira/browse/QPID-8136
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-6.1.6, 
> qpid-java-broker-7.0.3
>
>
> CVE-2017-7525 was recently published against the Jackson-databind component.  
>   Broker-J uses the library for the purposes of the persistence of 
> configuration and the interpreting of payloads of some network requests.   
> Whilst Apache Qpid Broker-J distributions include a version of 
> jackson-databind that is affected by the vulnerability, it is believed
>  that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
> vulnerability.  This is because Broker-J code never enables Jackson's
>  polymorphic deserialisation features: specifically it never makes calls to 
> Object#enableDefaultTyping(...) nor does it use
>  TypeResolverBuilders or annotations that enable the feature.
> Even though it is believed the vulnerability cannot be exploited, this Jira 
> will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
> that are not vulnerable to this issue:
> For:
>  * master (upgrade from 2.8.7 to 2.9.4)
>  * 7.0.x (upgrade from  2.8.7 to 2.8.11)
>  * 6.1.x (upgrade from 2.8.7 to 2.8.11)
> There is no release planned for 6.0.x.  Users are recommend to move to the 
> 7.0 line.
> Also see:
> [http://mail-archives.apache.org/mod_mbox/qpid-users/201803.mbox/%3cCAFEMS4tdrS_=st85j+-xqfm8nc3avx4x0ay10jqmpynmdly...@mail.gmail.com%3e]
>  



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

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

[jira] [Updated] (QPID-8136) [Broker-J] Upgrade Jackson dependencies

[Keith Wall (JIRA)]

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

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

> [Broker-J] Upgrade Jackson dependencies
> ---
>
> Key: QPID-8136
> URL: https://issues.apache.org/jira/browse/QPID-8136
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-6.1.6, 
> qpid-java-broker-7.0.3
>
>
> CVE-2017-7525 was recently published against the Jackson-databind component.  
>   Broker-J uses the library for the purposes of the persistence of 
> configuration and the interpreting the payloads of some network requests.   
> Whilst Apache Qpid Broker-J distributions include a version of 
> jackson-databind that is affected by the vulnerability, it is believed
>  that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
> vulnerability.  This is because Broker-J code never enables Jackson's
>  polymorphic deserialisation features: specifically it never makes calls to 
> Object#enableDefaultTyping(...) nor does it use
>  TypeResolverBuilders or annotations that enable the feature.
> Even though it is believed the vulnerability cannot be exploited, this Jira 
> will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
> that are not vulnerable to this issue:
> For:
>  * master (upgrade from 2.8.7 to 2.9.4)
>  * 7.0.x (upgrade from  2.8.7 to 2.8.11)
>  * 6.1.x (upgrade from 2.8.7 to 2.8.11)
> There is no release planned for 6.0.x.  Users are recommend to move to the 
> 7.0 line.
> Also see:
> http://mail-archives.apache.org/mod_mbox/qpid-users/201803.mbox/%3cCAFEMS4tdrS_=st85j+-xqfm8nc3avx4x0ay10jqmpynmdly...@mail.gmail.com%3e
>  



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

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

[jira] [Assigned] (QPID-8136) [Broker-J] Upgrade Jackson dependencies

[Keith Wall (JIRA)]

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

Keith Wall reassigned QPID-8136:


Assignee: Keith Wall

> [Broker-J] Upgrade Jackson dependencies
> ---
>
> Key: QPID-8136
> URL: https://issues.apache.org/jira/browse/QPID-8136
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-6.1.6, 
> qpid-java-broker-7.0.3
>
>
> CVE-2017-7525 was recently published against the Jackson-databind component.  
>   Broker-J uses the library for the purposes of the persistence of 
> configuration and the interpreting the payloads of some network requests.   
> Whilst Apache Qpid Broker-J distributions include a version of 
> jackson-databind that is affected by the vulnerability, it is believed
>  that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
> vulnerability.  This is because Broker-J code never enables Jackson's
>  polymorphic deserialisation features: specifically it never makes calls to 
> Object#enableDefaultTyping(...) nor does it use
>  TypeResolverBuilders or annotations that enable the feature.
> Even though it is believed the vulnerability cannot be exploited, this Jira 
> will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
> that are not vulnerable to this issue:
> For:
>  * master (upgrade from 2.8.7 to 2.9.4)
>  * 7.0.x (upgrade from  2.8.7 to 2.8.11)
>  * 6.1.x (upgrade from 2.8.7 to 2.8.11)
> There is no release planned for 6.0.x.  Users are recommend to move to the 
> 7.0 line.
> Also see:
> http://mail-archives.apache.org/mod_mbox/qpid-users/201803.mbox/%3cCAFEMS4tdrS_=st85j+-xqfm8nc3avx4x0ay10jqmpynmdly...@mail.gmail.com%3e
>  



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

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

[jira] [Updated] (QPID-8136) [Broker-J] Upgrade Jackson dependencies

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8136:
-
Description: 
CVE-2017-7525 was recently published against the Jackson-databind component.    
Broker-J uses the library for the purposes of the persistence of configuration 
and the interpreting the payloads of some network requests.   

Whilst Apache Qpid Broker-J distributions include a version of jackson-databind 
that is affected by the vulnerability, it is believed
 that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
vulnerability.  This is because Broker-J code never enables Jackson's
 polymorphic deserialisation features: specifically it never makes calls to 
Object#enableDefaultTyping(...) nor does it use
 TypeResolverBuilders or annotations that enable the feature.

Even though it is believed the vulnerability cannot be exploited, this Jira 
will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
that are not vulnerable to this issue:

For:
 * master (upgrade from 2.8.7 to 2.9.4)
 * 7.0.x (upgrade from  2.8.7 to 2.8.11)
 * 6.1.x (upgrade from 2.8.7 to 2.8.11)

There is no release planned for 6.0.x.  Users are recommend to move to the 7.0 
line.

Also see:

http://mail-archives.apache.org/mod_mbox/qpid-users/201803.mbox/%3cCAFEMS4tdrS_=st85j+-xqfm8nc3avx4x0ay10jqmpynmdly...@mail.gmail.com%3e

 

  was:
CVE-2017-7525 was recently published against the Jackson-databind component.    
Broker-J uses the library for the purposes of the persistence of configuration 
and the interpreting the payloads of some network requests.   

Whilst Apache Qpid Broker-J distributions include a version of jackson-databind 
that is affected by the vulnerability, it is believed
 that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
vulnerability.  This is because Broker-J code never enables Jackson's
 polymorphic deserialisation features: specifically it never makes calls to 
Object#enableDefaultTyping(...) nor does it use
 TypeResolverBuilders or annotations that enable the feature.

Even though it is believed the vulnerability cannot be exploited, this Jira 
will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
that are not vulnerable to this issue:

For:
 * master (upgrade from 2.8.7 to 2.9.4)
 * 7.0.x (upgrade from  2.8.7 to 2.8.11)
 * 6.1.x (upgrade from 2.8.7 to 2.8.11)

There is no release planned for 6.0.x.  Users are recommend to move to the 7.0 
line.

 


> [Broker-J] Upgrade Jackson dependencies
> ---
>
> Key: QPID-8136
> URL: https://issues.apache.org/jira/browse/QPID-8136
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-6.1.6, 
> qpid-java-broker-7.0.3
>
>
> CVE-2017-7525 was recently published against the Jackson-databind component.  
>   Broker-J uses the library for the purposes of the persistence of 
> configuration and the interpreting the payloads of some network requests.   
> Whilst Apache Qpid Broker-J distributions include a version of 
> jackson-databind that is affected by the vulnerability, it is believed
>  that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
> vulnerability.  This is because Broker-J code never enables Jackson's
>  polymorphic deserialisation features: specifically it never makes calls to 
> Object#enableDefaultTyping(...) nor does it use
>  TypeResolverBuilders or annotations that enable the feature.
> Even though it is believed the vulnerability cannot be exploited, this Jira 
> will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
> that are not vulnerable to this issue:
> For:
>  * master (upgrade from 2.8.7 to 2.9.4)
>  * 7.0.x (upgrade from  2.8.7 to 2.8.11)
>  * 6.1.x (upgrade from 2.8.7 to 2.8.11)
> There is no release planned for 6.0.x.  Users are recommend to move to the 
> 7.0 line.
> Also see:
> http://mail-archives.apache.org/mod_mbox/qpid-users/201803.mbox/%3cCAFEMS4tdrS_=st85j+-xqfm8nc3avx4x0ay10jqmpynmdly...@mail.gmail.com%3e
>  



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

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

[jira] [Created] (DISPATCH-945) Crash on shutdown when a http+websocket connection is open

[Ted Ross (JIRA)]

Ted Ross created DISPATCH-945:
-

 Summary: Crash on shutdown when a http+websocket connection is open
 Key: DISPATCH-945
 URL: https://issues.apache.org/jira/browse/DISPATCH-945
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Container
Affects Versions: 1.0.1
Reporter: Ted Ross
 Fix For: 1.1.0


If the router is shut down when there is an active HTTP+websockets connection, 
the router segfaults.

This crash appears to be a result of improper shutdown ordering.  When the 
connection is closed, the container module has already been freed.  This 
results in the dereferencing of invalid pointers.



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

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

[jira] [Updated] (QPID-8136) [Broker-J] Upgrade Jackson dependencies

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8136:
-
Description: 
CVE-2017-7525 was recently published against the Jackson-databind component.    
Broker-J uses the library for the purposes of the persistence of configuration 
and the interpreting the payloads of some network requests.   

Whilst Apache Qpid Broker-J distributions include a version of jackson-databind 
that is affected by the vulnerability, it is believed
 that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
vulnerability.  This is because Broker-J code never enables Jackson's
 polymorphic deserialisation features: specifically it never makes calls to 
Object#enableDefaultTyping(...) nor does it use
 TypeResolverBuilders or annotations that enable the feature.

Even though it is believed the vulnerability cannot be exploited, this Jira 
will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
that are not vulnerable to this issue:

For:
 * master (upgrade from 2.8.7 to 2.9.4)
 * 7.0.x (upgrade from  2.8.7 to 2.8.11)
 * 6.1.x (upgrade from 2.8.7 to 2.8.11)

There is no release planned for 6.0.x.  Users are recommend to move to the 7.0 
line.

 

  was:
CVE-2017-7525 was recently published against the Jackson-databind component.    
Broker-J uses the library for the purposes of the persistence of configuration 
and the interpreting the payloads of some network requests.   

Whilst Apache Qpid Broker-J distributions include a version of jackson-databind 
that is affected by the vulnerability, it is believed
 that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
vulnerability.  This is because Broker-J code never enables Jackson's
 polymorphic deserialisation features: specifically it never makes calls to 
Object#enableDefaultTyping(...) nor does it use
 TypeResolverBuilders or annotations that enable the feature.

Even though it is believed the vulnerability cannot be exploited, this Jira 
will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
that are not vulnerable to this issue:

For:
 * master (upgrade from 2.8.7 to 2.9.4)
 * 7.0.x (upgrade from  2.8.7 to 2.8.11)
 * 6.1.x (upgrade from 

 

 


> [Broker-J] Upgrade Jackson dependencies
> ---
>
> Key: QPID-8136
> URL: https://issues.apache.org/jira/browse/QPID-8136
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-6.1.6, 
> qpid-java-broker-7.0.3
>
>
> CVE-2017-7525 was recently published against the Jackson-databind component.  
>   Broker-J uses the library for the purposes of the persistence of 
> configuration and the interpreting the payloads of some network requests.   
> Whilst Apache Qpid Broker-J distributions include a version of 
> jackson-databind that is affected by the vulnerability, it is believed
>  that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
> vulnerability.  This is because Broker-J code never enables Jackson's
>  polymorphic deserialisation features: specifically it never makes calls to 
> Object#enableDefaultTyping(...) nor does it use
>  TypeResolverBuilders or annotations that enable the feature.
> Even though it is believed the vulnerability cannot be exploited, this Jira 
> will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
> that are not vulnerable to this issue:
> For:
>  * master (upgrade from 2.8.7 to 2.9.4)
>  * 7.0.x (upgrade from  2.8.7 to 2.8.11)
>  * 6.1.x (upgrade from 2.8.7 to 2.8.11)
> There is no release planned for 6.0.x.  Users are recommend to move to the 
> 7.0 line.
>  



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

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

[jira] [Updated] (QPID-8136) [Broker-J] Upgrade Jackson dependencies

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8136:
-
Description: 
CVE-2017-7525 was recently published against the Jackson-databind component.    
Broker-J uses the library for the purposes of the persistence of configuration 
and the interpreting the payloads of some network requests.   

Whilst Apache Qpid Broker-J distributions include a version of jackson-databind 
that is affected by the vulnerability, it is believed
 that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
vulnerability.  This is because Broker-J code never enables Jackson's
 polymorphic deserialisation features: specifically it never makes calls to 
Object#enableDefaultTyping(...) nor does it use
 TypeResolverBuilders or annotations that enable the feature.

Even though it is believed the vulnerability cannot be exploited, this Jira 
will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
that are not vulnerable to this issue:

For:
 * master (upgrade from 2.8.7 to 2.9.4)
 * 7.0.x (upgrade from  2.8.7 to 2.8.11)
 * 6.1.x (upgrade from 

 

 

  was:
CVE-2017-7525 was recently published against the Jackson-databind component.    
Broker-J uses the library for the purposes of the persistence of configuration 
and the interpreting the payloads of some network requests.   

Whilst Apache Qpid Broker-J distributions include a version of jackson-databind 
that is affected by the vulnerability, it is believed
 that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
vulnerability.  This is because Broker-J code never enables Jackson's
 polymorphic deserialisation features: specifically it never makes calls to 
Object#enableDefaultTyping(...) nor does it use
 TypeResolverBuilders or annotations that enable the feature.

Even though it is believed the vulnerability cannot be exploited, this Jira 
will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
that are not vulnerable to this issue:

For:

* master (upgrade from 

 

 


> [Broker-J] Upgrade Jackson dependencies
> ---
>
> Key: QPID-8136
> URL: https://issues.apache.org/jira/browse/QPID-8136
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-6.1.6, 
> qpid-java-broker-7.0.3
>
>
> CVE-2017-7525 was recently published against the Jackson-databind component.  
>   Broker-J uses the library for the purposes of the persistence of 
> configuration and the interpreting the payloads of some network requests.   
> Whilst Apache Qpid Broker-J distributions include a version of 
> jackson-databind that is affected by the vulnerability, it is believed
>  that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
> vulnerability.  This is because Broker-J code never enables Jackson's
>  polymorphic deserialisation features: specifically it never makes calls to 
> Object#enableDefaultTyping(...) nor does it use
>  TypeResolverBuilders or annotations that enable the feature.
> Even though it is believed the vulnerability cannot be exploited, this Jira 
> will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
> that are not vulnerable to this issue:
> For:
>  * master (upgrade from 2.8.7 to 2.9.4)
>  * 7.0.x (upgrade from  2.8.7 to 2.8.11)
>  * 6.1.x (upgrade from 
>  
>  



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

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

[jira] [Updated] (QPID-8136) [Broker-J] Upgrade Jackson dependencies

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8136:
-
Description: 
CVE-2017-7525 was recently published against the Jackson-databind component.    
Broker-J uses the library for the purposes of the persistence of configuration 
and the interpreting the payloads of some network requests.   

Whilst Apache Qpid Broker-J distributions include a version of jackson-databind 
that is affected by the vulnerability, it is believed
that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
vulnerability.  This is because Broker-J code never enables Jackson's
polymorphic deserialisation features: specifically it never makes calls to 
Object#enableDefaultTyping(...) nor does it use
TypeResolverBuilders or annotations that enable the feature.

Even though it is believed the vulnerability cannot be exploited, this Jira 
will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
that are not vulnerable to this issue:

 

 

  was:Upgrade Jackson dependencies


> [Broker-J] Upgrade Jackson dependencies
> ---
>
> Key: QPID-8136
> URL: https://issues.apache.org/jira/browse/QPID-8136
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-6.1.6, 
> qpid-java-broker-7.0.3
>
>
> CVE-2017-7525 was recently published against the Jackson-databind component.  
>   Broker-J uses the library for the purposes of the persistence of 
> configuration and the interpreting the payloads of some network requests.   
> Whilst Apache Qpid Broker-J distributions include a version of 
> jackson-databind that is affected by the vulnerability, it is believed
> that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
> vulnerability.  This is because Broker-J code never enables Jackson's
> polymorphic deserialisation features: specifically it never makes calls to 
> Object#enableDefaultTyping(...) nor does it use
> TypeResolverBuilders or annotations that enable the feature.
> Even though it is believed the vulnerability cannot be exploited, this Jira 
> will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
> that are not vulnerable to this issue:
>  
>  



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

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

[jira] [Updated] (QPID-8136) [Broker-J] Upgrade Jackson dependencies

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8136:
-
Description: 
CVE-2017-7525 was recently published against the Jackson-databind component.    
Broker-J uses the library for the purposes of the persistence of configuration 
and the interpreting the payloads of some network requests.   

Whilst Apache Qpid Broker-J distributions include a version of jackson-databind 
that is affected by the vulnerability, it is believed
 that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
vulnerability.  This is because Broker-J code never enables Jackson's
 polymorphic deserialisation features: specifically it never makes calls to 
Object#enableDefaultTyping(...) nor does it use
 TypeResolverBuilders or annotations that enable the feature.

Even though it is believed the vulnerability cannot be exploited, this Jira 
will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
that are not vulnerable to this issue:

For:

* master (upgrade from 

 

 

  was:
CVE-2017-7525 was recently published against the Jackson-databind component.    
Broker-J uses the library for the purposes of the persistence of configuration 
and the interpreting the payloads of some network requests.   

Whilst Apache Qpid Broker-J distributions include a version of jackson-databind 
that is affected by the vulnerability, it is believed
that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
vulnerability.  This is because Broker-J code never enables Jackson's
polymorphic deserialisation features: specifically it never makes calls to 
Object#enableDefaultTyping(...) nor does it use
TypeResolverBuilders or annotations that enable the feature.

Even though it is believed the vulnerability cannot be exploited, this Jira 
will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
that are not vulnerable to this issue:

 

 


> [Broker-J] Upgrade Jackson dependencies
> ---
>
> Key: QPID-8136
> URL: https://issues.apache.org/jira/browse/QPID-8136
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-6.1.6, 
> qpid-java-broker-7.0.3
>
>
> CVE-2017-7525 was recently published against the Jackson-databind component.  
>   Broker-J uses the library for the purposes of the persistence of 
> configuration and the interpreting the payloads of some network requests.   
> Whilst Apache Qpid Broker-J distributions include a version of 
> jackson-databind that is affected by the vulnerability, it is believed
>  that Apache Qpid Broker-J product itself is *NOT AFFECTED* by this 
> vulnerability.  This is because Broker-J code never enables Jackson's
>  polymorphic deserialisation features: specifically it never makes calls to 
> Object#enableDefaultTyping(...) nor does it use
>  TypeResolverBuilders or annotations that enable the feature.
> Even though it is believed the vulnerability cannot be exploited, this Jira 
> will upgrade the dependencies of Broker-J to versions of the Jackson-databind 
> that are not vulnerable to this issue:
> For:
> * master (upgrade from 
>  
>  



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

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

[jira] [Commented] (QPID-8136) [Broker-J] Upgrade Jackson dependencies

[ASF subversion and git services (JIRA)]

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

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

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

QPID-8136: [Broker-J] [Jackson] Update dependency from 2.8.7 to 2.8.11


> [Broker-J] Upgrade Jackson dependencies
> ---
>
> Key: QPID-8136
> URL: https://issues.apache.org/jira/browse/QPID-8136
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-6.1.6, 
> qpid-java-broker-7.0.3
>
>
> Upgrade Jackson dependencies



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

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

[jira] [Updated] (QPID-8136) [Broker-J] Upgrade Jackson dependencies

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8136:
-
Fix Version/s: qpid-java-6.1.6

> [Broker-J] Upgrade Jackson dependencies
> ---
>
> Key: QPID-8136
> URL: https://issues.apache.org/jira/browse/QPID-8136
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-6.1.6, 
> qpid-java-broker-7.0.3
>
>
> Upgrade Jackson dependencies



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

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

[jira] [Commented] (QPID-7858) [Java Broker] Bump com.fasterxml.jackson dependency 2.5 => 2.8

[ASF subversion and git services (JIRA)]

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

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

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

QPID-7858 [Java Broker] Bump com.fasterxml.jackson dependency from 2.5 to 2.8


> [Java Broker] Bump com.fasterxml.jackson dependency 2.5 => 2.8
> --
>
> Key: QPID-7858
> URL: https://issues.apache.org/jira/browse/QPID-7858
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.0
>
>
> The Broker uses Jackson for handling JSON.  The Broker is currently a couple 
> of minor releases behind.



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

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

[jira] [Commented] (QPID-7858) [Java Broker] Bump com.fasterxml.jackson dependency 2.5 => 2.8

[ASF subversion and git services (JIRA)]

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

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

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

QPID-7858: Update dependency reference w.r.t FasterXML/jackson


> [Java Broker] Bump com.fasterxml.jackson dependency 2.5 => 2.8
> --
>
> Key: QPID-7858
> URL: https://issues.apache.org/jira/browse/QPID-7858
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.0
>
>
> The Broker uses Jackson for handling JSON.  The Broker is currently a couple 
> of minor releases behind.



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

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

[jira] [Commented] (QPID-8136) [Broker-J] Upgrade Jackson dependencies

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-8136:
--

The commit message on 906a84956baa3de2 was incorrect.  It ought to have read 
from 2.8.7 to 2.9.4.

> [Broker-J] Upgrade Jackson dependencies
> ---
>
> Key: QPID-8136
> URL: https://issues.apache.org/jira/browse/QPID-8136
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.3
>
>
> Upgrade Jackson dependencies



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

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

[jira] [Commented] (QPID-8133) Refresh Commons-CLI dependency (1.4)

[ASF subversion and git services (JIRA)]

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

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

Commit 07aaa13b07165e1b1b2f5c0ffb0a820e168be016 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=07aaa13 ]

QPID-8133: [Broker-J] Correct handling of cic command line argument and 
eliminate depcreation warning


> Refresh Commons-CLI dependency (1.4)
> 
>
> Key: QPID-8133
> URL: https://issues.apache.org/jira/browse/QPID-8133
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.1.0
>
>
> The Commons CLI dependency used by Broker-J is getting stale.  The latest 
> release is 1.4.



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

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

[jira] [Commented] (PROTON-1589) [cpp] How can I handle invalid SASL PLAIN credentials error when reconnect is on?

[JIRA]

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

Jiri Daněk commented on PROTON-1589:


The behaviour could be eventually unified with that of the Python binding. 
Python will trigger {{on_transport_error}} handler and I can detect auth 
failure by checking the error description string. I can then decide for myself 
how I want to handle it. (Although, failing the reconnect on first failure 
sounds very reasonable and it may not be necessary to allow users changing this 
behavior.)

{code}
  if name == "on_transport_error":
err_message = "Transport error: %s - %s" % (
event.transport.condition.name, 
event.transport.condition.description)
if ("authentication" in 
event.transport.condition.description.lower()
or self.conn_reconnect == "false"):
raise ClientException(err_message)
else:
Utils.dump_error(err_message)
{code}

(https://github.com/rh-messaging/cli-proton-python/blob/a52cdba7c1c0d41ee5f01d11bbfb425a4d12509c/cli_proton_python/coreclient.py#L401-L409)

> [cpp] How can I handle invalid SASL PLAIN credentials error when reconnect is 
> on?
> -
>
> Key: PROTON-1589
> URL: https://issues.apache.org/jira/browse/PROTON-1589
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>Priority: Major
>  Labels: sasl
> Fix For: proton-c-0.22.0
>
>
> Apply the following patch to the simple_send.cpp example
> {code}
> diff --git a/examples/cpp/simple_send.cpp b/examples/cpp/simple_send.cpp
> index a4c2272d..053da34f 100644
> --- a/examples/cpp/simple_send.cpp
> +++ b/examples/cpp/simple_send.cpp
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -53,6 +54,12 @@ class simple_send : public proton::messaging_handler {
>  proton::connection_options co;
>  if (!user.empty()) co.user(user);
>  if (!password.empty()) co.password(password);
> +co.sasl_enabled(true);
> +co.sasl_allow_insecure_mechs(true);
> +std::string sasl_mechanisms("PLAIN");
> +co.sasl_allowed_mechs(sasl_mechanisms);
> +proton::reconnect_options ro;
> +co.reconnect(ro);
>  sender = c.open_sender(url, co);
>  }
> {code}
> Now attempt to connect to AMQP broker, for example ActiveMQ Artemis instance, 
> which was created with {{--require-login}}. The client gets stuck if you use 
> invalid credentials.
> {noformat}
> PN_TRACE_FRM=1 examples/cpp/simple_send -a amqp://127.0.0.1:5672 -u nosuch -p 
> user
> [0xed9980]:  -> SASL
> [0xed9980]:  <- SASL
> [0xed9980]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xed9980]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xed9980]:0 <- @sasl-outcome(68) [code=1]
> [0xed9980]:  -> EOS
> [0xee7290]:  -> SASL
> [0xee7290]:  <- SASL
> [0xee7290]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xee7290]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xee7290]:0 <- @sasl-outcome(68) [code=1]
> [0xee7290]:  -> EOS
> [0xeee6b0]:  -> SASL
> [0xeee6b0]:  <- SASL
> [0xeee6b0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xeee6b0]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xeee6b0]:0 <- @sasl-outcome(68) [code=1]
> [0xeee6b0]:  -> EOS
> {noformat}
> As you can see, the client keeps reconnecting. The previous behavior, if I 
> recall correctly, was to execute error handler in this case. To be exact, it 
> would run {{on_transport_error}} handler.
> I think that it is reasonable for the client to stop reconnecting and run 
> this handler if the reason for failed connection are wrong credentials. This 
> condition is unlikely to resolve itself on multiple retries.



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

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

[jira] [Resolved] (PROTON-1589) [cpp] How can I handle invalid SASL PLAIN credentials error when reconnect is on?

[Andrew Stitcher (JIRA)]

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

Andrew Stitcher resolved PROTON-1589.
-
   Resolution: Fixed
Fix Version/s: proton-c-0.22.0

> [cpp] How can I handle invalid SASL PLAIN credentials error when reconnect is 
> on?
> -
>
> Key: PROTON-1589
> URL: https://issues.apache.org/jira/browse/PROTON-1589
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>Priority: Major
>  Labels: sasl
> Fix For: proton-c-0.22.0
>
>
> Apply the following patch to the simple_send.cpp example
> {code}
> diff --git a/examples/cpp/simple_send.cpp b/examples/cpp/simple_send.cpp
> index a4c2272d..053da34f 100644
> --- a/examples/cpp/simple_send.cpp
> +++ b/examples/cpp/simple_send.cpp
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -53,6 +54,12 @@ class simple_send : public proton::messaging_handler {
>  proton::connection_options co;
>  if (!user.empty()) co.user(user);
>  if (!password.empty()) co.password(password);
> +co.sasl_enabled(true);
> +co.sasl_allow_insecure_mechs(true);
> +std::string sasl_mechanisms("PLAIN");
> +co.sasl_allowed_mechs(sasl_mechanisms);
> +proton::reconnect_options ro;
> +co.reconnect(ro);
>  sender = c.open_sender(url, co);
>  }
> {code}
> Now attempt to connect to AMQP broker, for example ActiveMQ Artemis instance, 
> which was created with {{--require-login}}. The client gets stuck if you use 
> invalid credentials.
> {noformat}
> PN_TRACE_FRM=1 examples/cpp/simple_send -a amqp://127.0.0.1:5672 -u nosuch -p 
> user
> [0xed9980]:  -> SASL
> [0xed9980]:  <- SASL
> [0xed9980]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xed9980]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xed9980]:0 <- @sasl-outcome(68) [code=1]
> [0xed9980]:  -> EOS
> [0xee7290]:  -> SASL
> [0xee7290]:  <- SASL
> [0xee7290]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xee7290]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xee7290]:0 <- @sasl-outcome(68) [code=1]
> [0xee7290]:  -> EOS
> [0xeee6b0]:  -> SASL
> [0xeee6b0]:  <- SASL
> [0xeee6b0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xeee6b0]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xeee6b0]:0 <- @sasl-outcome(68) [code=1]
> [0xeee6b0]:  -> EOS
> {noformat}
> As you can see, the client keeps reconnecting. The previous behavior, if I 
> recall correctly, was to execute error handler in this case. To be exact, it 
> would run {{on_transport_error}} handler.
> I think that it is reasonable for the client to stop reconnecting and run 
> this handler if the reason for failed connection are wrong credentials. This 
> condition is unlikely to resolve itself on multiple retries.



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

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

[jira] [Commented] (PROTON-1589) [cpp] How can I handle invalid SASL PLAIN credentials error when reconnect is on?

[Andrew Stitcher (JIRA)]

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

Andrew Stitcher commented on PROTON-1589:
-

The behaviour has now been changed so that the transport will "error" on the 
first authorization failure it receives and not retry any further urls even 
though they might not have the same authentication problem.

> [cpp] How can I handle invalid SASL PLAIN credentials error when reconnect is 
> on?
> -
>
> Key: PROTON-1589
> URL: https://issues.apache.org/jira/browse/PROTON-1589
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>Priority: Major
>  Labels: sasl
> Fix For: proton-c-0.22.0
>
>
> Apply the following patch to the simple_send.cpp example
> {code}
> diff --git a/examples/cpp/simple_send.cpp b/examples/cpp/simple_send.cpp
> index a4c2272d..053da34f 100644
> --- a/examples/cpp/simple_send.cpp
> +++ b/examples/cpp/simple_send.cpp
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -53,6 +54,12 @@ class simple_send : public proton::messaging_handler {
>  proton::connection_options co;
>  if (!user.empty()) co.user(user);
>  if (!password.empty()) co.password(password);
> +co.sasl_enabled(true);
> +co.sasl_allow_insecure_mechs(true);
> +std::string sasl_mechanisms("PLAIN");
> +co.sasl_allowed_mechs(sasl_mechanisms);
> +proton::reconnect_options ro;
> +co.reconnect(ro);
>  sender = c.open_sender(url, co);
>  }
> {code}
> Now attempt to connect to AMQP broker, for example ActiveMQ Artemis instance, 
> which was created with {{--require-login}}. The client gets stuck if you use 
> invalid credentials.
> {noformat}
> PN_TRACE_FRM=1 examples/cpp/simple_send -a amqp://127.0.0.1:5672 -u nosuch -p 
> user
> [0xed9980]:  -> SASL
> [0xed9980]:  <- SASL
> [0xed9980]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xed9980]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xed9980]:0 <- @sasl-outcome(68) [code=1]
> [0xed9980]:  -> EOS
> [0xee7290]:  -> SASL
> [0xee7290]:  <- SASL
> [0xee7290]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xee7290]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xee7290]:0 <- @sasl-outcome(68) [code=1]
> [0xee7290]:  -> EOS
> [0xeee6b0]:  -> SASL
> [0xeee6b0]:  <- SASL
> [0xeee6b0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xeee6b0]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xeee6b0]:0 <- @sasl-outcome(68) [code=1]
> [0xeee6b0]:  -> EOS
> {noformat}
> As you can see, the client keeps reconnecting. The previous behavior, if I 
> recall correctly, was to execute error handler in this case. To be exact, it 
> would run {{on_transport_error}} handler.
> I think that it is reasonable for the client to stop reconnecting and run 
> this handler if the reason for failed connection are wrong credentials. This 
> condition is unlikely to resolve itself on multiple retries.



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

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

[jira] [Commented] (PROTON-1589) [cpp] How can I handle invalid SASL PLAIN credentials error when reconnect is on?

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1589: [C++ binding] Test no reconnect on authentication failure


> [cpp] How can I handle invalid SASL PLAIN credentials error when reconnect is 
> on?
> -
>
> Key: PROTON-1589
> URL: https://issues.apache.org/jira/browse/PROTON-1589
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>Priority: Major
>  Labels: sasl
>
> Apply the following patch to the simple_send.cpp example
> {code}
> diff --git a/examples/cpp/simple_send.cpp b/examples/cpp/simple_send.cpp
> index a4c2272d..053da34f 100644
> --- a/examples/cpp/simple_send.cpp
> +++ b/examples/cpp/simple_send.cpp
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -53,6 +54,12 @@ class simple_send : public proton::messaging_handler {
>  proton::connection_options co;
>  if (!user.empty()) co.user(user);
>  if (!password.empty()) co.password(password);
> +co.sasl_enabled(true);
> +co.sasl_allow_insecure_mechs(true);
> +std::string sasl_mechanisms("PLAIN");
> +co.sasl_allowed_mechs(sasl_mechanisms);
> +proton::reconnect_options ro;
> +co.reconnect(ro);
>  sender = c.open_sender(url, co);
>  }
> {code}
> Now attempt to connect to AMQP broker, for example ActiveMQ Artemis instance, 
> which was created with {{--require-login}}. The client gets stuck if you use 
> invalid credentials.
> {noformat}
> PN_TRACE_FRM=1 examples/cpp/simple_send -a amqp://127.0.0.1:5672 -u nosuch -p 
> user
> [0xed9980]:  -> SASL
> [0xed9980]:  <- SASL
> [0xed9980]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xed9980]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xed9980]:0 <- @sasl-outcome(68) [code=1]
> [0xed9980]:  -> EOS
> [0xee7290]:  -> SASL
> [0xee7290]:  <- SASL
> [0xee7290]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xee7290]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xee7290]:0 <- @sasl-outcome(68) [code=1]
> [0xee7290]:  -> EOS
> [0xeee6b0]:  -> SASL
> [0xeee6b0]:  <- SASL
> [0xeee6b0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xeee6b0]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xeee6b0]:0 <- @sasl-outcome(68) [code=1]
> [0xeee6b0]:  -> EOS
> {noformat}
> As you can see, the client keeps reconnecting. The previous behavior, if I 
> recall correctly, was to execute error handler in this case. To be exact, it 
> would run {{on_transport_error}} handler.
> I think that it is reasonable for the client to stop reconnecting and run 
> this handler if the reason for failed connection are wrong credentials. This 
> condition is unlikely to resolve itself on multiple retries.



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

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

[jira] [Commented] (PROTON-1589) [cpp] How can I handle invalid SASL PLAIN credentials error when reconnect is on?

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1589: Fix reconnect API error


> [cpp] How can I handle invalid SASL PLAIN credentials error when reconnect is 
> on?
> -
>
> Key: PROTON-1589
> URL: https://issues.apache.org/jira/browse/PROTON-1589
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>Priority: Major
>  Labels: sasl
>
> Apply the following patch to the simple_send.cpp example
> {code}
> diff --git a/examples/cpp/simple_send.cpp b/examples/cpp/simple_send.cpp
> index a4c2272d..053da34f 100644
> --- a/examples/cpp/simple_send.cpp
> +++ b/examples/cpp/simple_send.cpp
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -53,6 +54,12 @@ class simple_send : public proton::messaging_handler {
>  proton::connection_options co;
>  if (!user.empty()) co.user(user);
>  if (!password.empty()) co.password(password);
> +co.sasl_enabled(true);
> +co.sasl_allow_insecure_mechs(true);
> +std::string sasl_mechanisms("PLAIN");
> +co.sasl_allowed_mechs(sasl_mechanisms);
> +proton::reconnect_options ro;
> +co.reconnect(ro);
>  sender = c.open_sender(url, co);
>  }
> {code}
> Now attempt to connect to AMQP broker, for example ActiveMQ Artemis instance, 
> which was created with {{--require-login}}. The client gets stuck if you use 
> invalid credentials.
> {noformat}
> PN_TRACE_FRM=1 examples/cpp/simple_send -a amqp://127.0.0.1:5672 -u nosuch -p 
> user
> [0xed9980]:  -> SASL
> [0xed9980]:  <- SASL
> [0xed9980]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xed9980]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xed9980]:0 <- @sasl-outcome(68) [code=1]
> [0xed9980]:  -> EOS
> [0xee7290]:  -> SASL
> [0xee7290]:  <- SASL
> [0xee7290]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xee7290]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xee7290]:0 <- @sasl-outcome(68) [code=1]
> [0xee7290]:  -> EOS
> [0xeee6b0]:  -> SASL
> [0xeee6b0]:  <- SASL
> [0xeee6b0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xeee6b0]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xeee6b0]:0 <- @sasl-outcome(68) [code=1]
> [0xeee6b0]:  -> EOS
> {noformat}
> As you can see, the client keeps reconnecting. The previous behavior, if I 
> recall correctly, was to execute error handler in this case. To be exact, it 
> would run {{on_transport_error}} handler.
> I think that it is reasonable for the client to stop reconnecting and run 
> this handler if the reason for failed connection are wrong credentials. This 
> condition is unlikely to resolve itself on multiple retries.



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

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

[jira] [Commented] (PROTON-1589) [cpp] How can I handle invalid SASL PLAIN credentials error when reconnect is on?

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1589: [C++ binding] Stop reconnect attempts on authorization failure


> [cpp] How can I handle invalid SASL PLAIN credentials error when reconnect is 
> on?
> -
>
> Key: PROTON-1589
> URL: https://issues.apache.org/jira/browse/PROTON-1589
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>Priority: Major
>  Labels: sasl
>
> Apply the following patch to the simple_send.cpp example
> {code}
> diff --git a/examples/cpp/simple_send.cpp b/examples/cpp/simple_send.cpp
> index a4c2272d..053da34f 100644
> --- a/examples/cpp/simple_send.cpp
> +++ b/examples/cpp/simple_send.cpp
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -53,6 +54,12 @@ class simple_send : public proton::messaging_handler {
>  proton::connection_options co;
>  if (!user.empty()) co.user(user);
>  if (!password.empty()) co.password(password);
> +co.sasl_enabled(true);
> +co.sasl_allow_insecure_mechs(true);
> +std::string sasl_mechanisms("PLAIN");
> +co.sasl_allowed_mechs(sasl_mechanisms);
> +proton::reconnect_options ro;
> +co.reconnect(ro);
>  sender = c.open_sender(url, co);
>  }
> {code}
> Now attempt to connect to AMQP broker, for example ActiveMQ Artemis instance, 
> which was created with {{--require-login}}. The client gets stuck if you use 
> invalid credentials.
> {noformat}
> PN_TRACE_FRM=1 examples/cpp/simple_send -a amqp://127.0.0.1:5672 -u nosuch -p 
> user
> [0xed9980]:  -> SASL
> [0xed9980]:  <- SASL
> [0xed9980]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xed9980]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xed9980]:0 <- @sasl-outcome(68) [code=1]
> [0xed9980]:  -> EOS
> [0xee7290]:  -> SASL
> [0xee7290]:  <- SASL
> [0xee7290]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xee7290]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xee7290]:0 <- @sasl-outcome(68) [code=1]
> [0xee7290]:  -> EOS
> [0xeee6b0]:  -> SASL
> [0xeee6b0]:  <- SASL
> [0xeee6b0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xeee6b0]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xeee6b0]:0 <- @sasl-outcome(68) [code=1]
> [0xeee6b0]:  -> EOS
> {noformat}
> As you can see, the client keeps reconnecting. The previous behavior, if I 
> recall correctly, was to execute error handler in this case. To be exact, it 
> would run {{on_transport_error}} handler.
> I think that it is reasonable for the client to stop reconnecting and run 
> this handler if the reason for failed connection are wrong credentials. This 
> condition is unlikely to resolve itself on multiple retries.



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

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

[jira] [Commented] (PROTON-1589) [cpp] How can I handle invalid SASL PLAIN credentials error when reconnect is on?

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1589: [C++ binding] Add reconnect option to simple_connect example
- This example now sports nearly every type of connection option:
  It'll soon be time to stop calling it "simple"!


> [cpp] How can I handle invalid SASL PLAIN credentials error when reconnect is 
> on?
> -
>
> Key: PROTON-1589
> URL: https://issues.apache.org/jira/browse/PROTON-1589
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>Priority: Major
>  Labels: sasl
>
> Apply the following patch to the simple_send.cpp example
> {code}
> diff --git a/examples/cpp/simple_send.cpp b/examples/cpp/simple_send.cpp
> index a4c2272d..053da34f 100644
> --- a/examples/cpp/simple_send.cpp
> +++ b/examples/cpp/simple_send.cpp
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -53,6 +54,12 @@ class simple_send : public proton::messaging_handler {
>  proton::connection_options co;
>  if (!user.empty()) co.user(user);
>  if (!password.empty()) co.password(password);
> +co.sasl_enabled(true);
> +co.sasl_allow_insecure_mechs(true);
> +std::string sasl_mechanisms("PLAIN");
> +co.sasl_allowed_mechs(sasl_mechanisms);
> +proton::reconnect_options ro;
> +co.reconnect(ro);
>  sender = c.open_sender(url, co);
>  }
> {code}
> Now attempt to connect to AMQP broker, for example ActiveMQ Artemis instance, 
> which was created with {{--require-login}}. The client gets stuck if you use 
> invalid credentials.
> {noformat}
> PN_TRACE_FRM=1 examples/cpp/simple_send -a amqp://127.0.0.1:5672 -u nosuch -p 
> user
> [0xed9980]:  -> SASL
> [0xed9980]:  <- SASL
> [0xed9980]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xed9980]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xed9980]:0 <- @sasl-outcome(68) [code=1]
> [0xed9980]:  -> EOS
> [0xee7290]:  -> SASL
> [0xee7290]:  <- SASL
> [0xee7290]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xee7290]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xee7290]:0 <- @sasl-outcome(68) [code=1]
> [0xee7290]:  -> EOS
> [0xeee6b0]:  -> SASL
> [0xeee6b0]:  <- SASL
> [0xeee6b0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xeee6b0]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00nosuch\x00user"]
> [0xeee6b0]:0 <- @sasl-outcome(68) [code=1]
> [0xeee6b0]:  -> EOS
> {noformat}
> As you can see, the client keeps reconnecting. The previous behavior, if I 
> recall correctly, was to execute error handler in this case. To be exact, it 
> would run {{on_transport_error}} handler.
> I think that it is reasonable for the client to stop reconnecting and run 
> this handler if the reason for failed connection are wrong credentials. This 
> condition is unlikely to resolve itself on multiple retries.



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

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