date:20170811

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

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


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

ASF GitHub Bot commented on PROTON-1532:


Github user astitcher commented on the issue:

https://github.com/apache/qpid-proton/pull/116
  
@alanconway you may want to take a look at this.


> 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
>
> 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-08-11 Thread astitcher

Github user astitcher commented on the issue:

https://github.com/apache/qpid-proton/pull/116
  
@alanconway you may want to take a look at this.


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

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

[jira] [Commented] (DISPATCH-807) Message handling requires flow control to limit memory consumption

2017-08-11 Thread Chuck Rolke (JIRA)


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

Chuck Rolke commented on DISPATCH-807:
--

Here is an illustration of the issue.
{noformat}

 +--+
 |   Sender |
 +--+---+
|
 +--|--+
 |Router|  |
 |   +--|---+  |
 |   |Proton In v   |  |
 |   | #|  |
 |   |incoming-window-->   |  |  |  |  #  Q1|  |
 |   | #|  |
 |   |queue of frames   |   |  |
 |   +--|---+  |
 |  |  |
 |   ++|
 |   |pn_link_recv||
 |   ++|
 |  |  |
 |   +-+--+-+  |
 |   |Message Handling |qd_message_receive| |  |
 |   | ++-+ |  |
 |   |  v   |  |
 |   | #|  |
 |   |message-bytes--> |  |  |  |  #  Q2|  |
 |   | #|  |
 |   |queue of dispatch |   |  |
 |   |buffers   |   |  |
 |   | +---+|  |
 |   | |qd_message_send||  |
 |   +-++--++  |
 |  |  |
 |   ++|
 |   |pn_link_send||
 |   ++|
 |  |  |
 |   +--|---+  |
 |   |Proton Outv   |  |
 |   | #|  |
 |   |outgoing-bytes-->|  |  |  |  #  Q3|  |
 |   | #|  |
 |   |  |   |  |
 |   +--|---+  |
 +--|--+
v
 +--+
 |   Receiver   |
 +--+
{noformat}

Here a fast Sender is sending a large message to the router and on to a slow 
Receiver. The message bytes pass through three queues.

*Q1* is the Proton session frame queue. This queue is *not* subject to overflow 
and unlimited memory consumption. Instead this queue is protected by AMQP 
session incoming-window that limits the number of frames that the Sender is 
allowed to send. If function _pn_link_receive_ is not called then the session 
incoming-window will close and the Sender will stop sending.

*Q2* is internal to a dispatch message where bytes are pulled the Proton layer 
and stored in dispatch buffers. Recent changes for streaming limit the size of 
this buffer by pulling message bytes out of the head of this queue while it is 
being filled. In general this queue is not a problem because the when the 
router gets around to sending the message all of the bytes are pulled out of Q2 
and sent.

*Q3* is an outgoing byte queue in Proton. This queue may grow unbounded.

h3. Limiting queue size

Proposal 1 is to add limits to how large queues Q2 and Q3 may grow.
* When Q2 is above its threshold then_qd_message_receive_ stops calling 
_pn_link_recv_ and message data is backed up into Q1.
* When Q3 is above its threshold then _qd_message_send_ stops calling 
_pn_link_send_ and message data is backed up into Q2.

Proposal 2 is to have no limit applied to Q2 and just have a limit for Q3.
* When Q3 is above its threshold then _qd_message_receive_ stops calling 
_pn_link_recv_.

h3. Proposal complexity

Both proposals have to deal with multiple outbound links as message targets. 
That is, the same message

[jira] [Created] (DISPATCH-807) Message handling requires flow control to limit memory consumption

2017-08-11 Thread Chuck Rolke (JIRA)

Chuck Rolke created DISPATCH-807:


 Summary: Message handling requires flow control to limit memory 
consumption
 Key: DISPATCH-807
 URL: https://issues.apache.org/jira/browse/DISPATCH-807
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Router Node
Affects Versions: 0.8.0
Reporter: Chuck Rolke
Assignee: Chuck Rolke


Large messages coming from fast senders and going to slow receivers may consume 
large amounts of memory.



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

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

[jira] [Resolved] (PROTON-1535) Can't set hostname on SASL-INIT through sasl plugin interface

2017-08-11 Thread Gordon Sim (JIRA)


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

Gordon Sim resolved PROTON-1535.

Resolution: Fixed

> Can't set hostname on SASL-INIT through sasl plugin interface
> -
>
> Key: PROTON-1535
> URL: https://issues.apache.org/jira/browse/PROTON-1535
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Gordon Sim
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> There is no way to set the hostname in the SASL-INIT frame that is sent out 
> by proton. This is needed if the server will use that hostname to determine 
> the realm/domain against which to authenticate in a multi-tenant environment.



--
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-1535) Can't set hostname on SASL-INIT through sasl plugin interface

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


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

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

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

PROTON-1535: allow plugins to set the hostname sent out in sasl-int frames


> Can't set hostname on SASL-INIT through sasl plugin interface
> -
>
> Key: PROTON-1535
> URL: https://issues.apache.org/jira/browse/PROTON-1535
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Gordon Sim
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> There is no way to set the hostname in the SASL-INIT frame that is sent out 
> by proton. This is needed if the server will use that hostname to determine 
> the realm/domain against which to authenticate in a multi-tenant environment.



--
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-1535) Can't set hostname on SASL-INIT through sasl plugin interface

2017-08-11 Thread Andrew Stitcher (JIRA)


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

Andrew Stitcher commented on PROTON-1535:
-

Yeah. By 'in general' I meant should proton do this always, or rather if 
proton-c can't do this are there some applications that it won't work for?

But in any case that should be a new and separate JIRA.

> Can't set hostname on SASL-INIT through sasl plugin interface
> -
>
> Key: PROTON-1535
> URL: https://issues.apache.org/jira/browse/PROTON-1535
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Gordon Sim
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> There is no way to set the hostname in the SASL-INIT frame that is sent out 
> by proton. This is needed if the server will use that hostname to determine 
> the realm/domain against which to authenticate in a multi-tenant environment.



--
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-1535) Can't set hostname on SASL-INIT

2017-08-11 Thread Gordon Sim (JIRA)


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

Gordon Sim commented on PROTON-1535:


Yes, it is compliant. By 'doing this in general' do you mean setting it by 
default? If so, possibly, but then you would need a more public api (to disable 
or alter the default where needed). Thats true for the second question also I 
think, i.e. you might indeed want a public api that lets you read what has been 
sent from outside the sasl plugin (within the plugin there is already a method 
to read it). I could clarify in the title for this bug that it covers the new 
sasl plugin interface only? (Then the decision to have a public api for general 
use if needed can be considered separately).

> Can't set hostname on SASL-INIT
> ---
>
> Key: PROTON-1535
> URL: https://issues.apache.org/jira/browse/PROTON-1535
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Gordon Sim
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> There is no way to set the hostname in the SASL-INIT frame that is sent out 
> by proton. This is needed if the server will use that hostname to determine 
> the realm/domain against which to authenticate in a multi-tenant environment.



--
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-1535) Can't set hostname on SASL-INIT through sasl plugin interface

2017-08-11 Thread Gordon Sim (JIRA)


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

Gordon Sim updated PROTON-1535:
---
Summary: Can't set hostname on SASL-INIT through sasl plugin interface  
(was: Can't set hostname on SASL-INIT)

> Can't set hostname on SASL-INIT through sasl plugin interface
> -
>
> Key: PROTON-1535
> URL: https://issues.apache.org/jira/browse/PROTON-1535
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Gordon Sim
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> There is no way to set the hostname in the SASL-INIT frame that is sent out 
> by proton. This is needed if the server will use that hostname to determine 
> the realm/domain against which to authenticate in a multi-tenant environment.



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

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

Re: Review Request 61596: allow hostname to be set for sasl-init

2017-08-11 Thread Andrew Stitcher


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/61596/#review182734
---


Ship it!




Ship It!

- Andrew Stitcher


On Aug. 11, 2017, 5:24 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61596/
> ---
> 
> (Updated Aug. 11, 2017, 5:24 p.m.)
> 
> 
> Review request for qpid and Andrew Stitcher.
> 
> 
> Bugs: PROTON-1535
> https://issues.apache.org/jira/browse/PROTON-1535
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> allow hostname to be set for sasl-init
> 
> 
> Diffs
> -
> 
>   proton-c/include/proton/sasl-plugin.h cbc6684 
>   proton-c/src/sasl/sasl-internal.h fc141b4 
>   proton-c/src/sasl/sasl.c a39e602 
> 
> 
> Diff: https://reviews.apache.org/r/61596/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

Re: Review Request 61596: allow hostname to be set for sasl-init

2017-08-11 Thread Gordon Sim



> On Aug. 11, 2017, 5:46 p.m., Andrew Stitcher wrote:
> > This looks fine.
> > 
> > Can you just confirm that adding this extra field to the frame is still 
> > amqp 1.0 protocol compliant (I dont have time to check that today).
> 
> Gordon Sim wrote:
> From spec:
> 
>  provides="sasl-frame">
> 
> 
> 
> 
> 
> 
> "This field can be used by AMQP proxies to determine the correct back-end 
> service to connect the
> client to, and to determine the domain to validate the client’s 
> credentials against."

I've also verified that it is written as a string as required. (Initially I had 
it coming as a symbol which qpidd warned about).


- Gordon


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/61596/#review182725
---


On Aug. 11, 2017, 5:24 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61596/
> ---
> 
> (Updated Aug. 11, 2017, 5:24 p.m.)
> 
> 
> Review request for qpid and Andrew Stitcher.
> 
> 
> Bugs: PROTON-1535
> https://issues.apache.org/jira/browse/PROTON-1535
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> allow hostname to be set for sasl-init
> 
> 
> Diffs
> -
> 
>   proton-c/include/proton/sasl-plugin.h cbc6684 
>   proton-c/src/sasl/sasl-internal.h fc141b4 
>   proton-c/src/sasl/sasl.c a39e602 
> 
> 
> Diff: https://reviews.apache.org/r/61596/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

Re: Review Request 61596: allow hostname to be set for sasl-init

2017-08-11 Thread Gordon Sim



> On Aug. 11, 2017, 5:46 p.m., Andrew Stitcher wrote:
> > This looks fine.
> > 
> > Can you just confirm that adding this extra field to the frame is still 
> > amqp 1.0 protocol compliant (I dont have time to check that today).

>From spec:








"This field can be used by AMQP proxies to determine the correct back-end 
service to connect the
client to, and to determine the domain to validate the client’s credentials 
against."


- Gordon


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/61596/#review182725
---


On Aug. 11, 2017, 5:24 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61596/
> ---
> 
> (Updated Aug. 11, 2017, 5:24 p.m.)
> 
> 
> Review request for qpid and Andrew Stitcher.
> 
> 
> Bugs: PROTON-1535
> https://issues.apache.org/jira/browse/PROTON-1535
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> allow hostname to be set for sasl-init
> 
> 
> Diffs
> -
> 
>   proton-c/include/proton/sasl-plugin.h cbc6684 
>   proton-c/src/sasl/sasl-internal.h fc141b4 
>   proton-c/src/sasl/sasl.c a39e602 
> 
> 
> Diff: https://reviews.apache.org/r/61596/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

[jira] [Commented] (PROTON-1538) Epoll proactor unguarded memory access

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


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

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

Commit 79309b030476f4957f7d8f360d2224ee0850e006 in qpid-proton's branch 
refs/heads/master from Clifford Jansen
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=79309b0 ]

PROTON-1538: epoll proactor - prevent out of order rearming of connection file 
descriptor


> Epoll proactor unguarded memory access
> --
>
> Key: PROTON-1538
> URL: https://issues.apache.org/jira/browse/PROTON-1538
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
> Fix For: proton-j-0.18.0
>
>
> ThreadSanitizer singled out the epoll_event for network sockets to be a risk 
> of  out of order access by multiple threads.
> On inspection it is possible that two threads could try rearming the socket 
> out of order, allowing the wrong events of interest to be registered.
> Reusing the existing connection context mutex would be costly for
> guarding this since the system call is frequent and relatively long
> compared to other acquisitions of the mutex.  Adding a new mutex that
> guards this operation should fix things with negligible performance
> cost.



--
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-1536) There is no way using the C++ binding connection_driver API to either send heartbeat frames, or recognise heartbeat timeouts

2017-08-11 Thread Andrew Stitcher (JIRA)


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

Andrew Stitcher updated PROTON-1536:

Summary: There is no way using the C++ binding connection_driver API to 
either send heartbeat frames, or recognise heartbeat timeouts  (was: THere is 
no way using the C++ binding connection_driver API to either send heartbeat 
frames, or recognise heartbeat timeouts)

> There is no way using the C++ binding connection_driver API to either send 
> heartbeat frames, or recognise heartbeat timeouts
> 
>
> Key: PROTON-1536
> URL: https://issues.apache.org/jira/browse/PROTON-1536
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> The C++ connection_driver API does not expose any way to get to the 
> pn_transport_tick() function to tell the engine what time it is. So the 
> engine has no way to know whether it needs to send empty heartbeat frames, 
> and equally it can't tell when a heartbeat timeout has occurred due to lack 
> of traffic from the peer.



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

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

[jira] [Resolved] (PROTON-1536) There is no way using the C++ binding connection_driver API to either send heartbeat frames, or recognise heartbeat timeouts

2017-08-11 Thread Andrew Stitcher (JIRA)


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

Andrew Stitcher resolved PROTON-1536.
-
   Resolution: Fixed
Fix Version/s: proton-c-0.18.0

> There is no way using the C++ binding connection_driver API to either send 
> heartbeat frames, or recognise heartbeat timeouts
> 
>
> Key: PROTON-1536
> URL: https://issues.apache.org/jira/browse/PROTON-1536
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> The C++ connection_driver API does not expose any way to get to the 
> pn_transport_tick() function to tell the engine what time it is. So the 
> engine has no way to know whether it needs to send empty heartbeat frames, 
> and equally it can't tell when a heartbeat timeout has occurred due to lack 
> of traffic from the peer.



--
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-1536) THere is no way using the C++ binding connection_driver API to either send heartbeat frames, or recognise heartbeat timeouts

2017-08-11 Thread Andrew Stitcher (JIRA)


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

Andrew Stitcher commented on PROTON-1536:
-

This code change has very rudimentary tests. Just one positive and one negative 
test.

Specifically it doesn't test heartbeat frame generation. Although it should be 
straightforward to force generation of heartbeat frames - I think it might be 
difficult to recognise they have/have not arrived.

> THere is no way using the C++ binding connection_driver API to either send 
> heartbeat frames, or recognise heartbeat timeouts
> 
>
> Key: PROTON-1536
> URL: https://issues.apache.org/jira/browse/PROTON-1536
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> The C++ connection_driver API does not expose any way to get to the 
> pn_transport_tick() function to tell the engine what time it is. So the 
> engine has no way to know whether it needs to send empty heartbeat frames, 
> and equally it can't tell when a heartbeat timeout has occurred due to lack 
> of traffic from the peer.



--
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-1536) THere is no way using the C++ binding connection_driver API to either send heartbeat frames, or recognise heartbeat timeouts

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


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

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

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

PROTON-1536: [C++ Binding] Add tick() member function to connection_driver API


> THere is no way using the C++ binding connection_driver API to either send 
> heartbeat frames, or recognise heartbeat timeouts
> 
>
> Key: PROTON-1536
> URL: https://issues.apache.org/jira/browse/PROTON-1536
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>
> The C++ connection_driver API does not expose any way to get to the 
> pn_transport_tick() function to tell the engine what time it is. So the 
> engine has no way to know whether it needs to send empty heartbeat frames, 
> and equally it can't tell when a heartbeat timeout has occurred due to lack 
> of traffic from the peer.



--
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-1535) Can't set hostname on SASL-INIT

2017-08-11 Thread Andrew Stitcher (JIRA)


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

Andrew Stitcher commented on PROTON-1535:
-

The fix looks fine (assuming the frame that is generated is still protocol 
compliant).

A question does arise though - should we be doing this in general?

A second question is how are you getting to the local fqdn at the other end 
seeing as proton doesn't handle it (or does it?).

> Can't set hostname on SASL-INIT
> ---
>
> Key: PROTON-1535
> URL: https://issues.apache.org/jira/browse/PROTON-1535
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Gordon Sim
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> There is no way to set the hostname in the SASL-INIT frame that is sent out 
> by proton. This is needed if the server will use that hostname to determine 
> the realm/domain against which to authenticate in a multi-tenant environment.



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

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

Re: Review Request 61596: allow hostname to be set for sasl-init

2017-08-11 Thread Andrew Stitcher


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/61596/#review182725
---



This looks fine.

Can you just confirm that adding this extra field to the frame is still amqp 
1.0 protocol compliant (I dont have time to check that today).

- Andrew Stitcher


On Aug. 11, 2017, 5:24 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61596/
> ---
> 
> (Updated Aug. 11, 2017, 5:24 p.m.)
> 
> 
> Review request for qpid and Andrew Stitcher.
> 
> 
> Bugs: PROTON-1535
> https://issues.apache.org/jira/browse/PROTON-1535
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> allow hostname to be set for sasl-init
> 
> 
> Diffs
> -
> 
>   proton-c/include/proton/sasl-plugin.h cbc6684 
>   proton-c/src/sasl/sasl-internal.h fc141b4 
>   proton-c/src/sasl/sasl.c a39e602 
> 
> 
> Diff: https://reviews.apache.org/r/61596/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

[jira] [Commented] (PROTON-1535) Can't set hostname on SASL-INIT

2017-08-11 Thread Gordon Sim (JIRA)


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

Gordon Sim commented on PROTON-1535:


Possible fix: https://reviews.apache.org/r/61596/

> Can't set hostname on SASL-INIT
> ---
>
> Key: PROTON-1535
> URL: https://issues.apache.org/jira/browse/PROTON-1535
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Gordon Sim
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> There is no way to set the hostname in the SASL-INIT frame that is sent out 
> by proton. This is needed if the server will use that hostname to determine 
> the realm/domain against which to authenticate in a multi-tenant environment.



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

Review Request 61596: allow hostname to be set for sasl-init

2017-08-11 Thread Gordon Sim


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/61596/
---

Review request for qpid and Andrew Stitcher.


Bugs: PROTON-1535
https://issues.apache.org/jira/browse/PROTON-1535


Repository: qpid-proton-git


Description
---

allow hostname to be set for sasl-init


Diffs
-

  proton-c/include/proton/sasl-plugin.h cbc6684 
  proton-c/src/sasl/sasl-internal.h fc141b4 
  proton-c/src/sasl/sasl.c a39e602 


Diff: https://reviews.apache.org/r/61596/diff/1/


Testing
---


Thanks,

Gordon Sim

[jira] [Created] (PROTON-1538) Epoll proactor unguarded memory access

2017-08-11 Thread Cliff Jansen (JIRA)

Cliff Jansen created PROTON-1538:


 Summary: Epoll proactor unguarded memory access
 Key: PROTON-1538
 URL: https://issues.apache.org/jira/browse/PROTON-1538
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: proton-c-0.18.0
Reporter: Cliff Jansen
Assignee: Cliff Jansen
 Fix For: proton-j-0.18.0


ThreadSanitizer singled out the epoll_event for network sockets to be a risk of 
 out of order access by multiple threads.

On inspection it is possible that two threads could try rearming the socket out 
of order, allowing the wrong events of interest to be registered.

Reusing the existing connection context mutex would be costly for
guarding this since the system call is frequent and relatively long
compared to other acquisitions of the mutex.  Adding a new mutex that
guards this operation should fix things with negligible performance
cost.



--
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] (DISPATCH-805) System test system_tests_sasl_plain fails in systems with TLSv1.2

2017-08-11 Thread Ganesh Murthy (JIRA)


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

Ganesh Murthy resolved DISPATCH-805.

Resolution: Fixed

> System test system_tests_sasl_plain fails in systems with TLSv1.2
> -
>
> Key: DISPATCH-805
> URL: https://issues.apache.org/jira/browse/DISPATCH-805
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine, Tests
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> A couple of tests in system_tests_sasl_plain.py tests for hard coded string 
> *TLSv1/SSLv3* as the TLS version. The version of TLS can vary. It could be 
> *TLSv1.2*
> Instead of asserting
> {noformat}
> self.assertEqual(u'TLSv1/SSLv3', results[0][10])
> {noformat}
> we should do
> {noformat}
> self.assertTrue(u'TLSv1' in results[0][10])
> {noformat}
> Following is the trace from the failing test
> {noformat}
> 24: ==
> 24: FAIL: test_inter_router_plain_over_ssl_exists 
> (system_tests_sasl_plain.RouterTestVerifyHostNameNo)
> 24: --
> 24: Traceback (most recent call last):
> 24:   File "/foo/qpid-dispatch/tests/system_tests_sasl_plain.py", line 525, 
> in test_inter_router_plain_over_ssl_exists
> 24: self.common_asserts(results)
> 24:   File "/foo/qpid-dispatch/tests/system_tests_sasl_plain.py", line 503, 
> in common_asserts
> 24: self.assertEqual(u'TLSv1/SSLv3', results[N][10])
> 24: AssertionError: u'TLSv1/SSLv3' != u'TLSv1.2'
> 24: - TLSv1/SSLv3
> 24: + TLSv1.2
> 24:
> 24:
> 24: ==
> 24: FAIL: test_zzz_delete_create_ssl_profile 
> (system_tests_sasl_plain.RouterTestVerifyHostNameNo)
> 24: --
> 24: Traceback (most recent call last):
> 24:   File "/foo/qpid-dispatch/tests/system_tests_sasl_plain.py", line 564, 
> in test_zzz_delete_create_ssl_profile
> 24: self.common_asserts(results)
> 24:   File "/foo/qpid-dispatch/tests/system_tests_sasl_plain.py", line 503, 
> in common_asserts
> 24: self.assertEqual(u'TLSv1/SSLv3', results[N][10])
> 24: AssertionError: u'TLSv1/SSLv3' != u'TLSv1.2'
> 24: - TLSv1/SSLv3
> 24: + TLSv1.2
> 24:
> 24:
> 24: --
> 24: Ran 8 tests in 15.760s
> 24:
> 24: FAILED (failures=3)
> {noformat}



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

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

[jira] [Commented] (DISPATCH-805) System test system_tests_sasl_plain fails in systems with TLSv1.2

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


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

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

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

DISPATCH-805 - Fixed the assert on system_tests_sasl_plain.py in order to not 
hard code TLS version


> System test system_tests_sasl_plain fails in systems with TLSv1.2
> -
>
> Key: DISPATCH-805
> URL: https://issues.apache.org/jira/browse/DISPATCH-805
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine, Tests
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> A couple of tests in system_tests_sasl_plain.py tests for hard coded string 
> *TLSv1/SSLv3* as the TLS version. The version of TLS can vary. It could be 
> *TLSv1.2*
> Instead of asserting
> {noformat}
> self.assertEqual(u'TLSv1/SSLv3', results[0][10])
> {noformat}
> we should do
> {noformat}
> self.assertTrue(u'TLSv1' in results[0][10])
> {noformat}
> Following is the trace from the failing test
> {noformat}
> 24: ==
> 24: FAIL: test_inter_router_plain_over_ssl_exists 
> (system_tests_sasl_plain.RouterTestVerifyHostNameNo)
> 24: --
> 24: Traceback (most recent call last):
> 24:   File "/foo/qpid-dispatch/tests/system_tests_sasl_plain.py", line 525, 
> in test_inter_router_plain_over_ssl_exists
> 24: self.common_asserts(results)
> 24:   File "/foo/qpid-dispatch/tests/system_tests_sasl_plain.py", line 503, 
> in common_asserts
> 24: self.assertEqual(u'TLSv1/SSLv3', results[N][10])
> 24: AssertionError: u'TLSv1/SSLv3' != u'TLSv1.2'
> 24: - TLSv1/SSLv3
> 24: + TLSv1.2
> 24:
> 24:
> 24: ==
> 24: FAIL: test_zzz_delete_create_ssl_profile 
> (system_tests_sasl_plain.RouterTestVerifyHostNameNo)
> 24: --
> 24: Traceback (most recent call last):
> 24:   File "/foo/qpid-dispatch/tests/system_tests_sasl_plain.py", line 564, 
> in test_zzz_delete_create_ssl_profile
> 24: self.common_asserts(results)
> 24:   File "/foo/qpid-dispatch/tests/system_tests_sasl_plain.py", line 503, 
> in common_asserts
> 24: self.assertEqual(u'TLSv1/SSLv3', results[N][10])
> 24: AssertionError: u'TLSv1/SSLv3' != u'TLSv1.2'
> 24: - TLSv1/SSLv3
> 24: + TLSv1.2
> 24:
> 24:
> 24: --
> 24: Ran 8 tests in 15.760s
> 24:
> 24: FAILED (failures=3)
> {noformat}



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

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

[jira] [Updated] (DISPATCH-804) connectors ignore addr

2017-08-11 Thread Gordon Sim (JIRA)


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

Gordon Sim updated DISPATCH-804:

Priority: Major  (was: Blocker)

Downgrading. Blocker was a bit of an extreme reaction, hadn't realised it was a 
deprecated field anyway. Should still fix (or else entirely remove support for 
addr though)

> connectors ignore addr
> --
>
> Key: DISPATCH-804
> URL: https://issues.apache.org/jira/browse/DISPATCH-804
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> The addr field of connector appears to be entirely ignored, with 127.0.0.1 
> used instead. E.g. with the following config:
> {noformat}
> router {
> mode: standalone
> routerId: myrouter
> }
> listener {
> addr: 0.0.0.0
> port: amqp
> authenticatePeer: no
> }
> connector {
> name: myconnector
> addr: google.com
> port: 5673
> }
> {noformat}
> you see 
> {noformat}
> 2017-08-11 16:27:13.184 +0100 AGENT (warning) routerId is deprecated, use id 
> instead
> 2017-08-11 16:27:13.555 +0100 SERVER (warning) HTTP support is not available
> 2017-08-11 16:27:13.563 +0100 SERVER (info) Container Name: myrouter
> 2017-08-11 16:27:13.651 +0100 ROUTER (info) Router started in Standalone mode
> 2017-08-11 16:27:13.679 +0100 ROUTER_CORE (info) Allow Unsettled Multicast: no
> 2017-08-11 16:27:13.1033 +0100 ROUTER_CORE (info) Router Core thread running. 
> 0/myrouter
> 2017-08-11 16:27:13.1049 +0100 ROUTER_CORE (info) In-process subscription 
> M/$management
> 2017-08-11 16:27:13.7044 +0100 AGENT (info) Activating management agent on 
> $_management_internal
> 2017-08-11 16:27:13.7099 +0100 ROUTER_CORE (info) In-process subscription 
> L/$management
> 2017-08-11 16:27:13.7122 +0100 ROUTER_CORE (info) In-process subscription 
> L/$_management_internal
> 2017-08-11 16:27:13.7410 +0100 CONN_MGR (info) Configured Listener: 
> 0.0.0.0:amqp proto=any, role=normal
> 2017-08-11 16:27:13.8007 +0100 CONN_MGR (info) Configured Connector: 
> 127.0.0.1:5673 proto=any, role=normal<- NOTE: Wrong hostname!!
> 2017-08-11 16:27:13.8460 +0100 POLICY (info) Policy configured 
> maxConnections: 65535, policyDir: '', access rules enabled: 'false'
> 2017-08-11 16:27:13.9149 +0100 POLICY (info) Policy fallback defaultVhost is 
> defined: '$default'
> 2017-08-11 16:27:13.9175 +0100 SERVER (notice) Operational, 4 Threads Running 
> (process ID 3236)
> 2017-08-11 16:27:13.9286 +0100 SERVER (notice) Listening on 0.0.0.0:amqp
> {noformat}
> And indeed it connects to a broker on the local host.



--
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-7888) [Java Client] [Documentation] Correct typo in end to end encryption connection url examples

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


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

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

Commit 56bacf627665471531aea6e88f7d80bbbf43cfb2 in qpid-jms-amqp-0-x's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=56bacf6 ]

QPID-7888: [Java Client] [Documentation] Correct typo in connection urls used 
in end to end encryption example.


> [Java Client] [Documentation] Correct typo in end to end encryption 
> connection url examples
> ---
>
> Key: QPID-7888
> URL: https://issues.apache.org/jira/browse/QPID-7888
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client, Java Documentation
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> As highlighted by this thread:
> https://stackoverflow.com/questions/45583101/encrypted-messages-using-apache-qpid
> there is a typo in the connection urls used in the example.



--
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-7888) [Java Client] [Documentation] Correct typo in end to end encryption connection url examples

2017-08-11 Thread Keith Wall (JIRA)

Keith Wall created QPID-7888:


 Summary: [Java Client] [Documentation] Correct typo in end to end 
encryption connection url examples
 Key: QPID-7888
 URL: https://issues.apache.org/jira/browse/QPID-7888
 Project: Qpid
  Issue Type: Bug
  Components: Java Client, Java Documentation
Reporter: Keith Wall
 Fix For: qpid-java-client-0-x-6.3.0


As highlighted by this thread:

https://stackoverflow.com/questions/45583101/encrypted-messages-using-apache-qpid

there is a typo in the connection urls used in the example.



--
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-7888) [Java Client] [Documentation] Correct typo in end to end encryption connection url examples

2017-08-11 Thread Keith Wall (JIRA)


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

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

> [Java Client] [Documentation] Correct typo in end to end encryption 
> connection url examples
> ---
>
> Key: QPID-7888
> URL: https://issues.apache.org/jira/browse/QPID-7888
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client, Java Documentation
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> As highlighted by this thread:
> https://stackoverflow.com/questions/45583101/encrypted-messages-using-apache-qpid
> there is a typo in the connection urls used in the example.



--
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-806) Go thru every deprecated entity and make sure a warning is put out when a deprecated entity is used.

2017-08-11 Thread Ganesh Murthy (JIRA)

Ganesh Murthy created DISPATCH-806:
--

 Summary: Go thru every deprecated entity and make sure a warning 
is put out when a deprecated entity is used.
 Key: DISPATCH-806
 URL: https://issues.apache.org/jira/browse/DISPATCH-806
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Container
Affects Versions: 0.8.0
Reporter: Ganesh Murthy
Assignee: Ganesh Murthy
 Fix For: 1.0.0


If any deprecated entity or attribute is used, make sure a warning log message 
is put out by the router warning of such deprecated usage.



--
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-804) connectors ignore addr

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


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

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

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

DISPATCH-804: use addr if specified (though it is deprecated)


> connectors ignore addr
> --
>
> Key: DISPATCH-804
> URL: https://issues.apache.org/jira/browse/DISPATCH-804
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
>Priority: Blocker
> Fix For: 1.0.0
>
>
> The addr field of connector appears to be entirely ignored, with 127.0.0.1 
> used instead. E.g. with the following config:
> {noformat}
> router {
> mode: standalone
> routerId: myrouter
> }
> listener {
> addr: 0.0.0.0
> port: amqp
> authenticatePeer: no
> }
> connector {
> name: myconnector
> addr: google.com
> port: 5673
> }
> {noformat}
> you see 
> {noformat}
> 2017-08-11 16:27:13.184 +0100 AGENT (warning) routerId is deprecated, use id 
> instead
> 2017-08-11 16:27:13.555 +0100 SERVER (warning) HTTP support is not available
> 2017-08-11 16:27:13.563 +0100 SERVER (info) Container Name: myrouter
> 2017-08-11 16:27:13.651 +0100 ROUTER (info) Router started in Standalone mode
> 2017-08-11 16:27:13.679 +0100 ROUTER_CORE (info) Allow Unsettled Multicast: no
> 2017-08-11 16:27:13.1033 +0100 ROUTER_CORE (info) Router Core thread running. 
> 0/myrouter
> 2017-08-11 16:27:13.1049 +0100 ROUTER_CORE (info) In-process subscription 
> M/$management
> 2017-08-11 16:27:13.7044 +0100 AGENT (info) Activating management agent on 
> $_management_internal
> 2017-08-11 16:27:13.7099 +0100 ROUTER_CORE (info) In-process subscription 
> L/$management
> 2017-08-11 16:27:13.7122 +0100 ROUTER_CORE (info) In-process subscription 
> L/$_management_internal
> 2017-08-11 16:27:13.7410 +0100 CONN_MGR (info) Configured Listener: 
> 0.0.0.0:amqp proto=any, role=normal
> 2017-08-11 16:27:13.8007 +0100 CONN_MGR (info) Configured Connector: 
> 127.0.0.1:5673 proto=any, role=normal<- NOTE: Wrong hostname!!
> 2017-08-11 16:27:13.8460 +0100 POLICY (info) Policy configured 
> maxConnections: 65535, policyDir: '', access rules enabled: 'false'
> 2017-08-11 16:27:13.9149 +0100 POLICY (info) Policy fallback defaultVhost is 
> defined: '$default'
> 2017-08-11 16:27:13.9175 +0100 SERVER (notice) Operational, 4 Threads Running 
> (process ID 3236)
> 2017-08-11 16:27:13.9286 +0100 SERVER (notice) Listening on 0.0.0.0:amqp
> {noformat}
> And indeed it connects to a broker on the local host.



--
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] (DISPATCH-804) connectors ignore addr

2017-08-11 Thread Gordon Sim (JIRA)


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

Gordon Sim resolved DISPATCH-804.
-
Resolution: Fixed

> connectors ignore addr
> --
>
> Key: DISPATCH-804
> URL: https://issues.apache.org/jira/browse/DISPATCH-804
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
>Priority: Blocker
> Fix For: 1.0.0
>
>
> The addr field of connector appears to be entirely ignored, with 127.0.0.1 
> used instead. E.g. with the following config:
> {noformat}
> router {
> mode: standalone
> routerId: myrouter
> }
> listener {
> addr: 0.0.0.0
> port: amqp
> authenticatePeer: no
> }
> connector {
> name: myconnector
> addr: google.com
> port: 5673
> }
> {noformat}
> you see 
> {noformat}
> 2017-08-11 16:27:13.184 +0100 AGENT (warning) routerId is deprecated, use id 
> instead
> 2017-08-11 16:27:13.555 +0100 SERVER (warning) HTTP support is not available
> 2017-08-11 16:27:13.563 +0100 SERVER (info) Container Name: myrouter
> 2017-08-11 16:27:13.651 +0100 ROUTER (info) Router started in Standalone mode
> 2017-08-11 16:27:13.679 +0100 ROUTER_CORE (info) Allow Unsettled Multicast: no
> 2017-08-11 16:27:13.1033 +0100 ROUTER_CORE (info) Router Core thread running. 
> 0/myrouter
> 2017-08-11 16:27:13.1049 +0100 ROUTER_CORE (info) In-process subscription 
> M/$management
> 2017-08-11 16:27:13.7044 +0100 AGENT (info) Activating management agent on 
> $_management_internal
> 2017-08-11 16:27:13.7099 +0100 ROUTER_CORE (info) In-process subscription 
> L/$management
> 2017-08-11 16:27:13.7122 +0100 ROUTER_CORE (info) In-process subscription 
> L/$_management_internal
> 2017-08-11 16:27:13.7410 +0100 CONN_MGR (info) Configured Listener: 
> 0.0.0.0:amqp proto=any, role=normal
> 2017-08-11 16:27:13.8007 +0100 CONN_MGR (info) Configured Connector: 
> 127.0.0.1:5673 proto=any, role=normal<- NOTE: Wrong hostname!!
> 2017-08-11 16:27:13.8460 +0100 POLICY (info) Policy configured 
> maxConnections: 65535, policyDir: '', access rules enabled: 'false'
> 2017-08-11 16:27:13.9149 +0100 POLICY (info) Policy fallback defaultVhost is 
> defined: '$default'
> 2017-08-11 16:27:13.9175 +0100 SERVER (notice) Operational, 4 Threads Running 
> (process ID 3236)
> 2017-08-11 16:27:13.9286 +0100 SERVER (notice) Listening on 0.0.0.0:amqp
> {noformat}
> And indeed it connects to a broker on the local host.



--
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-804) connectors ignore addr

2017-08-11 Thread Gordon Sim (JIRA)


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

Gordon Sim commented on DISPATCH-804:
-

Possible fix:

{noformat}
diff --git a/src/connection_manager.c b/src/connection_manager.c
index 513b16c..041f231 100644
--- a/src/connection_manager.c
+++ b/src/connection_manager.c
@@ -165,6 +165,10 @@ static void set_config_host(qd_server_config_t *config, 
qd_entity_t* entity)
 config->host = host;
 free(addr);
 }
+else if (host && addr && strcmp(host, addr) != 0 && strcmp(host, 
"127.0.0.1") == 0) {
+config->host = addr;
+free(host);
+}
 else if (host && strcmp(host, "") != 0 ) {
 config->host = host;
 free(addr);
{noformat}

> connectors ignore addr
> --
>
> Key: DISPATCH-804
> URL: https://issues.apache.org/jira/browse/DISPATCH-804
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
>Priority: Blocker
> Fix For: 1.0.0
>
>
> The addr field of connector appears to be entirely ignored, with 127.0.0.1 
> used instead. E.g. with the following config:
> {noformat}
> router {
> mode: standalone
> routerId: myrouter
> }
> listener {
> addr: 0.0.0.0
> port: amqp
> authenticatePeer: no
> }
> connector {
> name: myconnector
> addr: google.com
> port: 5673
> }
> {noformat}
> you see 
> {noformat}
> 2017-08-11 16:27:13.184 +0100 AGENT (warning) routerId is deprecated, use id 
> instead
> 2017-08-11 16:27:13.555 +0100 SERVER (warning) HTTP support is not available
> 2017-08-11 16:27:13.563 +0100 SERVER (info) Container Name: myrouter
> 2017-08-11 16:27:13.651 +0100 ROUTER (info) Router started in Standalone mode
> 2017-08-11 16:27:13.679 +0100 ROUTER_CORE (info) Allow Unsettled Multicast: no
> 2017-08-11 16:27:13.1033 +0100 ROUTER_CORE (info) Router Core thread running. 
> 0/myrouter
> 2017-08-11 16:27:13.1049 +0100 ROUTER_CORE (info) In-process subscription 
> M/$management
> 2017-08-11 16:27:13.7044 +0100 AGENT (info) Activating management agent on 
> $_management_internal
> 2017-08-11 16:27:13.7099 +0100 ROUTER_CORE (info) In-process subscription 
> L/$management
> 2017-08-11 16:27:13.7122 +0100 ROUTER_CORE (info) In-process subscription 
> L/$_management_internal
> 2017-08-11 16:27:13.7410 +0100 CONN_MGR (info) Configured Listener: 
> 0.0.0.0:amqp proto=any, role=normal
> 2017-08-11 16:27:13.8007 +0100 CONN_MGR (info) Configured Connector: 
> 127.0.0.1:5673 proto=any, role=normal<- NOTE: Wrong hostname!!
> 2017-08-11 16:27:13.8460 +0100 POLICY (info) Policy configured 
> maxConnections: 65535, policyDir: '', access rules enabled: 'false'
> 2017-08-11 16:27:13.9149 +0100 POLICY (info) Policy fallback defaultVhost is 
> defined: '$default'
> 2017-08-11 16:27:13.9175 +0100 SERVER (notice) Operational, 4 Threads Running 
> (process ID 3236)
> 2017-08-11 16:27:13.9286 +0100 SERVER (notice) Listening on 0.0.0.0:amqp
> {noformat}
> And indeed it connects to a broker on the local host.



--
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-804) connectors ignore addr

2017-08-11 Thread Ganesh Murthy (JIRA)


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

Ganesh Murthy reassigned DISPATCH-804:
--

Assignee: Ganesh Murthy

> connectors ignore addr
> --
>
> Key: DISPATCH-804
> URL: https://issues.apache.org/jira/browse/DISPATCH-804
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
>Priority: Blocker
> Fix For: 1.0.0
>
>
> The addr field of connector appears to be entirely ignored, with 127.0.0.1 
> used instead. E.g. with the following config:
> {noformat}
> router {
> mode: standalone
> routerId: myrouter
> }
> listener {
> addr: 0.0.0.0
> port: amqp
> authenticatePeer: no
> }
> connector {
> name: myconnector
> addr: google.com
> port: 5673
> }
> {noformat}
> you see 
> {noformat}
> 2017-08-11 16:27:13.184 +0100 AGENT (warning) routerId is deprecated, use id 
> instead
> 2017-08-11 16:27:13.555 +0100 SERVER (warning) HTTP support is not available
> 2017-08-11 16:27:13.563 +0100 SERVER (info) Container Name: myrouter
> 2017-08-11 16:27:13.651 +0100 ROUTER (info) Router started in Standalone mode
> 2017-08-11 16:27:13.679 +0100 ROUTER_CORE (info) Allow Unsettled Multicast: no
> 2017-08-11 16:27:13.1033 +0100 ROUTER_CORE (info) Router Core thread running. 
> 0/myrouter
> 2017-08-11 16:27:13.1049 +0100 ROUTER_CORE (info) In-process subscription 
> M/$management
> 2017-08-11 16:27:13.7044 +0100 AGENT (info) Activating management agent on 
> $_management_internal
> 2017-08-11 16:27:13.7099 +0100 ROUTER_CORE (info) In-process subscription 
> L/$management
> 2017-08-11 16:27:13.7122 +0100 ROUTER_CORE (info) In-process subscription 
> L/$_management_internal
> 2017-08-11 16:27:13.7410 +0100 CONN_MGR (info) Configured Listener: 
> 0.0.0.0:amqp proto=any, role=normal
> 2017-08-11 16:27:13.8007 +0100 CONN_MGR (info) Configured Connector: 
> 127.0.0.1:5673 proto=any, role=normal<- NOTE: Wrong hostname!!
> 2017-08-11 16:27:13.8460 +0100 POLICY (info) Policy configured 
> maxConnections: 65535, policyDir: '', access rules enabled: 'false'
> 2017-08-11 16:27:13.9149 +0100 POLICY (info) Policy fallback defaultVhost is 
> defined: '$default'
> 2017-08-11 16:27:13.9175 +0100 SERVER (notice) Operational, 4 Threads Running 
> (process ID 3236)
> 2017-08-11 16:27:13.9286 +0100 SERVER (notice) Listening on 0.0.0.0:amqp
> {noformat}
> And indeed it connects to a broker on the local host.



--
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-805) System test system_tests_sasl_plain fails in systems with TLSv1.2

2017-08-11 Thread Ganesh Murthy (JIRA)

Ganesh Murthy created DISPATCH-805:
--

 Summary: System test system_tests_sasl_plain fails in systems with 
TLSv1.2
 Key: DISPATCH-805
 URL: https://issues.apache.org/jira/browse/DISPATCH-805
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Routing Engine, Tests
Affects Versions: 0.8.0
Reporter: Ganesh Murthy
Assignee: Ganesh Murthy
 Fix For: 1.0.0


A couple of tests in system_tests_sasl_plain.py tests for hard coded string 
*TLSv1/SSLv3* as the TLS version. The version of TLS can vary. It could be 
*TLSv1.2*

Instead of asserting
{noformat}
self.assertEqual(u'TLSv1/SSLv3', results[0][10])
{noformat}

we should do
{noformat}
self.assertTrue(u'TLSv1' in results[0][10])
{noformat}

Following is the trace from the failing test
{noformat}
24: ==
24: FAIL: test_inter_router_plain_over_ssl_exists 
(system_tests_sasl_plain.RouterTestVerifyHostNameNo)
24: --
24: Traceback (most recent call last):
24:   File "/foo/qpid-dispatch/tests/system_tests_sasl_plain.py", line 525, in 
test_inter_router_plain_over_ssl_exists
24: self.common_asserts(results)
24:   File "/foo/qpid-dispatch/tests/system_tests_sasl_plain.py", line 503, in 
common_asserts
24: self.assertEqual(u'TLSv1/SSLv3', results[N][10])
24: AssertionError: u'TLSv1/SSLv3' != u'TLSv1.2'
24: - TLSv1/SSLv3
24: + TLSv1.2
24:
24:
24: ==
24: FAIL: test_zzz_delete_create_ssl_profile 
(system_tests_sasl_plain.RouterTestVerifyHostNameNo)
24: --
24: Traceback (most recent call last):
24:   File "/foo/qpid-dispatch/tests/system_tests_sasl_plain.py", line 564, in 
test_zzz_delete_create_ssl_profile
24: self.common_asserts(results)
24:   File "/foo/qpid-dispatch/tests/system_tests_sasl_plain.py", line 503, in 
common_asserts
24: self.assertEqual(u'TLSv1/SSLv3', results[N][10])
24: AssertionError: u'TLSv1/SSLv3' != u'TLSv1.2'
24: - TLSv1/SSLv3
24: + TLSv1.2
24:
24:
24: --
24: Ran 8 tests in 15.760s
24:
24: FAILED (failures=3)
{noformat}



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

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

[jira] [Commented] (DISPATCH-804) connectors ignore addr

2017-08-11 Thread Gordon Sim (JIRA)


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

Gordon Sim commented on DISPATCH-804:
-

Looks to be related to https://issues.apache.org/jira/browse/DISPATCH-763, the 
fix for which prevents the crash, but doesn't actually use the addr.

> connectors ignore addr
> --
>
> Key: DISPATCH-804
> URL: https://issues.apache.org/jira/browse/DISPATCH-804
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Gordon Sim
>Priority: Blocker
> Fix For: 1.0.0
>
>
> The addr field of connector appears to be entirely ignored, with 127.0.0.1 
> used instead. E.g. with the following config:
> {noformat}
> router {
> mode: standalone
> routerId: myrouter
> }
> listener {
> addr: 0.0.0.0
> port: amqp
> authenticatePeer: no
> }
> connector {
> name: myconnector
> addr: google.com
> port: 5673
> }
> {noformat}
> you see 
> {noformat}
> 2017-08-11 16:27:13.184 +0100 AGENT (warning) routerId is deprecated, use id 
> instead
> 2017-08-11 16:27:13.555 +0100 SERVER (warning) HTTP support is not available
> 2017-08-11 16:27:13.563 +0100 SERVER (info) Container Name: myrouter
> 2017-08-11 16:27:13.651 +0100 ROUTER (info) Router started in Standalone mode
> 2017-08-11 16:27:13.679 +0100 ROUTER_CORE (info) Allow Unsettled Multicast: no
> 2017-08-11 16:27:13.1033 +0100 ROUTER_CORE (info) Router Core thread running. 
> 0/myrouter
> 2017-08-11 16:27:13.1049 +0100 ROUTER_CORE (info) In-process subscription 
> M/$management
> 2017-08-11 16:27:13.7044 +0100 AGENT (info) Activating management agent on 
> $_management_internal
> 2017-08-11 16:27:13.7099 +0100 ROUTER_CORE (info) In-process subscription 
> L/$management
> 2017-08-11 16:27:13.7122 +0100 ROUTER_CORE (info) In-process subscription 
> L/$_management_internal
> 2017-08-11 16:27:13.7410 +0100 CONN_MGR (info) Configured Listener: 
> 0.0.0.0:amqp proto=any, role=normal
> 2017-08-11 16:27:13.8007 +0100 CONN_MGR (info) Configured Connector: 
> 127.0.0.1:5673 proto=any, role=normal<- NOTE: Wrong hostname!!
> 2017-08-11 16:27:13.8460 +0100 POLICY (info) Policy configured 
> maxConnections: 65535, policyDir: '', access rules enabled: 'false'
> 2017-08-11 16:27:13.9149 +0100 POLICY (info) Policy fallback defaultVhost is 
> defined: '$default'
> 2017-08-11 16:27:13.9175 +0100 SERVER (notice) Operational, 4 Threads Running 
> (process ID 3236)
> 2017-08-11 16:27:13.9286 +0100 SERVER (notice) Listening on 0.0.0.0:amqp
> {noformat}
> And indeed it connects to a broker on the local host.



--
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-804) connectors ignore addr

2017-08-11 Thread Gordon Sim (JIRA)

Gordon Sim created DISPATCH-804:
---

 Summary: connectors ignore addr
 Key: DISPATCH-804
 URL: https://issues.apache.org/jira/browse/DISPATCH-804
 Project: Qpid Dispatch
  Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Gordon Sim
Priority: Blocker
 Fix For: 1.0.0


The addr field of connector appears to be entirely ignored, with 127.0.0.1 used 
instead. E.g. with the following config:

{noformat}
router {
mode: standalone
routerId: myrouter
}

listener {
addr: 0.0.0.0
port: amqp
authenticatePeer: no
}

connector {
name: myconnector
addr: google.com
port: 5673
}
{noformat}

you see 

{noformat}
2017-08-11 16:27:13.184 +0100 AGENT (warning) routerId is deprecated, use id 
instead
2017-08-11 16:27:13.555 +0100 SERVER (warning) HTTP support is not available
2017-08-11 16:27:13.563 +0100 SERVER (info) Container Name: myrouter
2017-08-11 16:27:13.651 +0100 ROUTER (info) Router started in Standalone mode
2017-08-11 16:27:13.679 +0100 ROUTER_CORE (info) Allow Unsettled Multicast: no
2017-08-11 16:27:13.1033 +0100 ROUTER_CORE (info) Router Core thread running. 
0/myrouter
2017-08-11 16:27:13.1049 +0100 ROUTER_CORE (info) In-process subscription 
M/$management
2017-08-11 16:27:13.7044 +0100 AGENT (info) Activating management agent on 
$_management_internal
2017-08-11 16:27:13.7099 +0100 ROUTER_CORE (info) In-process subscription 
L/$management
2017-08-11 16:27:13.7122 +0100 ROUTER_CORE (info) In-process subscription 
L/$_management_internal
2017-08-11 16:27:13.7410 +0100 CONN_MGR (info) Configured Listener: 
0.0.0.0:amqp proto=any, role=normal
2017-08-11 16:27:13.8007 +0100 CONN_MGR (info) Configured Connector: 
127.0.0.1:5673 proto=any, role=normal<- NOTE: Wrong hostname!!
2017-08-11 16:27:13.8460 +0100 POLICY (info) Policy configured maxConnections: 
65535, policyDir: '', access rules enabled: 'false'
2017-08-11 16:27:13.9149 +0100 POLICY (info) Policy fallback defaultVhost is 
defined: '$default'
2017-08-11 16:27:13.9175 +0100 SERVER (notice) Operational, 4 Threads Running 
(process ID 3236)
2017-08-11 16:27:13.9286 +0100 SERVER (notice) Listening on 0.0.0.0:amqp
{noformat}

And indeed it connects to a broker on the local host.



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

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

[jira] [Assigned] (QPID-7815) Reject policy type

2017-08-11 Thread Alex Rudyy (JIRA)


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

Alex Rudyy reassigned QPID-7815:


Assignee: (was: Alex Rudyy)

> Reject policy type
> --
>
> Key: QPID-7815
> URL: https://issues.apache.org/jira/browse/QPID-7815
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Tomas Vavricka
>  Labels: policy-type, queue, reject
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 0001-QPID-7815-Add-support-for-reject-policy.patch, 
> 0001-QPID-7815-Fix-recovery-of-queue-with-reject-policy.patch, 
> 0001-QPID-7815-Java-Broker-Enable-QueuePolicyTests-on-all.patch, 
> 0001-QPID-7815-Reject-policy-type.patch, 1 before restart.png, 2 after 
> restart.png, broker.log, default.json
>
>
> It would be good if Java Broker will support reject policy.
> Reject policy - reject incoming message(s) when queue capacity is reached
> Queue capacity can be defined by maximum count of message and maximum size of 
> messages (including header).



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

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

[jira] [Assigned] (QPID-7815) Reject policy type

2017-08-11 Thread Alex Rudyy (JIRA)


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

Alex Rudyy reassigned QPID-7815:


Assignee: Alex Rudyy  (was: Lorenz Quack)

> Reject policy type
> --
>
> Key: QPID-7815
> URL: https://issues.apache.org/jira/browse/QPID-7815
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Tomas Vavricka
>Assignee: Alex Rudyy
>  Labels: policy-type, queue, reject
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 0001-QPID-7815-Add-support-for-reject-policy.patch, 
> 0001-QPID-7815-Fix-recovery-of-queue-with-reject-policy.patch, 
> 0001-QPID-7815-Java-Broker-Enable-QueuePolicyTests-on-all.patch, 
> 0001-QPID-7815-Reject-policy-type.patch, 1 before restart.png, 2 after 
> restart.png, broker.log, default.json
>
>
> It would be good if Java Broker will support reject policy.
> Reject policy - reject incoming message(s) when queue capacity is reached
> Queue capacity can be defined by maximum count of message and maximum size of 
> messages (including header).



--
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-7815) Reject policy type

2017-08-11 Thread Alex Rudyy (JIRA)


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

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

> Reject policy type
> --
>
> Key: QPID-7815
> URL: https://issues.apache.org/jira/browse/QPID-7815
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Tomas Vavricka
>Assignee: Alex Rudyy
>  Labels: policy-type, queue, reject
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 0001-QPID-7815-Add-support-for-reject-policy.patch, 
> 0001-QPID-7815-Fix-recovery-of-queue-with-reject-policy.patch, 
> 0001-QPID-7815-Java-Broker-Enable-QueuePolicyTests-on-all.patch, 
> 0001-QPID-7815-Reject-policy-type.patch, 1 before restart.png, 2 after 
> restart.png, broker.log, default.json
>
>
> It would be good if Java Broker will support reject policy.
> Reject policy - reject incoming message(s) when queue capacity is reached
> Queue capacity can be defined by maximum count of message and maximum size of 
> messages (including header).



--
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-7886) [Java Broker] [WMC] Expose ability to get a thread dump

2017-08-11 Thread Alex Rudyy (JIRA)


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

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

The changes look good to me

> [Java Broker] [WMC] Expose ability to get a thread dump
> ---
>
> Key: QPID-7886
> URL: https://issues.apache.org/jira/browse/QPID-7886
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> For support reasons, it is sometimes desirable for operators to collect a 
> thread dump from the Broker's JVM.  The operation is already built into the 
> REST API, but needs exposing through the UI to simplify its use.



--
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-7886) [Java Broker] [WMC] Expose ability to get a thread dump

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


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

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

Commit 6837975b7f4126fd6a3cb1f1c3a50913e5a3fd6d 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=6837975 ]

QPID-7886: [Java Broker] Hide download iframe


> [Java Broker] [WMC] Expose ability to get a thread dump
> ---
>
> Key: QPID-7886
> URL: https://issues.apache.org/jira/browse/QPID-7886
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> For support reasons, it is sometimes desirable for operators to collect a 
> thread dump from the Broker's JVM.  The operation is already built into the 
> REST API, but needs exposing through the UI to simplify its use.



--
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-7887) [Java Broker] Message conversion error handling

2017-08-11 Thread Lorenz Quack (JIRA)


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

Lorenz Quack updated QPID-7887:
---
Description: 
The work done in QPID-7434 means that {{MessageConversionExceptions}} are now 
thrown when errors in message conversion are encountered. These exceptions need 
to be handled.

The following handling is proposed:
There is a context variable 
{{qpid.queue.messageConversion.exceptionHandlingPolicy}} which materialises at 
the {{Queue}} level and can take one of these values:
* {{"close"}} - the connection(0-x)/link(1.0) to the consumer will be closed
* {{"routeToAlternate"}} - the message will be routed to the alternate 
destination or deleted if no alternative destination is configured. If the 
consumer is a QueueBrowser it should simply skip the message in question 
without triggering this behaviour.

{{"close"}} should be the default.

  was:
The work done in QPID-7434 means that {{MessageConversionExceptions}} are now 
thrown when errors in message conversion are encountered. These exceptions need 
to be handled.

The following handling is proposed:
There is a context variable 
{{qpid.queue.messageConversion.exceptionHandlingPolicy}} which materialises at 
the {{Queue}} level and can take one of these values:
* {{"close"}} - the connection(0-x)/link(1.0) to the consumer will be closed
* {{"routeToAlternate"}} - the message will be routed to the alternate 
destination or deleted if no alternative destination is configured. If the 
consumer is a QueueBrowser it should simply skip the message in question 
without triggering this behaviour.
{{"close"}} should be the default.


> [Java Broker] Message conversion error handling
> ---
>
> Key: QPID-7887
> URL: https://issues.apache.org/jira/browse/QPID-7887
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> The work done in QPID-7434 means that {{MessageConversionExceptions}} are now 
> thrown when errors in message conversion are encountered. These exceptions 
> need to be handled.
> The following handling is proposed:
> There is a context variable 
> {{qpid.queue.messageConversion.exceptionHandlingPolicy}} which materialises 
> at the {{Queue}} level and can take one of these values:
> * {{"close"}} - the connection(0-x)/link(1.0) to the consumer will be closed
> * {{"routeToAlternate"}} - the message will be routed to the alternate 
> destination or deleted if no alternative destination is configured. If the 
> consumer is a QueueBrowser it should simply skip the message in question 
> without triggering this behaviour.
> {{"close"}} should be the default.



--
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-7887) [Java Broker] Message conversion error handling

2017-08-11 Thread Lorenz Quack (JIRA)


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

Lorenz Quack updated QPID-7887:
---
Description: 
The work done in QPID-7434 means that {{MessageConversionExceptions}} are now 
thrown when errors in message conversion are encountered. These exceptions need 
to be handled.

The following handling is proposed:
There is a context variable 
{{qpid.queue.messageConversion.exceptionHandlingPolicy}} which materialises at 
the {{Queue}} level and can take one of these values:
* {{"close"}} - the connection(0-x)/link(1.0) to the consumer will be closed
* {{"routeToAlternate"}} - the message will be routed to the alternate 
destination or deleted if no alternative destination is configured. If the 
consumer is a QueueBrowser it should simply skip the message in question 
without triggering this behaviour.
{{"close"}} should be the default.

  was:
The work done in QPID-7434 means that {{MessageConversionExceptions}} are now 
thrown when errors in message conversion are encountered. These exceptions need 
to be handled.

The following handling is proposed:
There is a context variable 
{{qpid.queue.messageConversion.exceptionHandlingStrategy}} which materialises 
at the {{Queue}} level and can take one of these values:
* {{"close"}} - the connection(0-x)/link(1.0) to the consumer will be closed
* {{"routeToAlternate"}} - the message will be routed to the alternate 
destination or deleted if no alternative destination is configured. If the 
consumer is a QueueBrowser it should simply skip the message in question 
without triggering this behaviour.
{{"close"}} should be the default.


> [Java Broker] Message conversion error handling
> ---
>
> Key: QPID-7887
> URL: https://issues.apache.org/jira/browse/QPID-7887
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> The work done in QPID-7434 means that {{MessageConversionExceptions}} are now 
> thrown when errors in message conversion are encountered. These exceptions 
> need to be handled.
> The following handling is proposed:
> There is a context variable 
> {{qpid.queue.messageConversion.exceptionHandlingPolicy}} which materialises 
> at the {{Queue}} level and can take one of these values:
> * {{"close"}} - the connection(0-x)/link(1.0) to the consumer will be closed
> * {{"routeToAlternate"}} - the message will be routed to the alternate 
> destination or deleted if no alternative destination is configured. If the 
> consumer is a QueueBrowser it should simply skip the message in question 
> without triggering this behaviour.
> {{"close"}} should be the default.



--
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-7815) Reject policy type

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


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

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

Commit b7ee49ded4df66ecbb7b4836c599471659358e7e 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=b7ee49d ]

QPID-7815: [Java Broker] Invoke overflow policy check on queue maximum queue 
depth changes


> Reject policy type
> --
>
> Key: QPID-7815
> URL: https://issues.apache.org/jira/browse/QPID-7815
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Tomas Vavricka
>Assignee: Lorenz Quack
>  Labels: policy-type, queue, reject
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 0001-QPID-7815-Add-support-for-reject-policy.patch, 
> 0001-QPID-7815-Fix-recovery-of-queue-with-reject-policy.patch, 
> 0001-QPID-7815-Java-Broker-Enable-QueuePolicyTests-on-all.patch, 
> 0001-QPID-7815-Reject-policy-type.patch, 1 before restart.png, 2 after 
> restart.png, broker.log, default.json
>
>
> It would be good if Java Broker will support reject policy.
> Reject policy - reject incoming message(s) when queue capacity is reached
> Queue capacity can be defined by maximum count of message and maximum size of 
> messages (including header).



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

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

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

2017-08-11 Thread Alan Conway (JIRA)


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

Alan Conway commented on PROTON-1519:
-

Yes - the original fix made the code conditional on the Ruby version. I removed 
all refs to Fixnum and Bignum entirely so we have a single codebase that works 
on all ruby versions.

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



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

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

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

2017-08-11 Thread Alan Conway (JIRA)


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

Alan Conway edited comment on PROTON-1519 at 8/11/17 2:55 PM:
--

Yes - the original fix made the code conditional on the Ruby version. I removed 
all refs to Fixnum and Bignum entirely so we have a single codebase that works 
on all ruby versions.
That explains why the PR was closed :)



was (Author: aconway):
Yes - the original fix made the code conditional on the Ruby version. I removed 
all refs to Fixnum and Bignum entirely so we have a single codebase that works 
on all ruby versions.

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



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

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

[jira] [Created] (QPID-7887) [Java Broker] Message conversion error handling

2017-08-11 Thread Lorenz Quack (JIRA)

Lorenz Quack created QPID-7887:
--

 Summary: [Java Broker] Message conversion error handling
 Key: QPID-7887
 URL: https://issues.apache.org/jira/browse/QPID-7887
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Lorenz Quack
 Fix For: qpid-java-broker-7.0.0


The work done in QPID-7434 means that {{MessageConversionExceptions}} are now 
thrown when errors in message conversion are encountered. These exceptions need 
to be handled.

The following handling is proposed:
There is a context variable 
{{qpid.queue.messageConversion.exceptionHandlingStrategy}} which materialises 
at the {{Queue}} level and can take one of these values:
* {{"close"}} - the connection(0-x)/link(1.0) to the consumer will be closed
* {{"routeToAlternate"}} - the message will be routed to the alternate 
destination or deleted if no alternative destination is configured. If the 
consumer is a QueueBrowser it should simply skip the message in question 
without triggering this behaviour.
{{"close"}} should be the default.



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

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

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

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


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

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

Commit 385167e1f6085aceddb2ded398ad504bb40aed98 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=385167e ]

QPID-7434: [Java Broker] Improve handling of empty map/stream messages.


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



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

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

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

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


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

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

Commit 17e6c7d6e070ecfa8a46edb643607b0c6ef9d099 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=17e6c7d ]

QPID-7434: [Java Broker] Improve Internal to AMQP 0-x message conversion and 
add unit tests


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



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

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

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

2017-08-11 Thread Lorenz Quack (JIRA)


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

Lorenz Quack resolved QPID-7434.

Resolution: Fixed

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



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

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

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

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


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

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

Commit 939cda5bf529bc0ecf911f6af586eb48573bbcca 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=939cda5 ]

QPID-7434: [Java Broker] Improve AMQP 0-x to Internal conversion and add unit 
tests.


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



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

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

[GitHub] qpid-proton issue #111: Fix mapping of LONG for Ruby 2.4+

2017-08-11 Thread astitcher

Github user astitcher commented on the issue:

https://github.com/apache/qpid-proton/pull/111
  
I applied this fix  - that's why it's closed.


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

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

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

2017-08-11 Thread Alan Conway (JIRA)


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

Alan Conway reopened PROTON-1532:
-

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

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

2017-08-11 Thread Andrew Stitcher (JIRA)


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

Andrew Stitcher edited comment on PROTON-1519 at 8/11/17 2:11 PM:
--

I already applied this fix to 0.18 SHA e6aaadb21f47e7e9168bb68570111446546997bf

Edited:

Or maybe I applied a different change that this one seems to back out - did you 
decide to use a different fix?


was (Author: astitcher):
I already applied this fix to 0.18 SHA e6aaadb21f47e7e9168bb68570111446546997bf

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



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

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

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

2017-08-11 Thread Alan Conway (JIRA)


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

Alan Conway commented on PROTON-1532:
-

Excellent, thank you for that! I am in the process of cleaning up ruby issues, 
this is very helpful. I'll review and  mrege or get back to you with questions.

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

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

2017-08-11 Thread Andrew Stitcher (JIRA)


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

Andrew Stitcher commented on PROTON-1519:
-

I already applied this fix to 0.18 SHA e6aaadb21f47e7e9168bb68570111446546997bf

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



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

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

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

2017-08-11 Thread Alan Conway (JIRA)


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

Alan Conway resolved PROTON-1519.
-
Resolution: Fixed

Fix based on PR 111 from  [~Fryguy], extended to eliminate Fixnum/Bignum 
entirely from the codebase so we have consistent code using the Integer class 
only for all ruby versions.

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



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

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

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

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


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

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

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

PROTON-1519 ruby: Integer mapping does not work with Ruby 2.4

Ruby < 2.4 had separate Fixnum, Bignum subclasses of Integer. Ruby 2.4 makes
them all the same class, this breaks class-equality type mapping in mapping.rb.

Replaced all uses of Fixnum/Bignum with Integer. Type-mapping now uses
superclass match - type X maps if X is known OR if any superclass of X is known.


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



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

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

[GitHub] qpid-dispatch pull request #187: DISPATCH-802 - Refuse transaction coordinat...

2017-08-11 Thread ganeshmurthy

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-802 - Refuse transaction coordination links if they can't beâ¦

â¦ routed to a coordinator since the router by itself cannot coordinate 
transactions.

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

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

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

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


commit dccf0d25bf64da85b64889f98cbbb35da32c2af6
Author: Ganesh Murthy 
Date:   2017-08-04T19:19:15Z

DISPATCH-802 - Refuse transaction coordination links if they can't be 
routed to a coordinator since the router by itself cannot coordinate 
transactions.




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

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

[jira] [Commented] (DISPATCH-802) refuse transaction coordination links if they can't be routed to a coordinator

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


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

ASF GitHub Bot commented on DISPATCH-802:
-

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-802 - Refuse transaction coordination links if they can't be…

… routed to a coordinator since the router by itself cannot coordinate 
transactions.

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

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

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

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


commit dccf0d25bf64da85b64889f98cbbb35da32c2af6
Author: Ganesh Murthy 
Date:   2017-08-04T19:19:15Z

DISPATCH-802 - Refuse transaction coordination links if they can't be 
routed to a coordinator since the router by itself cannot coordinate 
transactions.




> refuse transaction coordination links if they can't be routed to a coordinator
> --
>
> Key: DISPATCH-802
> URL: https://issues.apache.org/jira/browse/DISPATCH-802
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.8.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>
> The router is accepting transaction coordinator links even if the support 
> from DISPATCH-195 is not being used to link-route them somewhere that can 
> handle coordination. If the router can't link-route to a coordinator, and 
> knows it can't coordinate transactions itself, it shouldn't accept the links 
> to begin with but rather refuse them so clients know they will never work and 
> why.
> Prior to 0.8.0, credit was also given on these links, allowing attempt to 
> declare transactions. From 0.8.0 no credit is given since there is no 
> receiver, so clients have no way to use the accepted link and no indication 
> why.



--
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-802) refuse transaction coordination links if they can't be routed to a coordinator

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


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

ASF GitHub Bot commented on DISPATCH-802:
-

Github user ganeshmurthy closed the pull request at:

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


> refuse transaction coordination links if they can't be routed to a coordinator
> --
>
> Key: DISPATCH-802
> URL: https://issues.apache.org/jira/browse/DISPATCH-802
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.8.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>
> The router is accepting transaction coordinator links even if the support 
> from DISPATCH-195 is not being used to link-route them somewhere that can 
> handle coordination. If the router can't link-route to a coordinator, and 
> knows it can't coordinate transactions itself, it shouldn't accept the links 
> to begin with but rather refuse them so clients know they will never work and 
> why.
> Prior to 0.8.0, credit was also given on these links, allowing attempt to 
> declare transactions. From 0.8.0 no credit is given since there is no 
> receiver, so clients have no way to use the accepted link and no indication 
> why.



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

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

[GitHub] qpid-dispatch pull request #184: DISPATCH-802 - Refuse transaction coordinat...

2017-08-11 Thread ganeshmurthy

Github user ganeshmurthy closed the pull request at:

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


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

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

[jira] [Commented] (QPID-7815) Reject policy type

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


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

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

Commit 42bebb9ff6e92f81eaffbd8d8a5350f3e6c10b1d 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=42bebb9 ]

QPID-7815: [Java Broker] Move overflow policy handlers creation from afterSet 
into changeAttributes


> Reject policy type
> --
>
> Key: QPID-7815
> URL: https://issues.apache.org/jira/browse/QPID-7815
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Tomas Vavricka
>Assignee: Lorenz Quack
>  Labels: policy-type, queue, reject
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 0001-QPID-7815-Add-support-for-reject-policy.patch, 
> 0001-QPID-7815-Fix-recovery-of-queue-with-reject-policy.patch, 
> 0001-QPID-7815-Java-Broker-Enable-QueuePolicyTests-on-all.patch, 
> 0001-QPID-7815-Reject-policy-type.patch, 1 before restart.png, 2 after 
> restart.png, broker.log, default.json
>
>
> It would be good if Java Broker will support reject policy.
> Reject policy - reject incoming message(s) when queue capacity is reached
> Queue capacity can be defined by maximum count of message and maximum size of 
> messages (including header).



--
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-08-11 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on PROTON-1532:


GitHub user gberginc opened a pull request:

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

PROTON-1532: Allow insecure mechanism in SASL

This commit extends SASL with the additional allow_insecure_mechs allowing 
users to override the defailt (false) authentication and use the plain 
mechanism. It also extends the Connection class to expose user and password 
that is used by the plain mechanism.

Finally, this patch modifies the connect method which now avoids the use of 
the plain method which is not defined on SASL. The code now more resembles the 
Python version.

This addresses the issue reported in 
[PROTON-1532](https://issues.apache.org/jira/browse/PROTON-1532) where I was 
trying to connect to an ActiveMQ using plain username/password authentication. 
Previous code used method `plain` which does not exist.

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

$ git pull https://github.com/gberginc/qpid-proton sasl_allow_insecure

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

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


commit e218be1f128f1c7452ca19626577043c46e53651
Author: Gregor Berginc 
Date:   2017-08-11T12:00:34Z

PROTON-1532: Allow insecure mechanism in SASL

This commit extends SASL with the additional allow_insecure_mechs allowing 
users to override the defailt (false) authentication and use the plain 
mechanism. It also extends the Connection class to expose user and password 
that is used by the plain mechanism.

Finally, this patch modifies the connect method which now avoids the use of 
the plain method which is not defined on SASL. The code now more resembles the 
Python version.

Signed-off-by: Gregor Berginc 




> 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
>
> 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 pull request #116: PROTON-1532: Allow insecure mechanism in SASL

2017-08-11 Thread gberginc

GitHub user gberginc opened a pull request:

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

PROTON-1532: Allow insecure mechanism in SASL

This commit extends SASL with the additional allow_insecure_mechs allowing 
users to override the defailt (false) authentication and use the plain 
mechanism. It also extends the Connection class to expose user and password 
that is used by the plain mechanism.

Finally, this patch modifies the connect method which now avoids the use of 
the plain method which is not defined on SASL. The code now more resembles the 
Python version.

This addresses the issue reported in 
[PROTON-1532](https://issues.apache.org/jira/browse/PROTON-1532) where I was 
trying to connect to an ActiveMQ using plain username/password authentication. 
Previous code used method `plain` which does not exist.

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

$ git pull https://github.com/gberginc/qpid-proton sasl_allow_insecure

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

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


commit e218be1f128f1c7452ca19626577043c46e53651
Author: Gregor Berginc 
Date:   2017-08-11T12:00:34Z

PROTON-1532: Allow insecure mechanism in SASL

This commit extends SASL with the additional allow_insecure_mechs allowing 
users to override the defailt (false) authentication and use the plain 
mechanism. It also extends the Connection class to expose user and password 
that is used by the plain mechanism.

Finally, this patch modifies the connect method which now avoids the use of 
the plain method which is not defined on SASL. The code now more resembles the 
Python version.

Signed-off-by: Gregor Berginc 




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

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

[jira] [Updated] (PROTON-927) absolute-expiry-time, creation-time and priority are encoded as 0 if not set

2017-08-11 Thread Gordon Sim (JIRA)


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

Gordon Sim updated PROTON-927:
--
Description: They should instead be encoded as null (since there is no 
default). (Possibly affects all numeric fields in headers and properties 
sections(?))  (was: They should instead be encoded as null (since there is no 
default).)
Summary: absolute-expiry-time, creation-time and priority are encoded 
as 0 if not set  (was: absolute-expiry-time and creation-time are encoded as 0 
if not set)

> absolute-expiry-time, creation-time and priority are encoded as 0 if not set
> 
>
> Key: PROTON-927
> URL: https://issues.apache.org/jira/browse/PROTON-927
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.9.1
>Reporter: Gordon Sim
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> They should instead be encoded as null (since there is no default). (Possibly 
> affects all numeric fields in headers and properties 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] [Comment Edited] (PROTON-927) absolute-expiry-time and creation-time are encoded as 0 if not set

2017-08-11 Thread Radim Kubis (JIRA)


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

Radim Kubis edited comment on PROTON-927 at 8/11/17 11:13 AM:
--

The same behaviour is for message priority. If message priority is not set in 
message, it is encoded as 0, but it means that priority has default value 4 
according to specification of AMQP 1.0.


was (Author: rkubis):
The same behaviour is for message priority.

> absolute-expiry-time and creation-time are encoded as 0 if not set
> --
>
> Key: PROTON-927
> URL: https://issues.apache.org/jira/browse/PROTON-927
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.9.1
>Reporter: Gordon Sim
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> They should instead be encoded as null (since there is no default).



--
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-927) absolute-expiry-time and creation-time are encoded as 0 if not set

2017-08-11 Thread Radim Kubis (JIRA)


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

Radim Kubis commented on PROTON-927:


The same behaviour is for message priority.

> absolute-expiry-time and creation-time are encoded as 0 if not set
> --
>
> Key: PROTON-927
> URL: https://issues.apache.org/jira/browse/PROTON-927
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.9.1
>Reporter: Gordon Sim
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> They should instead be encoded as null (since there is no default).



--
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-7781) [Java Broker] 500 error whilst deleting a virtualhost.

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


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

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

Commit a946173df9c08036c9504d07758f6b2085b083b9 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=a946173 ]

QPID-7781: [Java Broker] Move Add Virtual Host into Virtual Host panel and add 
Virtual Host delete button


> [Java Broker] 500 error whilst deleting a virtualhost.
> --
>
> Key: QPID-7781
> URL: https://issues.apache.org/jira/browse/QPID-7781
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Lorenz Quack
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The following 500 was encountered whilst deleting a JSON/Derby store backed 
> virtualhostnode/virtualhost.  The virtualhost had three messages on two 
> queues.  Clients were connected to the queues at the time (stopped on a 
> breakpoint).  The Broker did not crash.
> This will probably be just a trunk issue.
> {noformat}
> 2017-05-12 15:28:34,596 ERROR [HttpManagement-HTTP-89] 
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet 
> '/api/latest/virtualhostnode':
> java.lang.IllegalStateException: Message store is not open
> at 
> org.apache.qpid.server.store.derby.AbstractDerbyMessageStore.checkMessageStoreOpen(AbstractDerbyMessageStore.java:117)
> at 
> org.apache.qpid.server.store.derby.DerbyMessageStore.getConnection(DerbyMessageStore.java:57)
> at 
> org.apache.qpid.server.virtualhost.derby.DerbyVirtualHostImpl.getConnection(DerbyVirtualHostImpl.java:111)
> at 
> org.apache.qpid.server.protocol.v1_0.store.jdbc.JDBCLinkStore.getConnection(JDBCLinkStore.java:224)
> at 
> org.apache.qpid.server.protocol.v1_0.store.jdbc.JDBCLinkStore.doDelete(JDBCLinkStore.java:189)
> at 
> org.apache.qpid.server.protocol.v1_0.store.AbstractLinkStore.delete(AbstractLinkStore.java:122)
> at 
> org.apache.qpid.server.protocol.v1_0.LinkRegistryImpl.delete(LinkRegistryImpl.java:136)
> at 
> org.apache.qpid.server.virtualhost.AbstractVirtualHost$13.run(AbstractVirtualHost.java:2233)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2587)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2628)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2624)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2623)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:392)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:175)
> at 
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at 
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at 
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
> at 
> com.google.common.util.concurrent.SettableFuture.set(SettableFuture.java:53)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$2$1.onSuccess(AbstractConfiguredObject.java:641)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2628)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2624)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2623)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:392)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:175)
> at 
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at 
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
>

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

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


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

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

Commit 4f43a9bc760574639311f0ad773105c7dde879ae 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=4f43a9b ]

QPID-7434: [Java Broker] Remove invalid test


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



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

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

70 matches

Mail list logo