date:20170921

[GitHub] qpid-cpp pull request #10: Assorted C++ build fixes for review

2017-09-21 Thread ssorj

GitHub user ssorj opened a pull request:

https://github.com/apache/qpid-cpp/pull/10

Assorted C++ build fixes for review

Do not merge.  For review purposes only.

This includes the sketchy initialization changes to make things compile on 
Fedora 26.  It now also includes the clang linking fix, eliminates the swig 
cmake warnings, and bumps the max tested proton version.

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

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

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

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


commit be2668472f8cf82afa181d523a328ac8b289e933
Author: Justin Ross 
Date:   2017-09-20T23:11:58Z

QPID-7893: Dubious fixes for initialization warnings

commit f32608eaa665c6e107da8e80e4300718310db172
Author: Justin Ross 
Date:   2017-09-21T23:46:55Z

QPID-7713: The proximate fix for the clang linking problem

commit ac94a96dfe1319b5cf65070750c9e4620acb8442
Author: Justin Ross 
Date:   2017-09-22T00:09:37Z

QPID-7860: Fix swig deprecation warnings

commit 64b0cdafd51c4d0db3faca12e873236112fb3b53
Author: Justin Ross 
Date:   2017-09-22T00:24:38Z

QPID-7920: Increment the max safe proton version




---

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

[jira] [Commented] (QPID-7893) compilation failure on Fedora 26

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


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

ASF GitHub Bot commented on QPID-7893:
--

Github user ssorj closed the pull request at:

https://github.com/apache/qpid-cpp/pull/9


> compilation failure on Fedora 26
> 
>
> Key: QPID-7893
> URL: https://issues.apache.org/jira/browse/QPID-7893
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, C++ Build, C++ Client
>Affects Versions: qpid-cpp-1.37.0
> Environment: Fedora 26
> GCC reports version as "gcc (GCC) 7.1.1 20170622 (Red Hat 7.1.1-3)"
> commit 55d4171a8155d9f6a07a48507e33d43b8cb6d904 from qpid-cpp master
>Reporter: Robbie Gemmell
>Assignee: Justin Ross
>Priority: Critical
> Fix For: qpid-cpp-1.37.0
>
> Attachments: compile-failure.txt
>
>
> When trying to compile qpid-cpp master (commit 
> 55d4171a8155d9f6a07a48507e33d43b8cb6d904) on Fedora 26, I get some 
> 'maybe-uninitialized' related complication failures (see attachment). 
> Adding "-DCMAKE_CXX_FLAGS=-Wno-error=maybe-uninitialized" to the initial 
> cmake run seemed to get things going though obviously might not be correct.



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

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

[GitHub] qpid-cpp pull request #9: Highly sketchy fixes for initialization warnings

2017-09-21 Thread ssorj

Github user ssorj closed the pull request at:

https://github.com/apache/qpid-cpp/pull/9


---

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

[jira] [Updated] (QPID-7920) Qpid C++ 1.37.0 release tasks

2017-09-21 Thread Justin Ross (JIRA)


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

Justin Ross updated QPID-7920:
--
Fix Version/s: (was: qpid-cpp-1.36.0)
   qpid-cpp-1.37.0

> Qpid C++ 1.37.0 release tasks
> -
>
> Key: QPID-7920
> URL: https://issues.apache.org/jira/browse/QPID-7920
> Project: Qpid
>  Issue Type: Task
>  Components: C++ Broker, C++ Client
>Reporter: Justin Ross
>Assignee: Robbie Gemmell
> Fix For: qpid-cpp-1.37.0
>
>




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

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

[jira] [Created] (QPID-7920) Qpid C++ 1.37.0 release tasks

2017-09-21 Thread Justin Ross (JIRA)

Justin Ross created QPID-7920:
-

 Summary: Qpid C++ 1.37.0 release tasks
 Key: QPID-7920
 URL: https://issues.apache.org/jira/browse/QPID-7920
 Project: Qpid
  Issue Type: Task
  Components: C++ Broker, C++ Client
Reporter: Justin Ross
Assignee: Robbie Gemmell
 Fix For: qpid-cpp-1.36.0






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

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

[jira] [Resolved] (QPID-7861) [cpp] Provide systemd scripts for Fedora

2017-09-21 Thread Justin Ross (JIRA)


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

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

> [cpp] Provide systemd scripts for Fedora
> 
>
> Key: QPID-7861
> URL: https://issues.apache.org/jira/browse/QPID-7861
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker, C++ Client
>Affects Versions: qpid-cpp-1.36.0
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: qpid-cpp-1.37.0
>
>
> For use by Fedora packaging and Docker images based on Fedora.  These will 
> reside under qpid-cpp/etc/fedora in the source tree.



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

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

[jira] [Commented] (QPID-7895) [linearstore] Excessive CPU utilization for some kernel clocksources

2017-09-21 Thread Justin Ross (JIRA)


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

Justin Ross commented on QPID-7895:
---

[~kpvdr]?

> [linearstore] Excessive CPU utilization for some kernel clocksources
> 
>
> Key: QPID-7895
> URL: https://issues.apache.org/jira/browse/QPID-7895
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
> Fix For: qpid-cpp-1.37.0
>
>
> For some kernel clocksources (eg acpi_pm), it has been observed that there is 
> an excessively high CPU utilization which correlates with the linearstore's 
> flush timeout being set to a very low value (100us).  This is a problem for 
> some customers which require almost instant flush to obtain 
> pseudo-synchronous store behavior (hence the 100us flush timer) and run many 
> brokers (up to hundreds) on a single machine.  In these cases, the CPU is 
> 100% utilized.
> A check of the source shows that the flush timer is firing continuously, 
> irrespective of whether any disk I/O has taken place.
> It is proposed that a change to linearstore be made which will only run the 
> timer when needed (ie while there is content in the write buffers that needs 
> flushing).



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

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

[jira] [Created] (DISPATCH-835) The DETACH/CLOSE sequence causes a memory leak

2017-09-21 Thread Ted Ross (JIRA)

Ted Ross created DISPATCH-835:
-

 Summary: The DETACH/CLOSE sequence causes a memory leak
 Key: DISPATCH-835
 URL: https://issues.apache.org/jira/browse/DISPATCH-835
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Router Node
Affects Versions: 0.8.0
Reporter: Ted Ross
Assignee: Ted Ross
 Fix For: 1.0.0


If a client connects to a router and attaches one of more links, then in one 
synchronous sequence, detaches the links and closes the connection, memory 
objects associated with the link will be leaked.



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

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

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

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


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

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

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

PROTON-1512: c examples use recommended PN_DELIVERY pattern

Fixed the C examples to use the recommended pattern of always reading data
on a PN_DELIVERY event. Letting data accumulate in proton can cause a hang
if a message is larger than the session flow-control limit.


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



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

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

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

2017-09-21 Thread Alan Conway (JIRA)


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

Alan Conway commented on PROTON-1512:
-

It has been pointed out that it is not easy to tell whether an outgoing 
delivery in proton actually has had any frames sent or not. PN_FLOW events are 
ambiguous, they can mean data sent on wire OR credit received from remote so 
that's not reliable. Need to determine if we can use existing functions to 
determine that reliably, and if not add one. Also we should probably have 
abort() automatically drop the message if nothing is already sent and send an 
aborted=true frame only if the message has been partially framed already.

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



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

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

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

2017-09-21 Thread Alan Conway (JIRA)


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

Alan Conway commented on PROTON-1512:
-

[~gemmellr] +1

For link routing the router simply forwards frames verbatim.

You're correct about the potential block for method A: dispatch doesn't do this 
but some of our examples and bindings do; so we want to make sure they get an 
error at least for an abort till we can fix them all.

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



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

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

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

2017-09-21 Thread Robbie Gemmell (JIRA)


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

Robbie Gemmell commented on PROTON-1512:


On the comments around whether its ok for the router to drop an aborted message 
not yet partly passed on toa peer, would I be right to assume thats around 
message-routing and that for link-routing the transfers would always be 
forwarded as-is?

On Alans A/B scenario, to complicate matters slightly more I'd note that A may 
already be subject to potential hang/stall/never finish even without aborted 
transfers, if session flow control is in play enforcing protons 'session 
capacity' and the window becomes full before the message is complete. I believe 
that only effectively happens if you set a max frame size currently though.

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



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

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

[jira] [Commented] (PROTON-1532) Undefined method "plain" for SASL in Ruby binding

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


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

ASF GitHub Bot commented on PROTON-1532:


Github user alanconway commented on the issue:

https://github.com/apache/qpid-proton/pull/116
  
Sorry if I overlooked you questions on the mailing list. It should be
updated as part of the next proton-c release (0.18) which is Coming Any
Time Now. Part of what needs to be finished is my current effort to fix a
bunch of long-standing issues in the ruby binding - if you search the JIRA
for ruby issues targeted for 0.18 you'll see more details. I'm close, sooo
close...

On Thu, Sep 21, 2017 at 8:48 AM, Gregor Berginc 
wrote:

> @alanconway  Sorry for asking as part of
> this PR, but I wonder if you are aware of any update on the release of
> qpid_proton gem? I've asked in the users mailing list with no response,
> however I somewhat depend on this bug being resolved for further
> integration.
>
> Thanks!
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> 

> .
>



> Undefined method "plain" for SASL in Ruby binding
> -
>
> Key: PROTON-1532
> URL: https://issues.apache.org/jira/browse/PROTON-1532
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
> Environment: Centos, Ubuntu
>Reporter: Gregor Berginc
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> When I try to connect to an AMQP endpoint using the URL of the form 
> amqp://user:password@host:port, I get an error about a missing "plain" 
> method. This occurs in [this 
> line|https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/ruby/lib/reactor/connector.rb#L91].
>  This error can be reproduced simply using the following code
> {code:ruby}
> 2.3.3 :001 > require "qpid_proton"
>  => true 
> 2.3.3 :002 > transport = Qpid::Proton::Transport.new
>  => # @impl=# @__swigtype__="_p_pn_transport_t", 
> @proton_wrapper=#>> 
> 2.3.3 :003 > sasl = transport.sasl
>  => # @impl=# @__swigtype__="_p_pn_sasl_t">> 
> 2.3.3 :004 > sasl.plain('', '')
> NoMethodError: undefined method `plain' for 
> #
> from (irb):4
> from /usr/share/rvm/rubies/ruby-2.3.3/bin/irb:11:in `'
> {code}
> I have tried in Ubuntu 16.04 installing Proton via system packages and gem 
> 0.10.1 from Rubygems as well as in Centos 7, following the source code 
> install guide.
> I wonder if this method should be exposed by Swig somehow? Python binding 
> does not use it in that way, but it does set the username and password on the 
> connection.



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

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

[GitHub] qpid-proton issue #116: PROTON-1532: Allow insecure mechanism in SASL

2017-09-21 Thread alanconway

Github user alanconway commented on the issue:

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

Sorry if I overlooked you questions on the mailing list. It should be
updated as part of the next proton-c release (0.18) which is Coming Any
Time Now. Part of what needs to be finished is my current effort to fix a
bunch of long-standing issues in the ruby binding - if you search the JIRA
for ruby issues targeted for 0.18 you'll see more details. I'm close, sooo
close...

On Thu, Sep 21, 2017 at 8:48 AM, Gregor Berginc 
wrote:

> @alanconway  Sorry for asking as part of
> this PR, but I wonder if you are aware of any update on the release of
> qpid_proton gem? I've asked in the users mailing list with no response,
> however I somewhat depend on this bug being resolved for further
> integration.
>
> Thanks!
>
> â
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> 

> .
>

---

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

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

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


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

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

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

PROTON-1512: Fixes and doc clarifications for pn_delivery_aborted()

- added explict PN_ABORTED error code (PN_STATE_ERR has another meaning in this 
context)
- fixed initialization bug for aborted flag
- enforce discarding all data for aborted frames on sender and receiver, for 
interop sanity
- clarified docs - see below

Goal is to enable *correct* use of abort while minimizing interop problems with 
existing
abort-unaware proton code (and other AMQP clients)

The only correct use of abort is when part of a message has already been
sent. In a router, an incoming message can be aborted before any of it has been
forwarded, or even before enough headers have been acquired to know how to
forward it. Such messages should simply not be forwarded at all. Dispatch
doesn't (shouldn't) promise frame-by-frame identity for message routing so
silently dropping an early-aborted message is entirely valid and
unavoidable. Using abort is only valid when part of a message has already been
forwarded.

Here's the explanation of the backwards-compatibility problem:

/**
 * Check if a received delivery has been aborted.
 *
 * An aborted delivery means the sender cannot complete the message and the
 * receiver should discard any data already received. There is nothing further
 * to be done with the delivery: it is pn_delivery_settled() and pn_link_recv()
 * returns ::PN_ABORTED.
 *
 * For backward compatibility with code that does not check 
pn_delivery_aborted(),
 * the following are true of an aborted delivery:
 *
 * - pn_delivery_partial() is false - old code will not wait forever for more 
data
 *
 * - pn_delivery_pending() returns 1, not 0 - old code that checks for 
completion with
 *
 *   if (pn_delivery_pending(d)==0 && !pn_delivery_partial(d))
 *
 *   will not mistake this for successful completion, and will call 
pn_link_recv()
 *
 * - pn_link_recv() returns ::PN_ABORTED - old code will know there is some 
kind of error.
 *
 * @see pn_delivery_abort()
 * @param[in] delivery a delivery object
 * @return true if the delivery has been aborted, false otherwise
 */
PN_EXTERN bool pn_delivery_aborted(pn_delivery_t *delivery);


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



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

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

[jira] [Commented] (DISPATCH-773) Implement a 2-phase start in the Dispatch Router

2017-09-21 Thread Adel Boutros (JIRA)


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

Adel Boutros commented on DISPATCH-773:
---

Hello Ted,

* If a consumer connects and no address is configured, then a local address is 
created.
* If the address is created with Waypoint attribute, consumers and producers 
will not create local address.
If you confirm that both of my statements are true, then even for the dynamic 
addressing, we can avoid the problem by making sure addresses are created and 
configured before any consumers are attached.

Another solution I can see is to have an option which explicitly says this 
router will only use brokers for persistence. So the option would simply 
prohibit the creation of local addresses. In that case any consumer/producer 
trying to connect will receive an error ("amqp:not-found" for example). Does 
this solution map to your 2nd workaround (defaultDistribution to "unavailable") 
?

> Implement a 2-phase start in the Dispatch Router
> 
>
> Key: DISPATCH-773
> URL: https://issues.apache.org/jira/browse/DISPATCH-773
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Routing Engine
>Reporter: Adel Boutros
>Assignee: Ted Ross
>
> All the needed information could be found here:
> http://qpid.2158936.n2.nabble.com/Dispatch-router-2-phase-start-td7663118.html



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

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

[jira] [Commented] (QPID-7872) [Java Broker] [AMQP 1.0] Message expiry should be driven from ttl header only

2017-09-21 Thread Lorenz Quack (JIRA)


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

Lorenz Quack commented on QPID-7872:


Looking at the code again I can't see any place where we interpret TTL=0 as not 
set.
It seems like I made my comment in error. I apologise.

> [Java Broker] [AMQP 1.0] Message expiry should be driven from ttl header only
> -
>
> Key: QPID-7872
> URL: https://issues.apache.org/jira/browse/QPID-7872
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> Java broker should only discard message with ttl header set if TTL expires 
> including 0 values. Ensure TTL is adjusted before sending the message.



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

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

[jira] [Updated] (PROTON-1560) Cannot install qpid_proton-0.18.0.gem

2017-09-21 Thread Justin Ross (JIRA)


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

Justin Ross updated PROTON-1560:

Fix Version/s: proton-c-0.18.0

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



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

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

[jira] [Commented] (QPID-7564) Add competing consumer test to the performance test suite

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


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

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

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

QPID-7564: [Java Broker, Perftests] Add competing consumer test case to 
defaultTests.js


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



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

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

[jira] [Commented] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1

2017-09-21 Thread Robbie Gemmell (JIRA)


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

Robbie Gemmell commented on QPIDJMS-325:


For what its worth, add the Qpid AMQP 0-x JMS client to the list that seem 
(again, didint try) like they would return -1.

Also, in looking at the ActiveMQ 5.x client earlier (after investigation how I 
might change the Qpid client) I came to realise its current readBytes() impl is 
essentially identical to the Qpid JMS one. Trying the test with it, the 
ActiveMQ 5.x client also returns -1 immediately for me, not 0.

> reading from empty buffer of a BytesMessage should return 0, not -1
> ---
>
> Key: QPIDJMS-325
> URL: https://issues.apache.org/jira/browse/QPIDJMS-325
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> Consider the following test. According to 
> http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
>  the #readBytes method should return 0 when it is first called, as the number 
> of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it 
> should return -1. What happens now is that the method returns -1 the first 
> time.
> See the commented lines to try the same thing with ActiveMQ JMS Client 
> library, and with StreamMessage instead of BytesMessage. The behavior there 
> should be the same.
> ActiveMQ passes the test with BytesMessage and fails it with StreamMessage. 
> Qpid JMS fails with BytesMessage and passes with StreamMessage.
> {code}
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.qpid.jms.JmsConnectionFactory;
> import org.junit.Test;
> import javax.jms.*;
> import static com.google.common.truth.Truth.assertThat;
> public class EmptyBufferInputTest {
> @Test
> public void testEmptyBufferInput() throws JMSException {
> //ConnectionFactory connectionFactory = new 
> ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
> JmsConnectionFactory connectionFactory = new 
> JmsConnectionFactory("amqp://127.0.0.1:5672");
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false, 
> Session.AUTO_ACKNOWLEDGE);
> final byte[] BYTE_LIST = {1, 2, 4};
> //StreamMessage message = session.createStreamMessage();
> BytesMessage message = session.createBytesMessage();
> message.clearBody();
> byte[] readList = new byte[BYTE_LIST.length - 1];
> byte[] emptyList = {};
> message.writeBytes(emptyList);
> message.reset();
> final int IS_EMPTY = 0;
> assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
> }
> }
> {code}



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

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

[jira] [Resolved] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1

2017-09-21 Thread Robbie Gemmell (JIRA)


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

Robbie Gemmell resolved QPIDJMS-325.

Resolution: Not A Problem

> reading from empty buffer of a BytesMessage should return 0, not -1
> ---
>
> Key: QPIDJMS-325
> URL: https://issues.apache.org/jira/browse/QPIDJMS-325
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> Consider the following test. According to 
> http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
>  the #readBytes method should return 0 when it is first called, as the number 
> of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it 
> should return -1. What happens now is that the method returns -1 the first 
> time.
> See the commented lines to try the same thing with ActiveMQ JMS Client 
> library, and with StreamMessage instead of BytesMessage. The behavior there 
> should be the same.
> ActiveMQ passes the test with BytesMessage and fails it with StreamMessage. 
> Qpid JMS fails with BytesMessage and passes with StreamMessage.
> {code}
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.qpid.jms.JmsConnectionFactory;
> import org.junit.Test;
> import javax.jms.*;
> import static com.google.common.truth.Truth.assertThat;
> public class EmptyBufferInputTest {
> @Test
> public void testEmptyBufferInput() throws JMSException {
> //ConnectionFactory connectionFactory = new 
> ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
> JmsConnectionFactory connectionFactory = new 
> JmsConnectionFactory("amqp://127.0.0.1:5672");
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false, 
> Session.AUTO_ACKNOWLEDGE);
> final byte[] BYTE_LIST = {1, 2, 4};
> //StreamMessage message = session.createStreamMessage();
> BytesMessage message = session.createBytesMessage();
> message.clearBody();
> byte[] readList = new byte[BYTE_LIST.length - 1];
> byte[] emptyList = {};
> message.writeBytes(emptyList);
> message.reset();
> final int IS_EMPTY = 0;
> assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
> }
> }
> {code}



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

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

[jira] [Reopened] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1

2017-09-21 Thread Robbie Gemmell (JIRA)


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

Robbie Gemmell reopened QPIDJMS-325:


> reading from empty buffer of a BytesMessage should return 0, not -1
> ---
>
> Key: QPIDJMS-325
> URL: https://issues.apache.org/jira/browse/QPIDJMS-325
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> Consider the following test. According to 
> http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
>  the #readBytes method should return 0 when it is first called, as the number 
> of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it 
> should return -1. What happens now is that the method returns -1 the first 
> time.
> See the commented lines to try the same thing with ActiveMQ JMS Client 
> library, and with StreamMessage instead of BytesMessage. The behavior there 
> should be the same.
> ActiveMQ passes the test with BytesMessage and fails it with StreamMessage. 
> Qpid JMS fails with BytesMessage and passes with StreamMessage.
> {code}
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.qpid.jms.JmsConnectionFactory;
> import org.junit.Test;
> import javax.jms.*;
> import static com.google.common.truth.Truth.assertThat;
> public class EmptyBufferInputTest {
> @Test
> public void testEmptyBufferInput() throws JMSException {
> //ConnectionFactory connectionFactory = new 
> ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
> JmsConnectionFactory connectionFactory = new 
> JmsConnectionFactory("amqp://127.0.0.1:5672");
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false, 
> Session.AUTO_ACKNOWLEDGE);
> final byte[] BYTE_LIST = {1, 2, 4};
> //StreamMessage message = session.createStreamMessage();
> BytesMessage message = session.createBytesMessage();
> message.clearBody();
> byte[] readList = new byte[BYTE_LIST.length - 1];
> byte[] emptyList = {};
> message.writeBytes(emptyList);
> message.reset();
> final int IS_EMPTY = 0;
> assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
> }
> }
> {code}



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

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

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

2017-09-21 Thread Chuck Rolke (JIRA)


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

Chuck Rolke commented on PROTON-1512:
-

If you want to have existing clients not hang then I agree with returning an 
error immediately. Those same clients may have some of the same issues running 
0.17 proton when an aborted message is received and the more flag is not 
overridden by the abort.

Regarding the degenerate case of having the first frame of a message with 
aborted=true, sense could be made with a log entry on the order of "DEBUG 
Aborted message received on link _linkname_".

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



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

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

[jira] [Assigned] (DISPATCH-834) Create config tool to create/read/update/delete router config files

2017-09-21 Thread Ernest Allen (JIRA)


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

Ernest Allen reassigned DISPATCH-834:
-

Assignee: Ernest Allen

> Create config tool to create/read/update/delete router config files
> ---
>
> Key: DISPATCH-834
> URL: https://issues.apache.org/jira/browse/DISPATCH-834
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Console
>Affects Versions: 0.8.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>
> Create a UI and supporting program that reads/updates/writes/deletes router 
> config files.
> It should at least:
> - read all config files in a directory and display a topology
> - create new directories to store config files
> - create connectors/listeners between routers with correct host:port
> - allow creating/editing/deleting of external 
> listeners/connectors/sslProfiles/log sections
>  



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

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

[jira] [Assigned] (DISPATCH-833) Remove 'Add mode' from hawtio and stand-alone consoles

2017-09-21 Thread Ernest Allen (JIRA)


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

Ernest Allen reassigned DISPATCH-833:
-

Assignee: Ernest Allen

> Remove 'Add mode' from hawtio and stand-alone consoles
> --
>
> Key: DISPATCH-833
> URL: https://issues.apache.org/jira/browse/DISPATCH-833
> Project: Qpid Dispatch
>  Issue Type: Task
>  Components: Console
>Affects Versions: 0.8.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>
> The hawtio and stand-alone console have a mode that allows the user to add a 
> new router to the UI, edit the config file for the new router, and then 
> download/copy the new config file.
> This should be removed since that functionality has been moved/expanded in 
> the new config tool. 



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

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

[jira] [Created] (DISPATCH-834) Create config tool to create/read/update/delete router config files

2017-09-21 Thread Ernest Allen (JIRA)

Ernest Allen created DISPATCH-834:
-

 Summary: Create config tool to create/read/update/delete router 
config files
 Key: DISPATCH-834
 URL: https://issues.apache.org/jira/browse/DISPATCH-834
 Project: Qpid Dispatch
  Issue Type: New Feature
  Components: Console
Affects Versions: 0.8.0
Reporter: Ernest Allen


Create a UI and supporting program that reads/updates/writes/deletes router 
config files.

It should at least:
- read all config files in a directory and display a topology
- create new directories to store config files
- create connectors/listeners between routers with correct host:port
- allow creating/editing/deleting of external 
listeners/connectors/sslProfiles/log sections
 



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

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

[jira] [Created] (DISPATCH-833) Remove 'Add mode' from hawtio and stand-alone consoles

2017-09-21 Thread Ernest Allen (JIRA)

Ernest Allen created DISPATCH-833:
-

 Summary: Remove 'Add mode' from hawtio and stand-alone consoles
 Key: DISPATCH-833
 URL: https://issues.apache.org/jira/browse/DISPATCH-833
 Project: Qpid Dispatch
  Issue Type: Task
  Components: Console
Affects Versions: 0.8.0
Reporter: Ernest Allen


The hawtio and stand-alone console have a mode that allows the user to add a 
new router to the UI, edit the config file for the new router, and then 
download/copy the new config file.

This should be removed since that functionality has been moved/expanded in the 
new config tool. 



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

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

[jira] [Commented] (PROTON-1532) Undefined method "plain" for SASL in Ruby binding

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


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

ASF GitHub Bot commented on PROTON-1532:


Github user gberginc commented on the issue:

https://github.com/apache/qpid-proton/pull/116
  
@alanconway Sorry for asking as part of this PR, but I wonder if you are 
aware of any update on the release of qpid_proton gem? I've asked in the users 
mailing list with no response, however I somewhat depend on this bug being 
resolved for further integration.

Thanks!


> Undefined method "plain" for SASL in Ruby binding
> -
>
> Key: PROTON-1532
> URL: https://issues.apache.org/jira/browse/PROTON-1532
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
> Environment: Centos, Ubuntu
>Reporter: Gregor Berginc
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> When I try to connect to an AMQP endpoint using the URL of the form 
> amqp://user:password@host:port, I get an error about a missing "plain" 
> method. This occurs in [this 
> line|https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/ruby/lib/reactor/connector.rb#L91].
>  This error can be reproduced simply using the following code
> {code:ruby}
> 2.3.3 :001 > require "qpid_proton"
>  => true 
> 2.3.3 :002 > transport = Qpid::Proton::Transport.new
>  => # @impl=# @__swigtype__="_p_pn_transport_t", 
> @proton_wrapper=#>> 
> 2.3.3 :003 > sasl = transport.sasl
>  => # @impl=# @__swigtype__="_p_pn_sasl_t">> 
> 2.3.3 :004 > sasl.plain('', '')
> NoMethodError: undefined method `plain' for 
> #
> from (irb):4
> from /usr/share/rvm/rubies/ruby-2.3.3/bin/irb:11:in `'
> {code}
> I have tried in Ubuntu 16.04 installing Proton via system packages and gem 
> 0.10.1 from Rubygems as well as in Centos 7, following the source code 
> install guide.
> I wonder if this method should be exposed by Swig somehow? Python binding 
> does not use it in that way, but it does set the username and password on the 
> connection.



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

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

[GitHub] qpid-proton issue #116: PROTON-1532: Allow insecure mechanism in SASL

2017-09-21 Thread gberginc

Github user gberginc commented on the issue:

https://github.com/apache/qpid-proton/pull/116
  
@alanconway Sorry for asking as part of this PR, but I wonder if you are 
aware of any update on the release of qpid_proton gem? I've asked in the users 
mailing list with no response, however I somewhat depend on this bug being 
resolved for further integration.

Thanks!


---

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

[jira] [Commented] (QPID-7893) compilation failure on Fedora 26

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


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

ASF GitHub Bot commented on QPID-7893:
--

GitHub user ssorj opened a pull request:

https://github.com/apache/qpid-cpp/pull/9

Highly sketchy fixes for initialization warnings

Don't merge this.

This commit gets things building on Fedora 26, addressing QPID-7893 [1].  
I'm stabbing in the dark when it comes to C++ initialization.  Please help me 
determine if these changes are correct and harmless.

[1]: https://issues.apache.org/jira/browse/QPID-7893

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

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

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

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


commit be2668472f8cf82afa181d523a328ac8b289e933
Author: Justin Ross 
Date:   2017-09-20T23:11:58Z

QPID-7893: Dubious fixes for initialization warnings




> compilation failure on Fedora 26
> 
>
> Key: QPID-7893
> URL: https://issues.apache.org/jira/browse/QPID-7893
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, C++ Build, C++ Client
>Affects Versions: qpid-cpp-1.37.0
> Environment: Fedora 26
> GCC reports version as "gcc (GCC) 7.1.1 20170622 (Red Hat 7.1.1-3)"
> commit 55d4171a8155d9f6a07a48507e33d43b8cb6d904 from qpid-cpp master
>Reporter: Robbie Gemmell
>Assignee: Justin Ross
>Priority: Critical
> Fix For: qpid-cpp-1.37.0
>
> Attachments: compile-failure.txt
>
>
> When trying to compile qpid-cpp master (commit 
> 55d4171a8155d9f6a07a48507e33d43b8cb6d904) on Fedora 26, I get some 
> 'maybe-uninitialized' related complication failures (see attachment). 
> Adding "-DCMAKE_CXX_FLAGS=-Wno-error=maybe-uninitialized" to the initial 
> cmake run seemed to get things going though obviously might not be correct.



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

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

[GitHub] qpid-cpp pull request #9: Highly sketchy fixes for initialization warnings

2017-09-21 Thread ssorj

GitHub user ssorj opened a pull request:

https://github.com/apache/qpid-cpp/pull/9

Highly sketchy fixes for initialization warnings

Don't merge this.

This commit gets things building on Fedora 26, addressing QPID-7893 [1].  
I'm stabbing in the dark when it comes to C++ initialization.  Please help me 
determine if these changes are correct and harmless.

[1]: https://issues.apache.org/jira/browse/QPID-7893

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

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

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

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


commit be2668472f8cf82afa181d523a328ac8b289e933
Author: Justin Ross 
Date:   2017-09-20T23:11:58Z

QPID-7893: Dubious fixes for initialization warnings




---

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

[jira] [Closed] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1

2017-09-21 Thread JIRA


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

Jiri Daněk closed QPIDJMS-325.
--
Resolution: Not A Problem

> reading from empty buffer of a BytesMessage should return 0, not -1
> ---
>
> Key: QPIDJMS-325
> URL: https://issues.apache.org/jira/browse/QPIDJMS-325
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> Consider the following test. According to 
> http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
>  the #readBytes method should return 0 when it is first called, as the number 
> of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it 
> should return -1. What happens now is that the method returns -1 the first 
> time.
> See the commented lines to try the same thing with ActiveMQ JMS Client 
> library, and with StreamMessage instead of BytesMessage. The behavior there 
> should be the same.
> ActiveMQ passes the test with BytesMessage and fails it with StreamMessage. 
> Qpid JMS fails with BytesMessage and passes with StreamMessage.
> {code}
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.qpid.jms.JmsConnectionFactory;
> import org.junit.Test;
> import javax.jms.*;
> import static com.google.common.truth.Truth.assertThat;
> public class EmptyBufferInputTest {
> @Test
> public void testEmptyBufferInput() throws JMSException {
> //ConnectionFactory connectionFactory = new 
> ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
> JmsConnectionFactory connectionFactory = new 
> JmsConnectionFactory("amqp://127.0.0.1:5672");
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false, 
> Session.AUTO_ACKNOWLEDGE);
> final byte[] BYTE_LIST = {1, 2, 4};
> //StreamMessage message = session.createStreamMessage();
> BytesMessage message = session.createBytesMessage();
> message.clearBody();
> byte[] readList = new byte[BYTE_LIST.length - 1];
> byte[] emptyList = {};
> message.writeBytes(emptyList);
> message.reset();
> final int IS_EMPTY = 0;
> assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
> }
> }
> {code}



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

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

[jira] [Commented] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1

2017-09-21 Thread Robbie Gemmell (JIRA)


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

Robbie Gemmell commented on QPIDJMS-325:


The first pattern is how I would often expect it to be used, excepting 
potentially very large content, since BytesMessage does not dictate that you 
must read it repeatedly like StreamMessage does, theres only one chunk of data, 
and it has a method to give you the length of the content whereas StreamMessage 
does not, so you need to demarcate things with StreamMessage.

The BytesMessage javadoc overview notes thats its methods are largely based on 
DataInputStream and DataOutputStream. The readBytes of DataInputStream returns 
-1 immediately, which is where we get it from. From looking, but not trying, 
the JMS reference implementation (which makes even more direct use of 
DataInputStream than we do) and ActiveMQ Artemis clients (which I now realise 
you just mentioned also :P) seem like they would behave the same way Qpid JMS 
currently does.

> reading from empty buffer of a BytesMessage should return 0, not -1
> ---
>
> Key: QPIDJMS-325
> URL: https://issues.apache.org/jira/browse/QPIDJMS-325
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> Consider the following test. According to 
> http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
>  the #readBytes method should return 0 when it is first called, as the number 
> of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it 
> should return -1. What happens now is that the method returns -1 the first 
> time.
> See the commented lines to try the same thing with ActiveMQ JMS Client 
> library, and with StreamMessage instead of BytesMessage. The behavior there 
> should be the same.
> ActiveMQ passes the test with BytesMessage and fails it with StreamMessage. 
> Qpid JMS fails with BytesMessage and passes with StreamMessage.
> {code}
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.qpid.jms.JmsConnectionFactory;
> import org.junit.Test;
> import javax.jms.*;
> import static com.google.common.truth.Truth.assertThat;
> public class EmptyBufferInputTest {
> @Test
> public void testEmptyBufferInput() throws JMSException {
> //ConnectionFactory connectionFactory = new 
> ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
> JmsConnectionFactory connectionFactory = new 
> JmsConnectionFactory("amqp://127.0.0.1:5672");
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false, 
> Session.AUTO_ACKNOWLEDGE);
> final byte[] BYTE_LIST = {1, 2, 4};
> //StreamMessage message = session.createStreamMessage();
> BytesMessage message = session.createBytesMessage();
> message.clearBody();
> byte[] readList = new byte[BYTE_LIST.length - 1];
> byte[] emptyList = {};
> message.writeBytes(emptyList);
> message.reset();
> final int IS_EMPTY = 0;
> assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
> }
> }
> {code}



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

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

[jira] [Commented] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1

2017-09-21 Thread JIRA


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

Jiri Daněk commented on QPIDJMS-325:


I've done brief search on GitHub and from the code there, having looked at 
about 8 pages of results, it appears usual usage pattern is

{code}
byte[] bytes = new byte[(int) bytesMessage.getBodyLength()];
bytesMessage.readBytes(bytes);
{code}

and in one case I saw

{code}
// 
https://github.com/jianbinjiang/activemq/blob/0209d1d2b149988f933b7b50ae61322c7c84dc28/src/main/java/com/hk/demo/activemq/consumer/ConsumerService.java
while ((len = bm.readBytes(b)) != -1) {
System.out.println(new String(b, 0, len));
}
{code}

The return value would make a difference in the second case. When receiving 
empty array, it would either print empty line, or nothing, depending on return 
value.

If I could choose, I'd make the return value to be 0 on EOF for the first read 
and all subsequent ones for BytesMessage... Sadly, that is something the 
Javadoc does not allow, and I don't have preference between the ActiveMQ 
behavior and (qpid-jms + ActiveMQ Artemis) behavior.

https://github.com/search?utf8=%E2%9C%93=BytesMessage+readBytes+language%3AJava+path%3A%2Fsrc%2Fmain%2Fjava=Code=advsearch=Java=

I realize GitHub is not good corpus for this, because most of relevant JMS 
client code is probably not there.

> reading from empty buffer of a BytesMessage should return 0, not -1
> ---
>
> Key: QPIDJMS-325
> URL: https://issues.apache.org/jira/browse/QPIDJMS-325
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> Consider the following test. According to 
> http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
>  the #readBytes method should return 0 when it is first called, as the number 
> of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it 
> should return -1. What happens now is that the method returns -1 the first 
> time.
> See the commented lines to try the same thing with ActiveMQ JMS Client 
> library, and with StreamMessage instead of BytesMessage. The behavior there 
> should be the same.
> ActiveMQ passes the test with BytesMessage and fails it with StreamMessage. 
> Qpid JMS fails with BytesMessage and passes with StreamMessage.
> {code}
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.qpid.jms.JmsConnectionFactory;
> import org.junit.Test;
> import javax.jms.*;
> import static com.google.common.truth.Truth.assertThat;
> public class EmptyBufferInputTest {
> @Test
> public void testEmptyBufferInput() throws JMSException {
> //ConnectionFactory connectionFactory = new 
> ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
> JmsConnectionFactory connectionFactory = new 
> JmsConnectionFactory("amqp://127.0.0.1:5672");
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false, 
> Session.AUTO_ACKNOWLEDGE);
> final byte[] BYTE_LIST = {1, 2, 4};
> //StreamMessage message = session.createStreamMessage();
> BytesMessage message = session.createBytesMessage();
> message.clearBody();
> byte[] readList = new byte[BYTE_LIST.length - 1];
> byte[] emptyList = {};
> message.writeBytes(emptyList);
> message.reset();
> final int IS_EMPTY = 0;
> assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
> }
> }
> {code}



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

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

[jira] [Reopened] (QPID-7772) Add statistics panel to view tabs within the Web Management Console

2017-09-21 Thread Lorenz Quack (JIRA)


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

Lorenz Quack reopened QPID-7772:


> Add statistics panel to view tabs within the Web Management Console
> ---
>
> Key: QPID-7772
> URL: https://issues.apache.org/jira/browse/QPID-7772
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Configured Objects within the Broker's object model already carry many useful 
> statistics.  Only a fraction of these are currently presented on the WMC and 
> this means that most users are aware of their existence. 
>  Each view tab should have an expandable panel that provides the available 
> statistics. The contents of the statistics panel should be entirely driven 
> from the object's metadata.  If the statistics panel is opened, the 
> statistics should be updated automatically to the same refresh cycle of the 
> request of the UI.



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

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

[jira] [Reopened] (QPID-7606) Generalise Queue|Exchange#alternateExchange as alternateBinding

2017-09-21 Thread Lorenz Quack (JIRA)


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

Lorenz Quack reopened QPID-7606:


I just noticed that the UI for choosing the alternative binding behaves a 
little bit weird.
The dropdown list has the aritificial entries {{-- Queues \-\-}} and {{\-\- 
Exchanges --}}. When a user selects one of them the UI does not report any 
warning or error. Instead it silently disables the alternative binding feature.

Alex suggested to potentially use 
[SelectOptGroups|https://gibbok.github.io/dijit-select-optgroup/]. That seems 
like a reasonable suggestion to me.

Maybe we could also add an artificial entry to explicitly disable the feature. 
Currently one has to ignore the drop down list and manually delete the content 
of the field.

> Generalise Queue|Exchange#alternateExchange as alternateBinding
> ---
>
> Key: QPID-7606
> URL: https://issues.apache.org/jira/browse/QPID-7606
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: alternate-binding.tar.gz
>
>
> Queues and exchanges should have something akin to an "alternate binding" 
> rather than an alternate exchange.  From this we can simplify the DLQ 
> implementation to remove the need for DLEs (or at worst have a single DLE).
> Alternate Bindings could be modelled as {{\{destination, arguments\}}}.  A 
> supported argument might be {{replacementRoutingKey}} which if set could 
> direct the routing through the alternate(s) (This is separate - see 
> QPID-7771).
> This work includes:
> * changes to the model object themselves and the routing algorithms
> * update the configuration upgrades to remap Exchange#alternativeExchange and 
> Queue#alternativeExchange into the new model.
> * the facility for automatic creation of a DLQ should be retained but it can 
> be simplified to not create an DLE exchange.
> * On upgrade, existing users' DLQ/DLEs must be retained as is, that is, there 
> is no requirement to eliminate existing DLEs.  This is because we have no way 
> to predict if the users made additional changes to these objects.
> * update UI



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

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

[jira] [Commented] (QPID-7904) [Java Broker] ensure ACLs work with AMQP 1.0

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


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

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

Commit 366b4d6b4a070d5b2d0cb2adf92696ac6a7e2952 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=366b4d6 ]

QPID-7904: [AMQP 1.0] [ACL] Ensure that transaction is marked as rolled back 
only if ACL denies publish


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



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

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

[jira] [Commented] (QPID-7919) [Java Broker][AMQP1.0][ACL] ACL constraints for temporary queues are not applied on AMQP 1.0 path

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


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

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

Commit b39d491357f48856f39e59a59be036195d015260 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=b39d491 ]

QPID-7919: [System Tests] Exclude ACL test for temporary queue creation from 
messaging for AMQP 1.0


> [Java Broker][AMQP1.0][ACL] ACL constraints for temporary queues are not 
> applied on AMQP 1.0 path
> -
>
> Key: QPID-7919
> URL: https://issues.apache.org/jira/browse/QPID-7919
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>
> With AMQP 1.0  temporary queues and temporary topics are created using system 
> account. As result ACL restrictions for temporary queue are not applied to 
> the caller principals, even when there are rules explicitly denying temporary 
> queue creation.



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

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

[jira] [Updated] (QPID-7919) [Java Broker][AMQP1.0][ACL] ACL constraints for temporary queues are not applied on AMQP 1.0 path

2017-09-21 Thread Alex Rudyy (JIRA)


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

Alex Rudyy updated QPID-7919:
-
Description: With AMQP 1.0  temporary queues and temporary topics are 
created using system account. As result ACL restrictions for temporary queue 
are not applied to the caller principals, even when there are rules explicitly 
denying temporary queue creation.  (was: With AMQP 1.0  temporary queues and 
temporary topics are created using system account. As result ACL restrictions 
for temporary queue are not applied to the caller principals, even when there 
are rules explicitly denying temporary queue creation for the caller principal.)

> [Java Broker][AMQP1.0][ACL] ACL constraints for temporary queues are not 
> applied on AMQP 1.0 path
> -
>
> Key: QPID-7919
> URL: https://issues.apache.org/jira/browse/QPID-7919
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>
> With AMQP 1.0  temporary queues and temporary topics are created using system 
> account. As result ACL restrictions for temporary queue are not applied to 
> the caller principals, even when there are rules explicitly denying temporary 
> queue creation.



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

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

[jira] [Reopened] (QPID-7773) REST API queries that identify a single object by its full path should return a object rather than a list.

2017-09-21 Thread Lorenz Quack (JIRA)


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

Lorenz Quack reopened QPID-7773:


> REST API queries that identify a single object by its full path should return 
> a object rather than a list.
> --
>
> Key: QPID-7773
> URL: https://issues.apache.org/jira/browse/QPID-7773
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Currently if I GET for, say a queue, by the object's full path 
> {{/queue/vhn/vh/myqueue}}, I get a JSON list contain the queue object, rather 
> than an object directly.  This makes the REST API's abstraction inconsistent: 
> I PUT a queue as an object, but GET gives me a list.
> The REST API should be returning a list only in those situations where a 
> multiple object response could arise e.g. {{/queue/vhn/vh}}, wildcards or 
> filtering.



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

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

[jira] [Created] (QPID-7919) [Java Broker][AMQP1.0][ACL] ACL constraints for temporary queues are not applied on AMQP 1.0 path

2017-09-21 Thread Alex Rudyy (JIRA)

Alex Rudyy created QPID-7919:


 Summary: [Java Broker][AMQP1.0][ACL] ACL constraints for temporary 
queues are not applied on AMQP 1.0 path
 Key: QPID-7919
 URL: https://issues.apache.org/jira/browse/QPID-7919
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Affects Versions: qpid-java-broker-7.0.0
Reporter: Alex Rudyy


With AMQP 1.0  temporary queues and temporary topics are created using system 
account. As result ACL restrictions for temporary queue are not applied to the 
caller principals, even when there are rules explicitly denying temporary queue 
creation for the caller principal.



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

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

[jira] [Commented] (QPID-7787) [Java Broker] In AMQP 1.0 allow the SASL outcome to carry additional information

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


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

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

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

QPID-7787: [Java Broker] On AMQP 1.0 flip the default behaviour to send the 
additional SASL data in the outcome instead of in an additional challenge


> [Java Broker] In AMQP 1.0 allow the SASL outcome to carry additional 
> information
> 
>
> Key: QPID-7787
> URL: https://issues.apache.org/jira/browse/QPID-7787
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> 0001-QPID-7787-Java-Broker-Use-the-AMQP-SaslOutcome-s-add.patch, 
> QPID_7787___allow_the_SASL_outcome_to_carry_additional_information.patch
>
>
> Currently, when a SASL negotiation is successful but has additional data this 
> data is sent as a challenge requiring another round-trip.
> AMQP 1.0 allows to send additional data in the SASL Outcome frame avoiding 
> the additional round trip. We should use this in 
> {{AMQPConnection_1_0Impl#processSaslResponse}}.



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

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

42 matches

Mail list logo