[jira] [Commented] (QPIDJMS-225) Add additional testing for not yet covered code paths and use cases

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

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

QPIDJMS-225  Add additional test coverage

> Add additional testing for not yet covered code paths and use cases
> ---
>
> Key: QPIDJMS-225
> URL: https://issues.apache.org/jira/browse/QPIDJMS-225
> Project: Qpid JMS
>  Issue Type: Task
>  Components: qpid-jms-client
>Affects Versions: 0.11.1
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.20.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (DISPATCH-569) Dispatch does not compile due to new pn_event_type_t enum values.

2016-11-18 Thread Ted Ross (JIRA)

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

Ted Ross commented on DISPATCH-569:
---

Having the explicit list of cases in the switch statement was done deliberately 
so we would know when the API changed and that the list of events needed to be 
re-examined for needed changes in Dispatch.  Rather than add the default, we 
should add in the new events and bump the required Proton version to the 
version in which the new events are added.

> Dispatch does not compile due to new pn_event_type_t enum values.
> -
>
> Key: DISPATCH-569
> URL: https://issues.apache.org/jira/browse/DISPATCH-569
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.8.0
>
>
> pn_event_handler has a switch that explicitly lists every enum value of 
> pn_event_type_t even though most of the cases do nothing. This fails to 
> compile against proton master, which has some new enum values.
> Replace the empty cases with a default: case



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Updated] (PROTON-1356) AMQP go bing is throwing expected (unqualified) identifier

2016-11-18 Thread Ram (JIRA)

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

Ram updated PROTON-1356:

Attachment: usr_include_proton.tgz
qpid.apache.org.tgz

> AMQP go bing is throwing expected (unqualified) identifier
> --
>
> Key: PROTON-1356
> URL: https://issues.apache.org/jira/browse/PROTON-1356
> Project: Qpid Proton
>  Issue Type: Bug
>Reporter: Ram
> Attachments: qpid.apache.org.tgz, usr_include_proton.tgz
>
>
> I am trying to use go wraper for amqp to write qpid-stat in go but when i try 
> to go get i am getting bellow error.
> go get qpid.apache.org/amqp
> golang/src/qpid.apache.org/amqp/types.go:33:9: expected (unqualified) 
> identifier
> I have this version of qpid-proton-c-devel rpm -qa |grep qpid-proton-c-devel
> qpid-proton-c-devel-0.14.0-1.el6.x86_64



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Created] (PROTON-1356) AMQP go bing is throwing expected (unqualified) identifier

2016-11-18 Thread Ram (JIRA)
Ram created PROTON-1356:
---

 Summary: AMQP go bing is throwing expected (unqualified) identifier
 Key: PROTON-1356
 URL: https://issues.apache.org/jira/browse/PROTON-1356
 Project: Qpid Proton
  Issue Type: Bug
Reporter: Ram


I am trying to use go wraper for amqp to write qpid-stat in go but when i try 
to go get i am getting bellow error.

go get qpid.apache.org/amqp

golang/src/qpid.apache.org/amqp/types.go:33:9: expected (unqualified) identifier
I have this version of qpid-proton-c-devel rpm -qa |grep qpid-proton-c-devel
qpid-proton-c-devel-0.14.0-1.el6.x86_64



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Created] (QPIDJMS-225) Add additional testing for not yet covered code paths and use cases

2016-11-18 Thread Timothy Bish (JIRA)
Timothy Bish created QPIDJMS-225:


 Summary: Add additional testing for not yet covered code paths and 
use cases
 Key: QPIDJMS-225
 URL: https://issues.apache.org/jira/browse/QPIDJMS-225
 Project: Qpid JMS
  Issue Type: Task
  Components: qpid-jms-client
Affects Versions: 0.11.1
Reporter: Timothy Bish
Assignee: Timothy Bish
 Fix For: 0.20.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Resolved] (QPIDJMS-224) QueueSender calls incorrect superclass send method

2016-11-18 Thread Timothy Bish (JIRA)

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

Timothy Bish resolved QPIDJMS-224.
--
Resolution: Fixed

> QueueSender calls incorrect superclass send method
> --
>
> Key: QPIDJMS-224
> URL: https://issues.apache.org/jira/browse/QPIDJMS-224
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.11.1
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.20.0
>
>
> QueueSender implementation calls incorrect send method in the superclass not 
> passing along the provided Queue to send to.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (QPIDJMS-224) QueueSender calls incorrect superclass send method

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

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

QPIDJMS-224 Wrong super send method called in QueueSender

Call the send method with the given Queue to send to.

> QueueSender calls incorrect superclass send method
> --
>
> Key: QPIDJMS-224
> URL: https://issues.apache.org/jira/browse/QPIDJMS-224
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.11.1
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.20.0
>
>
> QueueSender implementation calls incorrect send method in the superclass not 
> passing along the provided Queue to send to.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Created] (QPIDJMS-224) QueueSender calls incorrect superclass send method

2016-11-18 Thread Timothy Bish (JIRA)
Timothy Bish created QPIDJMS-224:


 Summary: QueueSender calls incorrect superclass send method
 Key: QPIDJMS-224
 URL: https://issues.apache.org/jira/browse/QPIDJMS-224
 Project: Qpid JMS
  Issue Type: Bug
  Components: qpid-jms-client
Affects Versions: 0.11.1
Reporter: Timothy Bish
Assignee: Timothy Bish
 Fix For: 0.20.0


QueueSender implementation calls incorrect send method in the superclass not 
passing along the provided Queue to send to.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (QPID-7529) [Java Broker] Implement producer flow control in AMQP 1.0

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 1770435 from [~godfrer] in branch 'java/trunk'
[ https://svn.apache.org/r1770435 ]

QPID-7529 : Log flow control enforcement in AMQP 1.0

> [Java Broker] Implement producer flow control in AMQP 1.0
> -
>
> Key: QPID-7529
> URL: https://issues.apache.org/jira/browse/QPID-7529
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
> Fix For: qpid-java-6.2
>
>
> Implement producer flow control in AMQP 1.0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (QPID-7514) [Java Broker] Do all message delivery processing on the IO threads and remove the QueueRunner

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 1770433 from [~godfrer] in branch 'java/trunk'
[ https://svn.apache.org/r1770433 ]

QPID-7514 : Use context variables for prefetch and batch limit

> [Java Broker] Do all message delivery processing on the IO threads and remove 
> the QueueRunner
> -
>
> Key: QPID-7514
> URL: https://issues.apache.org/jira/browse/QPID-7514
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
> Fix For: qpid-java-6.2
>
>
> Currently message delivery processing is split between the assignment of the 
> message to a subscription (which happens on the incoming IO thread or in a 
> queue runner) and the actual delivery which happens on the IO thread of the 
> receiving client.
> Instead we should move all processing onto the IO threads and remove the 
> complications inherent in having separate threads attempting delivery.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Resolved] (PROTON-1012) Unable to build python-qpid-proton when behind a proxy server

2016-11-18 Thread Ken Giusti (JIRA)

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

Ken Giusti resolved PROTON-1012.

Resolution: Fixed

Starting in 0.16.0 the python source distribution now includes all the 
necessary C files.  Downloading is no longer necessary.

> Unable to build python-qpid-proton when behind a proxy server
> -
>
> Key: PROTON-1012
> URL: https://issues.apache.org/jira/browse/PROTON-1012
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.10
>Reporter: John Villalovos
>Assignee: Ken Giusti
> Fix For: 0.16.0
>
>
> The program is using urlopen() to download the qpid-proton tarball. This 
> doesn't work with proxy servers.
> Can the package use the 'requests' package which supports proxy servers?
> http://docs.python-requests.org/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (DISPATCH-561) Create python program that returns fake management data

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

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

DISPATCH-561 Add support for qdstat and qdmanage


> Create python program that returns fake management data
> ---
>
> Key: DISPATCH-561
> URL: https://issues.apache.org/jira/browse/DISPATCH-561
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Reporter: Ernest Allen
>Assignee: Ernest Allen
> Fix For: 0.8.0
>
>
> To stress the console with various large topologies, a python program that  
> responds to management queries and returns fake management info would be 
> useful.
> The program should:
> - accept connections from a console and respond to GET-MGMT-NODES, QUERY, 
> and METHOD requests and return fake management data.
> - accept management commands to create fake management data 
>  
> Separately, a new version of the console is needed to create the new 
> topologies and send the python program commands.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (PROTON-1345) [python] Avoid hardcoding the list of C files to be compiled in setup.py

2016-11-18 Thread Ken Giusti (JIRA)

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

Ken Giusti commented on PROTON-1345:


technically no - what needs to be done is have setup.py.in be configured by 
cmake to pass the proper sources in.

With PROTON-1330 this becomes almost trivial but not yet done.

> [python] Avoid hardcoding the list of C files to be compiled in setup.py
> 
>
> Key: PROTON-1345
> URL: https://issues.apache.org/jira/browse/PROTON-1345
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.15.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
> Fix For: 0.17.0
>
>
> Remove the hardcoded list of C source files in the setup.py file.  It's easy 
> to forget to update this list, and debugging the resulting tox build failure 
> is tricky.
> Instead have the setup.py discover all the necessary C source files using an 
> regex.  Add an explicit blacklist for those C source files that shouldn't be 
> built by the setup.py process (if there actually is any).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Updated] (PROTON-1345) [python] Avoid hardcoding the list of C files to be compiled in setup.py

2016-11-18 Thread Ken Giusti (JIRA)

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

Ken Giusti updated PROTON-1345:
---
Fix Version/s: (was: 0.16.0)
   0.17.0

> [python] Avoid hardcoding the list of C files to be compiled in setup.py
> 
>
> Key: PROTON-1345
> URL: https://issues.apache.org/jira/browse/PROTON-1345
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.15.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
> Fix For: 0.17.0
>
>
> Remove the hardcoded list of C source files in the setup.py file.  It's easy 
> to forget to update this list, and debugging the resulting tox build failure 
> is tricky.
> Instead have the setup.py discover all the necessary C source files using an 
> regex.  Add an explicit blacklist for those C source files that shouldn't be 
> built by the setup.py process (if there actually is any).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (DISPATCH-553) Add statistic counter to the "log" entity to count log events per severity

2016-11-18 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on DISPATCH-553:
-

GitHub user mgoulish opened a pull request:

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

DISPATCH-553   



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

$ git pull https://github.com/mgoulish/qpid-dispatch master

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

https://github.com/apache/qpid-dispatch/pull/115.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #115


commit ceb9aac6b176c6cdc66f7a04d0572e409eb09393
Author: mick 
Date:   2016-11-03T19:09:12Z

initial attempt at dispatch-553

commit 9ee8c97554795923bad6aea84047ee2ac7af04af
Author: mick 
Date:   2016-11-18T18:12:06Z

Merge branch 'master' of https://github.com/apache/qpid-dispatch




> Add statistic counter to the "log" entity to count log events per severity
> --
>
> Key: DISPATCH-553
> URL: https://issues.apache.org/jira/browse/DISPATCH-553
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Reporter: Ted Ross
>Assignee: michael goulish
> Fix For: 0.8.0
>
>
> Add counters to the "log" entity to count occurrences of log events in each 
> severity.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[GitHub] qpid-dispatch pull request #115: DISPATCH-553

2016-11-18 Thread mgoulish
GitHub user mgoulish opened a pull request:

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

DISPATCH-553   



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

$ git pull https://github.com/mgoulish/qpid-dispatch master

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

https://github.com/apache/qpid-dispatch/pull/115.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #115


commit ceb9aac6b176c6cdc66f7a04d0572e409eb09393
Author: mick 
Date:   2016-11-03T19:09:12Z

initial attempt at dispatch-553

commit 9ee8c97554795923bad6aea84047ee2ac7af04af
Author: mick 
Date:   2016-11-18T18:12:06Z

Merge branch 'master' of https://github.com/apache/qpid-dispatch




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

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



[GitHub] qpid-dispatch pull request #109: initial attempt at dispatch-553

2016-11-18 Thread mgoulish
Github user mgoulish closed the pull request at:

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


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

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



[jira] [Commented] (PROTON-1012) Unable to build python-qpid-proton when behind a proxy server

2016-11-18 Thread Justin Ross (JIRA)

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

Justin Ross commented on PROTON-1012:
-

[~kgiusti], can we consider this resolved?

> Unable to build python-qpid-proton when behind a proxy server
> -
>
> Key: PROTON-1012
> URL: https://issues.apache.org/jira/browse/PROTON-1012
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.10
>Reporter: John Villalovos
>Assignee: Ken Giusti
> Fix For: 0.16.0
>
>
> The program is using urlopen() to download the qpid-proton tarball. This 
> doesn't work with proxy servers.
> Can the package use the 'requests' package which supports proxy servers?
> http://docs.python-requests.org/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Updated] (PROTON-1311) [proton-c] Accessors for max-message-size on link

2016-11-18 Thread Justin Ross (JIRA)

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

Justin Ross updated PROTON-1311:

Assignee: Cliff Jansen

> [proton-c] Accessors for max-message-size on link
> -
>
> Key: PROTON-1311
> URL: https://issues.apache.org/jira/browse/PROTON-1311
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.14.0
>Reporter: Chuck Rolke
>Assignee: Cliff Jansen
> Fix For: 0.16.0
>
>
> A set function for new links is required.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (PROTON-1345) [python] Avoid hardcoding the list of C files to be compiled in setup.py

2016-11-18 Thread Justin Ross (JIRA)

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

Justin Ross commented on PROTON-1345:
-

[~kgiusti], done?

> [python] Avoid hardcoding the list of C files to be compiled in setup.py
> 
>
> Key: PROTON-1345
> URL: https://issues.apache.org/jira/browse/PROTON-1345
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.15.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
> Fix For: 0.16.0
>
>
> Remove the hardcoded list of C source files in the setup.py file.  It's easy 
> to forget to update this list, and debugging the resulting tox build failure 
> is tricky.
> Instead have the setup.py discover all the necessary C source files using an 
> regex.  Add an explicit blacklist for those C source files that shouldn't be 
> built by the setup.py process (if there actually is any).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Updated] (PROTON-1335) [Proton-c] [C++ Bindings] [Visual Studio 2008] Unable to create a binary message

2016-11-18 Thread Justin Ross (JIRA)

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

Justin Ross updated PROTON-1335:

Assignee: Andrew Stitcher  (was: Cliff Jansen)

> [Proton-c] [C++ Bindings] [Visual Studio 2008] Unable to create a binary 
> message
> 
>
> Key: PROTON-1335
> URL: https://issues.apache.org/jira/browse/PROTON-1335
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: 0.14.0
>Reporter: Adel Boutros
>Assignee: Andrew Stitcher
>  Labels: windows
> Fix For: 0.16.0
>
>
> Details can be found here: 
> http://qpid.2158936.n2.nabble.com/Proton-c-0-14-0-C-sending-receiving-bytes-and-map-messages-td7652225.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Updated] (PROTON-1336) [Proton-c 0.14.0][Visual Studio 2013] Failing ssl unit test only in Debug mode

2016-11-18 Thread Justin Ross (JIRA)

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

Justin Ross updated PROTON-1336:

Labels: patch windows  (was: windows)

> [Proton-c 0.14.0][Visual Studio 2013] Failing ssl unit test only in Debug mode
> --
>
> Key: PROTON-1336
> URL: https://issues.apache.org/jira/browse/PROTON-1336
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.14.0
>Reporter: Adel Boutros
>Assignee: Cliff Jansen
>  Labels: patch, windows
> Fix For: 0.16.0
>
>
> check full details here: 
> http://qpid.2158936.n2.nabble.com/Proton-c-0-14-0-Visual-Studio-2013-Failing-ssl-unit-test-only-in-Debug-mode-td7652076.html
> Suggested patch by Cliff is tested and working
> {code}
> --- proton/proton-c/src/windows/io.c2016-08-16 06:02:21 -0700 
> +++ new/proton-c/src/windows/io.c2016-10-19 16:19:21 -0700 
> @@ -90,8 +90,11 @@ 
>  void pn_io_finalize(void *obj) 
>  { 
>pn_io_t *io = (pn_io_t *) obj; 
> -  pn_error_free(io->error); 
> +  pn_selector_t *sel = io->iocp->selector; 
>pn_free(io->iocp); 
> +  if (sel) 
> +pn_decref(sel); 
> +  pn_error_free(io->error); 
>WSACleanup(); 
>  } 
> @@ -366,8 +369,10 @@ 
>  pn_selector_t *pn_io_selector(pn_io_t *io) 
>  { 
> -  if (io->iocp->selector == NULL) 
> +  if (io->iocp->selector == NULL) { 
>  io->iocp->selector = pni_selector_create(io->iocp); 
> +pn_incref(io->iocp->selector); 
> +  } 
>return io->iocp->selector; 
>  } 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Resolved] (PROTON-1351) Introduce proton core library

2016-11-18 Thread Justin Ross (JIRA)

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

Justin Ross resolved PROTON-1351.
-
Resolution: Fixed

> Introduce proton core library
> -
>
> Key: PROTON-1351
> URL: https://issues.apache.org/jira/browse/PROTON-1351
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.16.0
>
>
> Create a proton core library which contains the pure protocol processing 
> logic with no IO logic or code.
> Essentially this is the AMQP processing state machine part of proton-c 
> without any of the socket and OS handling code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Resolved] (PROTON-1350) Rearrange source code to clarify library organisation

2016-11-18 Thread Justin Ross (JIRA)

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

Justin Ross resolved PROTON-1350.
-
Resolution: Done

> Rearrange source code to clarify library organisation
> -
>
> Key: PROTON-1350
> URL: https://issues.apache.org/jira/browse/PROTON-1350
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.16.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Moved] (DISPATCH-571) Driver spins when a listener accepts a socket while FDs are all in use

2016-11-18 Thread Justin Ross (JIRA)

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

Justin Ross moved PROTON-586 to DISPATCH-571:
-

Fix Version/s: (was: 0.16.0)
   0.8.0
Affects Version/s: (was: 0.7)
  Component/s: (was: proton-c)
   Container
 Workflow: QPid Workflow  (was: classic default workflow)
  Key: DISPATCH-571  (was: PROTON-586)
  Project: Qpid Dispatch  (was: Qpid Proton)

> Driver spins when a listener accepts a socket while FDs are all in use
> --
>
> Key: DISPATCH-571
> URL: https://issues.apache.org/jira/browse/DISPATCH-571
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Reporter: Ted Ross
>Assignee: Alan Conway
> Fix For: 0.8.0
>
>
> when operating as a server and using listeners, if the number of open FDs is 
> equal to the limit on FDs, accept will return an error and the driver will 
> spin at 100% cpu until an FD is freed up for the incoming connection.
> Suggested fix:
> If "accept" returns a "too many open files" error (ENFILE or EMFILE), the 
> listening socket should be taken out of the read-fds for a time (say one 
> second) before retrying.
> If this is not practical to do in Proton, the driver should provide hooks for 
> the encapsulating application to use to provide this holdoff.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Closed] (PROTON-1261) Qpid-Proton 0.12.2 unable to open link with Azure when using connection_engine

2016-11-18 Thread Justin Ross (JIRA)

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

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

We'll handle this case in our example and documentation for external SSL 
implementations.

> Qpid-Proton 0.12.2 unable to open link with Azure when using connection_engine
> --
>
> Key: PROTON-1261
> URL: https://issues.apache.org/jira/browse/PROTON-1261
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: 0.12.2
> Environment: Linux
>Reporter: Tobias Duckworth
>Assignee: Alan Conway
>  Labels: workaround
> Fix For: 0.16.0
>
> Attachments: AzureWithQpidProton_FAILonOpenSender.pcapng, 
> AzureWithQpidProton_SUCCESS.pcapng
>
>
> Since proton's built in SSL does not work when running as a connection_engine 
> I used libcurl to achieve an SSL connection.
> I have tested this against a local broker and am able to connect, open 
> sessions, senders and receivers fine.
> However, on connecting to a Microsoft Azure IoTHub I find that whilst I am 
> able to connect and open a session, when attempting to open a sender or 
> receiver the remote (Azure) end immediately closes it again.
> The problem does not occur with a reactor/messenger build of the same 
> program, which uses proton's built in SSL support. However I don't think that 
> the use of internal or external SSL is the cause of the problem. (It's tricky 
> to prove this as I haven't found a way to do the io_reads and io_writes with 
> a reactor build, which is why I'm using connection_engine/socket_engine in 
> the first place - However, I did hack around in connection_options.cpp and 
> convinced ssl_init to get called and found that the connection_engine build 
> fails in the same way when using built in SSL).
> I'll try to attach wireshark traces from both sample programs to this bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (PROTON-1351) Introduce proton core library

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

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

PROTON-1351: [C++ binding] remove dependency on Proton-c url code
- In preparation for moving this to the proton core library
- Improved C++ url tests


> Introduce proton core library
> -
>
> Key: PROTON-1351
> URL: https://issues.apache.org/jira/browse/PROTON-1351
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.16.0
>
>
> Create a proton core library which contains the pure protocol processing 
> logic with no IO logic or code.
> Essentially this is the AMQP processing state machine part of proton-c 
> without any of the socket and OS handling code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Assigned] (QPID-7530) [Java Client] AMQSession_0_8#isQueueExist contains dead code intending to send passive queue declaration when queue is bound to a default exchange and assert flag is set

2016-11-18 Thread Alex Rudyy (JIRA)

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

Alex Rudyy reassigned QPID-7530:


Assignee: Keith Wall  (was: Alex Rudyy)

Keith,
Please review

> [Java Client] AMQSession_0_8#isQueueExist contains dead code intending to 
> send passive queue declaration when queue is bound to a default exchange and 
> assert flag is set to true
> -
>
> Key: QPID-7530
> URL: https://issues.apache.org/jira/browse/QPID-7530
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Affects Versions: qpid-java-6.1
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Trivial
> Fix For: qpid-java-6.2
>
>
> AMQSession_0_8#isQueueExist contains dead code creating FailoverNoopSupport 
> for sending queue declare command which never executed. The code was added 
> when support for address based destinations on 0.8 path was introduced.
> The callback is created when ExchangeBound for default exchange returns 
> positive reply and assert parameter is set to true. The passive queue 
> creation flag is set in FailoverNoopSupport. Execution of FailoverNoopSupport 
> sending passive queue declare for non-existing queue would cause session 
> close by the broker. It seems that passive queue declaration can only fail 
> when queue is deleted between sending of ExchangeBound and  QueueDeclare. 
> Apart from this corner case, the sending of passive queue declare should be 
> successful and client should continue performing its work after receiving of 
> QueueDeclareOk
> It seems that FailoverNoopSupport should be allowed to execute



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Updated] (QPID-7530) [Java Client] AMQSession_0_8#isQueueExist contains dead code intending to send passive queue declaration when queue is bound to a default exchange and assert flag is set t

2016-11-18 Thread Alex Rudyy (JIRA)

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

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

> [Java Client] AMQSession_0_8#isQueueExist contains dead code intending to 
> send passive queue declaration when queue is bound to a default exchange and 
> assert flag is set to true
> -
>
> Key: QPID-7530
> URL: https://issues.apache.org/jira/browse/QPID-7530
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Affects Versions: qpid-java-6.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-6.2
>
>
> AMQSession_0_8#isQueueExist contains dead code creating FailoverNoopSupport 
> for sending queue declare command which never executed. The code was added 
> when support for address based destinations on 0.8 path was introduced.
> The callback is created when ExchangeBound for default exchange returns 
> positive reply and assert parameter is set to true. The passive queue 
> creation flag is set in FailoverNoopSupport. Execution of FailoverNoopSupport 
> sending passive queue declare for non-existing queue would cause session 
> close by the broker. It seems that passive queue declaration can only fail 
> when queue is deleted between sending of ExchangeBound and  QueueDeclare. 
> Apart from this corner case, the sending of passive queue declare should be 
> successful and client should continue performing its work after receiving of 
> QueueDeclareOk
> It seems that FailoverNoopSupport should be allowed to execute



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Assigned] (QPID-7530) [Java Client] AMQSession_0_8#isQueueExist contains dead code intending to send passive queue declaration when queue is bound to a default exchange and assert flag is set

2016-11-18 Thread Alex Rudyy (JIRA)

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

Alex Rudyy reassigned QPID-7530:


Assignee: Alex Rudyy

> [Java Client] AMQSession_0_8#isQueueExist contains dead code intending to 
> send passive queue declaration when queue is bound to a default exchange and 
> assert flag is set to true
> -
>
> Key: QPID-7530
> URL: https://issues.apache.org/jira/browse/QPID-7530
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Affects Versions: qpid-java-6.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-6.2
>
>
> AMQSession_0_8#isQueueExist contains dead code creating FailoverNoopSupport 
> for sending queue declare command which never executed. The code was added 
> when support for address based destinations on 0.8 path was introduced.
> The callback is created when ExchangeBound for default exchange returns 
> positive reply and assert parameter is set to true. The passive queue 
> creation flag is set in FailoverNoopSupport. Execution of FailoverNoopSupport 
> sending passive queue declare for non-existing queue would cause session 
> close by the broker. It seems that passive queue declaration can only fail 
> when queue is deleted between sending of ExchangeBound and  QueueDeclare. 
> Apart from this corner case, the sending of passive queue declare should be 
> successful and client should continue performing its work after receiving of 
> QueueDeclareOk
> It seems that FailoverNoopSupport should be allowed to execute



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (QPID-7530) [Java Client] AMQSession_0_8#isQueueExist contains dead code intending to send passive queue declaration when queue is bound to a default exchange and assert flag is set

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 1770415 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1770415 ]

QPID-7530: Send passive queue declare on checking queue existance if assert 
option in address based destination is set to true

> [Java Client] AMQSession_0_8#isQueueExist contains dead code intending to 
> send passive queue declaration when queue is bound to a default exchange and 
> assert flag is set to true
> -
>
> Key: QPID-7530
> URL: https://issues.apache.org/jira/browse/QPID-7530
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Affects Versions: qpid-java-6.1
>Reporter: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-6.2
>
>
> AMQSession_0_8#isQueueExist contains dead code creating FailoverNoopSupport 
> for sending queue declare command which never executed. The code was added 
> when support for address based destinations on 0.8 path was introduced.
> The callback is created when ExchangeBound for default exchange returns 
> positive reply and assert parameter is set to true. The passive queue 
> creation flag is set in FailoverNoopSupport. Execution of FailoverNoopSupport 
> sending passive queue declare for non-existing queue would cause session 
> close by the broker. It seems that passive queue declaration can only fail 
> when queue is deleted between sending of ExchangeBound and  QueueDeclare. 
> Apart from this corner case, the sending of passive queue declare should be 
> successful and client should continue performing its work after receiving of 
> QueueDeclareOk
> It seems that FailoverNoopSupport should be allowed to execute



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (DISPATCH-561) Create python program that returns fake management data

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

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

DISPATCH-561 Re-enable nexthop calculation optimization


> Create python program that returns fake management data
> ---
>
> Key: DISPATCH-561
> URL: https://issues.apache.org/jira/browse/DISPATCH-561
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Reporter: Ernest Allen
>Assignee: Ernest Allen
> Fix For: 0.8.0
>
>
> To stress the console with various large topologies, a python program that  
> responds to management queries and returns fake management info would be 
> useful.
> The program should:
> - accept connections from a console and respond to GET-MGMT-NODES, QUERY, 
> and METHOD requests and return fake management data.
> - accept management commands to create fake management data 
>  
> Separately, a new version of the console is needed to create the new 
> topologies and send the python program commands.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



Re: Review Request 53876: add explicit sni option

2016-11-18 Thread Alan Conway


> On Nov. 18, 2016, 2:48 p.m., Alan Conway wrote:
> > Do we need the explicit sni setting? i.e. are there use cases where you 
> > really need to set SSL SNI = X and AMQP/SASL host = Y where X != Y? If 
> > there are then ship it. If not then I'd prefer to drop the ssl_sni option 
> > and make virtual_host the One True Fake Hostname for all security purposes. 
> > This story is confusing enough already.
> 
> Alan Conway wrote:
> To justify: I think embedding SSL in proton was a mistake from the get 
> go, in future it should be handled externally, using the user's choice of 
> tools, configured as normal for those tools. Proton should make it easy to 
> integrate by providing access to relevant *AMQP* settings (virtual_host, SASL 
> user/pass etc.) but *not* by exporting random config settings from a 
> randomly-chosen SSL tool (openssl) as part of proton's top-level API. Openssl 
> config is not suitable for windows SSL, the Go TLS stack, native python/ruby 
> SSL etc. I know SNI is common to all SSL stacks, but SSL is not the only 
> encryption layer in the world. I want to get proton back to doing just AMQP 
> and provide extension points to integrate whatever protocol layers the user 
> wants. It's not realistic now so if we need this feature short term go ahead. 
> However someday I will cut the Gordian Knot so I'd like to avoid expanding 
> the amount of pesky non-AMQP config I will have to untangle from the 
> top-level API.
> 
> Robbie Gemmell wrote:
> I think Gordon was trying to account for my mentioning the previous 
> change was altering the existing behaviour in a way that it would no longer 
> be possible to have the connection hostname and SNI hostname details match 
> while changing the AMQP sasl/open host, quite possibly making the python bits 
> act differently from everything else (including the .net client Ken 
> referenced). I agree it would often make sense for them all to be the same, 
> though at that point I'd also tend toward having the connection host match so 
> that you didnt need to set anything else at all.

Let's say C is socket.connect address, A is the AMQP/SASL hostname, S is the 
SSL hostname.
The likely scenarios in my mind are:
- direct connection, working DNS: C = A = S = DNS name
- indirect connection (router) or broken client DNS: C is not the target host, 
or not a name. A = S = DNS (server rarely doesn't have at least a pseudo-DNS 
name)

I can't think of a reason why you would configure the *same service* using 
*different* hostnames for SSL certs, AMQP/SASL and DNS. But I concede I may 
lack imagination.

SHIP IT.


- Alan


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


On Nov. 18, 2016, 3:26 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53876/
> ---
> 
> (Updated Nov. 18, 2016, 3:26 p.m.)
> 
> 
> Review request for qpid, Alan Conway, Chug Rolke, Justin Ross, Kenneth 
> Giusti, and Robbie Gemmell.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> Ulf's fix for https://issues.apache.org/jira/browse/PROTON-1355 allows you to 
> control the sni via the existing virtual host option. For cases where you 
> want the sni to be different from the hostname in the open frame, this patch 
> adds an explicit option.
> 
> 
> Diffs
> -
> 
>   proton-c/bindings/python/proton/reactor.py 3562aa9 
> 
> Diff: https://reviews.apache.org/r/53876/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>



Re: Review Request 53876: add explicit sni option

2016-11-18 Thread Alan Conway

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


Ship it!




Ship It!

- Alan Conway


On Nov. 18, 2016, 3:26 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53876/
> ---
> 
> (Updated Nov. 18, 2016, 3:26 p.m.)
> 
> 
> Review request for qpid, Alan Conway, Chug Rolke, Justin Ross, Kenneth 
> Giusti, and Robbie Gemmell.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> Ulf's fix for https://issues.apache.org/jira/browse/PROTON-1355 allows you to 
> control the sni via the existing virtual host option. For cases where you 
> want the sni to be different from the hostname in the open frame, this patch 
> adds an explicit option.
> 
> 
> Diffs
> -
> 
>   proton-c/bindings/python/proton/reactor.py 3562aa9 
> 
> Diff: https://reviews.apache.org/r/53876/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>



[jira] [Updated] (QPID-7530) [Java Client] AMQSession_0_8#isQueueExist contains dead code intending to send passive queue declaration when queue is bound to a default exchange and assert flag is set t

2016-11-18 Thread Alex Rudyy (JIRA)

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

Alex Rudyy updated QPID-7530:
-
Priority: Trivial  (was: Major)

> [Java Client] AMQSession_0_8#isQueueExist contains dead code intending to 
> send passive queue declaration when queue is bound to a default exchange and 
> assert flag is set to true
> -
>
> Key: QPID-7530
> URL: https://issues.apache.org/jira/browse/QPID-7530
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Affects Versions: qpid-java-6.1
>Reporter: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-6.2
>
>
> AMQSession_0_8#isQueueExist contains dead code creating FailoverNoopSupport 
> for sending queue declare command which never executed. The code was added 
> when support for address based destinations on 0.8 path was introduced.
> The callback is created when ExchangeBound for default exchange returns 
> positive reply and assert parameter is set to true. The passive queue 
> creation flag is set in FailoverNoopSupport. Execution of FailoverNoopSupport 
> sending passive queue declare for non-existing queue would cause session 
> close by the broker. It seems that passive queue declaration can only fail 
> when queue is deleted between sending of ExchangeBound and  QueueDeclare. 
> Apart from this corner case, the sending of passive queue declare should be 
> successful and client should continue performing its work after receiving of 
> QueueDeclareOk
> It seems that FailoverNoopSupport should be allowed to execute



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Created] (QPID-7530) [Java Client] AMQSession_0_8#isQueueExist contains dead code intending to send passive queue declaration when queue is bound to a default exchange and assert flag is set t

2016-11-18 Thread Alex Rudyy (JIRA)
Alex Rudyy created QPID-7530:


 Summary: [Java Client] AMQSession_0_8#isQueueExist contains dead 
code intending to send passive queue declaration when queue is bound to a 
default exchange and assert flag is set to true
 Key: QPID-7530
 URL: https://issues.apache.org/jira/browse/QPID-7530
 Project: Qpid
  Issue Type: Improvement
  Components: Java Client
Affects Versions: qpid-java-6.1
Reporter: Alex Rudyy
 Fix For: qpid-java-6.2


AMQSession_0_8#isQueueExist contains dead code creating FailoverNoopSupport for 
sending queue declare command which never executed. The code was added when 
support for address based destinations on 0.8 path was introduced.
The callback is created when ExchangeBound for default exchange returns 
positive reply and assert parameter is set to true. The passive queue creation 
flag is set in FailoverNoopSupport. Execution of FailoverNoopSupport sending 
passive queue declare for non-existing queue would cause session close by the 
broker. It seems that passive queue declaration can only fail when queue is 
deleted between sending of ExchangeBound and  QueueDeclare. Apart from this 
corner case, the sending of passive queue declare should be successful and 
client should continue performing its work after receiving of QueueDeclareOk

It seems that FailoverNoopSupport should be allowed to execute



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



Re: Review Request 53876: add explicit sni option

2016-11-18 Thread Robbie Gemmell


> On Nov. 18, 2016, 2:48 p.m., Alan Conway wrote:
> > Do we need the explicit sni setting? i.e. are there use cases where you 
> > really need to set SSL SNI = X and AMQP/SASL host = Y where X != Y? If 
> > there are then ship it. If not then I'd prefer to drop the ssl_sni option 
> > and make virtual_host the One True Fake Hostname for all security purposes. 
> > This story is confusing enough already.
> 
> Alan Conway wrote:
> To justify: I think embedding SSL in proton was a mistake from the get 
> go, in future it should be handled externally, using the user's choice of 
> tools, configured as normal for those tools. Proton should make it easy to 
> integrate by providing access to relevant *AMQP* settings (virtual_host, SASL 
> user/pass etc.) but *not* by exporting random config settings from a 
> randomly-chosen SSL tool (openssl) as part of proton's top-level API. Openssl 
> config is not suitable for windows SSL, the Go TLS stack, native python/ruby 
> SSL etc. I know SNI is common to all SSL stacks, but SSL is not the only 
> encryption layer in the world. I want to get proton back to doing just AMQP 
> and provide extension points to integrate whatever protocol layers the user 
> wants. It's not realistic now so if we need this feature short term go ahead. 
> However someday I will cut the Gordian Knot so I'd like to avoid expanding 
> the amount of pesky non-AMQP config I will have to untangle from the 
> top-level API.

I think Gordon was trying to account for my mentioning the previous change was 
altering the existing behaviour in a way that it would no longer be possible to 
have the connection hostname and SNI hostname details match while changing the 
AMQP sasl/open host, quite possibly making the python bits act differently from 
everything else (including the .net client Ken referenced). I agree it would 
often make sense for them all to be the same, though at that point I'd also 
tend toward having the connection host match so that you didnt need to set 
anything else at all.


- Robbie


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


On Nov. 18, 2016, 3:26 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53876/
> ---
> 
> (Updated Nov. 18, 2016, 3:26 p.m.)
> 
> 
> Review request for qpid, Alan Conway, Chug Rolke, Justin Ross, Kenneth 
> Giusti, and Robbie Gemmell.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> Ulf's fix for https://issues.apache.org/jira/browse/PROTON-1355 allows you to 
> control the sni via the existing virtual host option. For cases where you 
> want the sni to be different from the hostname in the open frame, this patch 
> adds an explicit option.
> 
> 
> Diffs
> -
> 
>   proton-c/bindings/python/proton/reactor.py 3562aa9 
> 
> Diff: https://reviews.apache.org/r/53876/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>



[jira] [Commented] (PROTON-1355) Allow controlling peer_hostname independently of connection url

2016-11-18 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on PROTON-1355:


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

https://github.com/apache/qpid-proton/pull/90#discussion_r88679501
  
--- Diff: proton-c/bindings/python/proton/reactor.py ---
@@ -565,7 +565,7 @@ def _connect(self, connection, reactor):
 if not self.ssl_domain:
 raise SSLUnavailable("amqps: SSL libraries not found")
 self.ssl = SSL(transport, self.ssl_domain)
-self.ssl.peer_hostname = url.host
+self.ssl.peer_hostname = self.virtual_host if 
self.virtual_host != None else url.host
--- End diff --

actually you can write it even more clearly ...
... = self.virtual_host or url.host


> Allow controlling peer_hostname independently of connection url
> ---
>
> Key: PROTON-1355
> URL: https://issues.apache.org/jira/browse/PROTON-1355
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: python-binding
>Reporter: Ulf Lilleengen
>Priority: Minor
>
> I've made a patch that sets SSL peer_hostname to virtual_host if set, and 
> falls back to the url hostname if not.
> On 15. nov. 2016 17:38, Alan Conway wrote:
> > On Mon, 2016-11-14 at 23:51 +, Gordon Sim wrote:
> >> > On 14/11/16 14:18, Ulf Lilleengen wrote:
> >>> > > 
> >>> > > I've been playing around with setting Server Name Indication (SNI)
> >>> > >  when using the qpid proton python bindings.
> >>> > > 
> >>> > > For configuring SSL, it seems to be expected that configuration
> >>> > > parameters come from a SSLDomain python object, which maps to the
> >>> > > underlying pn_ssl_domain_t in proton-c.
> >>> > > 
> >>> > > Today, setting SNI is done through the pn_ssl_t instance using
> >>> > > 'pn_ssl_set_peer_hostname'. The pn_ssl_t instance does not seem to
> >>> > > be
> >>> > > exposed in the end APIs in the same way as pn_ssl_domain_t, at
> >>> > > least
> >>> > > not in the python bindings. I tried to work around this in the
> >>> > > python
> >>> > > bindings by passing an extra parameter in addition to the
> >>> > > ssl_domain
> >>> > > instance on connect(), but it didn't seem like a good approach.
> >> > 
> >> > There is already a virtual_host keyword argument for connect(). This
> >> > is 
> >> > used to control the hostname field in the AMQP open frame. That is 
> >> > similar to SNI in TLS. The AMQP spec says:
> >> > 
> >> >  The TLS client peer SHOULD use the server name indication
> >> >  extension as described in RFC-4366 [RFC4366].
> >> > 
> >> >  If it does so, then it is undefined what happens if this
> >> >  differs from hostname in the sasl-init and open frame
> >> >  frames.
> >> > 
> >> > So perhaps using the virtual_host, if specified, for the
> >> > peer_hostname 
> >> > would make sense. (If not specified it could fallback to the hostname
> >> > in 
> >> > the url).
> > I think that is what we did with virtual_host a while back, but I am
> > not sure exactly what was completed and what was discussed. IIRC the
> > discussion was that AMQP hostname/peer_host should be set to
> > virtual_host if that is set, or fall-back to the URL hostname if not.
> > The idea was exactly to avoid the need to muck about with ssl_domains
> > and whatnot, and set the "virtual" hostname in just one



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[GitHub] qpid-proton pull request #90: PROTON-1355: Set ssl.peer_hostname to virtual_...

2016-11-18 Thread astitcher
Github user astitcher commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/90#discussion_r88679501
  
--- Diff: proton-c/bindings/python/proton/reactor.py ---
@@ -565,7 +565,7 @@ def _connect(self, connection, reactor):
 if not self.ssl_domain:
 raise SSLUnavailable("amqps: SSL libraries not found")
 self.ssl = SSL(transport, self.ssl_domain)
-self.ssl.peer_hostname = url.host
+self.ssl.peer_hostname = self.virtual_host if 
self.virtual_host != None else url.host
--- End diff --

actually you can write it even more clearly ...
... = self.virtual_host or url.host


---
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-7529) [Java Broker] Implement producer flow control in AMQP 1.0

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 1770401 from [~lorenz.quack] in branch 'java/trunk'
[ https://svn.apache.org/r1770401 ]

QPID-7529: [Java Broker] fix FlowControl on AMQP 1.0

> [Java Broker] Implement producer flow control in AMQP 1.0
> -
>
> Key: QPID-7529
> URL: https://issues.apache.org/jira/browse/QPID-7529
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
> Fix For: qpid-java-6.2
>
>
> Implement producer flow control in AMQP 1.0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (PROTON-1355) Allow controlling peer_hostname independently of connection url

2016-11-18 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on PROTON-1355:


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

https://github.com/apache/qpid-proton/pull/90#discussion_r88675979
  
--- Diff: proton-c/bindings/python/proton/reactor.py ---
@@ -565,7 +565,7 @@ def _connect(self, connection, reactor):
 if not self.ssl_domain:
 raise SSLUnavailable("amqps: SSL libraries not found")
 self.ssl = SSL(transport, self.ssl_domain)
-self.ssl.peer_hostname = url.host
+self.ssl.peer_hostname = self.virtual_host if 
self.virtual_host != None else url.host
--- End diff --

Agreed. I chose to write it this way to be consistent with the rest of the 
code which seems to explicitly check for None.


> Allow controlling peer_hostname independently of connection url
> ---
>
> Key: PROTON-1355
> URL: https://issues.apache.org/jira/browse/PROTON-1355
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: python-binding
>Reporter: Ulf Lilleengen
>Priority: Minor
>
> I've made a patch that sets SSL peer_hostname to virtual_host if set, and 
> falls back to the url hostname if not.
> On 15. nov. 2016 17:38, Alan Conway wrote:
> > On Mon, 2016-11-14 at 23:51 +, Gordon Sim wrote:
> >> > On 14/11/16 14:18, Ulf Lilleengen wrote:
> >>> > > 
> >>> > > I've been playing around with setting Server Name Indication (SNI)
> >>> > >  when using the qpid proton python bindings.
> >>> > > 
> >>> > > For configuring SSL, it seems to be expected that configuration
> >>> > > parameters come from a SSLDomain python object, which maps to the
> >>> > > underlying pn_ssl_domain_t in proton-c.
> >>> > > 
> >>> > > Today, setting SNI is done through the pn_ssl_t instance using
> >>> > > 'pn_ssl_set_peer_hostname'. The pn_ssl_t instance does not seem to
> >>> > > be
> >>> > > exposed in the end APIs in the same way as pn_ssl_domain_t, at
> >>> > > least
> >>> > > not in the python bindings. I tried to work around this in the
> >>> > > python
> >>> > > bindings by passing an extra parameter in addition to the
> >>> > > ssl_domain
> >>> > > instance on connect(), but it didn't seem like a good approach.
> >> > 
> >> > There is already a virtual_host keyword argument for connect(). This
> >> > is 
> >> > used to control the hostname field in the AMQP open frame. That is 
> >> > similar to SNI in TLS. The AMQP spec says:
> >> > 
> >> >  The TLS client peer SHOULD use the server name indication
> >> >  extension as described in RFC-4366 [RFC4366].
> >> > 
> >> >  If it does so, then it is undefined what happens if this
> >> >  differs from hostname in the sasl-init and open frame
> >> >  frames.
> >> > 
> >> > So perhaps using the virtual_host, if specified, for the
> >> > peer_hostname 
> >> > would make sense. (If not specified it could fallback to the hostname
> >> > in 
> >> > the url).
> > I think that is what we did with virtual_host a while back, but I am
> > not sure exactly what was completed and what was discussed. IIRC the
> > discussion was that AMQP hostname/peer_host should be set to
> > virtual_host if that is set, or fall-back to the URL hostname if not.
> > The idea was exactly to avoid the need to muck about with ssl_domains
> > and whatnot, and set the "virtual" hostname in just one



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[GitHub] qpid-proton pull request #90: PROTON-1355: Set ssl.peer_hostname to virtual_...

2016-11-18 Thread lulf
Github user lulf commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/90#discussion_r88675979
  
--- Diff: proton-c/bindings/python/proton/reactor.py ---
@@ -565,7 +565,7 @@ def _connect(self, connection, reactor):
 if not self.ssl_domain:
 raise SSLUnavailable("amqps: SSL libraries not found")
 self.ssl = SSL(transport, self.ssl_domain)
-self.ssl.peer_hostname = url.host
+self.ssl.peer_hostname = self.virtual_host if 
self.virtual_host != None else url.host
--- End diff --

Agreed. I chose to write it this way to be consistent with the rest of the 
code which seems to explicitly check for None.


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



Re: Review Request 53876: add explicit sni option

2016-11-18 Thread Alan Conway


> On Nov. 18, 2016, 2:48 p.m., Alan Conway wrote:
> > Do we need the explicit sni setting? i.e. are there use cases where you 
> > really need to set SSL SNI = X and AMQP/SASL host = Y where X != Y? If 
> > there are then ship it. If not then I'd prefer to drop the ssl_sni option 
> > and make virtual_host the One True Fake Hostname for all security purposes. 
> > This story is confusing enough already.

To justify: I think embedding SSL in proton was a mistake from the get go, in 
future it should be handled externally, using the user's choice of tools, 
configured as normal for those tools. Proton should make it easy to integrate 
by providing access to relevant *AMQP* settings (virtual_host, SASL user/pass 
etc.) but *not* by exporting random config settings from a randomly-chosen SSL 
tool (openssl) as part of proton's top-level API. Openssl config is not 
suitable for windows SSL, the Go TLS stack, native python/ruby SSL etc. I know 
SNI is common to all SSL stacks, but SSL is not the only encryption layer in 
the world. I want to get proton back to doing just AMQP and provide extension 
points to integrate whatever protocol layers the user wants. It's not realistic 
now so if we need this feature short term go ahead. However someday I will cut 
the Gordian Knot so I'd like to avoid expanding the amount of pesky non-AMQP 
config I will have to untangle from the top-level API.


- Alan


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


On Nov. 18, 2016, 1:58 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53876/
> ---
> 
> (Updated Nov. 18, 2016, 1:58 p.m.)
> 
> 
> Review request for qpid, Alan Conway, Justin Ross, Kenneth Giusti, and Robbie 
> Gemmell.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> Ulf's fix for https://issues.apache.org/jira/browse/PROTON-1355 allows you to 
> control the sni via the existing virtual host option. For cases where you 
> want the sni to be different from the hostname in the open frame, this patch 
> adds an explicit option.
> 
> 
> Diffs
> -
> 
>   proton-c/bindings/python/proton/reactor.py 3562aa9 
> 
> Diff: https://reviews.apache.org/r/53876/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>



Re: Review Request 53876: add explicit sni option

2016-11-18 Thread Kenneth Giusti

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



Looks good to me.

Can you add Chuck Rolke to the reviewer's list?  He's found issues with how 
hostname is used w.r.t. Azure - might be a good idea to have him take a look at 
it (though I doubt it will affect things - better safe than sorry...)

- Kenneth Giusti


On Nov. 18, 2016, 1:58 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53876/
> ---
> 
> (Updated Nov. 18, 2016, 1:58 p.m.)
> 
> 
> Review request for qpid, Alan Conway, Justin Ross, Kenneth Giusti, and Robbie 
> Gemmell.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> Ulf's fix for https://issues.apache.org/jira/browse/PROTON-1355 allows you to 
> control the sni via the existing virtual host option. For cases where you 
> want the sni to be different from the hostname in the open frame, this patch 
> adds an explicit option.
> 
> 
> Diffs
> -
> 
>   proton-c/bindings/python/proton/reactor.py 3562aa9 
> 
> Diff: https://reviews.apache.org/r/53876/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>



Re: Review Request 53876: add explicit sni option

2016-11-18 Thread Alan Conway

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



Do we need the explicit sni setting? i.e. are there use cases where you really 
need to set SSL SNI = X and AMQP/SASL host = Y where X != Y? If there are then 
ship it. If not then I'd prefer to drop the ssl_sni option and make 
virtual_host the One True Fake Hostname for all security purposes. This story 
is confusing enough already.

- Alan Conway


On Nov. 18, 2016, 1:58 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53876/
> ---
> 
> (Updated Nov. 18, 2016, 1:58 p.m.)
> 
> 
> Review request for qpid, Alan Conway, Justin Ross, Kenneth Giusti, and Robbie 
> Gemmell.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> Ulf's fix for https://issues.apache.org/jira/browse/PROTON-1355 allows you to 
> control the sni via the existing virtual host option. For cases where you 
> want the sni to be different from the hostname in the open frame, this patch 
> adds an explicit option.
> 
> 
> Diffs
> -
> 
>   proton-c/bindings/python/proton/reactor.py 3562aa9 
> 
> Diff: https://reviews.apache.org/r/53876/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>



[jira] [Commented] (QPID-7529) [Java Broker] Implement producer flow control in AMQP 1.0

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 1770385 from [~godfrer] in branch 'java/trunk'
[ https://svn.apache.org/r1770385 ]

QPID-7529 : Implement producer flow control in AMQP 1.0

> [Java Broker] Implement producer flow control in AMQP 1.0
> -
>
> Key: QPID-7529
> URL: https://issues.apache.org/jira/browse/QPID-7529
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
> Fix For: qpid-java-6.2
>
>
> Implement producer flow control in AMQP 1.0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Created] (QPID-7529) [Java Broker] Implement producer flow control in AMQP 1.0

2016-11-18 Thread Rob Godfrey (JIRA)
Rob Godfrey created QPID-7529:
-

 Summary: [Java Broker] Implement producer flow control in AMQP 1.0
 Key: QPID-7529
 URL: https://issues.apache.org/jira/browse/QPID-7529
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Rob Godfrey
 Fix For: qpid-java-6.2


Implement producer flow control in AMQP 1.0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



Re: Review Request 53876: add explicit sni option

2016-11-18 Thread Robbie Gemmell

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



Seems good to me.

- Robbie Gemmell


On Nov. 18, 2016, 1:58 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53876/
> ---
> 
> (Updated Nov. 18, 2016, 1:58 p.m.)
> 
> 
> Review request for qpid, Alan Conway, Justin Ross, Kenneth Giusti, and Robbie 
> Gemmell.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> Ulf's fix for https://issues.apache.org/jira/browse/PROTON-1355 allows you to 
> control the sni via the existing virtual host option. For cases where you 
> want the sni to be different from the hostname in the open frame, this patch 
> adds an explicit option.
> 
> 
> Diffs
> -
> 
>   proton-c/bindings/python/proton/reactor.py 3562aa9 
> 
> Diff: https://reviews.apache.org/r/53876/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>



Re: Review Request 53876: add explicit sni option

2016-11-18 Thread Gordon Sim

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

(Updated Nov. 18, 2016, 1:58 p.m.)


Review request for qpid, Alan Conway, Justin Ross, Kenneth Giusti, and Robbie 
Gemmell.


Repository: qpid-proton-git


Description
---

Ulf's fix for https://issues.apache.org/jira/browse/PROTON-1355 allows you to 
control the sni via the existing virtual host option. For cases where you want 
the sni to be different from the hostname in the open frame, this patch adds an 
explicit option.


Diffs (updated)
-

  proton-c/bindings/python/proton/reactor.py 3562aa9 

Diff: https://reviews.apache.org/r/53876/diff/


Testing
---


Thanks,

Gordon Sim



Review Request 53876: add explicit sni option

2016-11-18 Thread Gordon Sim

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

Review request for qpid, Alan Conway, Justin Ross, Kenneth Giusti, and Robbie 
Gemmell.


Repository: qpid-proton-git


Description
---

Ulf's fix for https://issues.apache.org/jira/browse/PROTON-1355 allows you to 
control the sni via the existing virtual host option. For cases where you want 
the sni to be different from the hostname in the open frame, this patch adds an 
explicit option.


Diffs
-

  proton-c/bindings/python/proton/reactor.py 3562aa9 

Diff: https://reviews.apache.org/r/53876/diff/


Testing
---


Thanks,

Gordon Sim



[jira] [Updated] (QPID-7528) Add serializationVersionId to the classes implementing Serializable

2016-11-18 Thread Alex Rudyy (JIRA)

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

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

> Add serializationVersionId to the classes implementing Serializable
> ---
>
> Key: QPID-7528
> URL: https://issues.apache.org/jira/browse/QPID-7528
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.2
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Minor
>
> * The following classes implement Serializable but do not have a 
> serializationVersionId
> ** QpidConnectionFactoryProxy
> ** UnsignedShort
> ** UnsignedLong
> ** StringWriter
> ** UnsignedInteger
> ** UnsignedByte
> ** AuthenticatedPrincipal
> ** UsernamePrincipal
> ** PlainPasswordCallback
> ** GroupPrincipal
> ** DefinedFileServlet
> ** FileServlet
> ** MessageContentServlet
> ** MessageServlet
> ** MetaDataServlet
> ** RestServlet
> ** SaslServlet
> ** StructureServlet
> ** ManagementLogonLogoffReporter
> ** UsernameCachingRMIJRMPServer
> ** AMQConnectionFactory
> ** QpidExchangeOptions
> ** QpidQueueOptions
> ** JCAProvider
> Implement Serializable on Principals not having it implemented as it is a 
> Subject requirement



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Assigned] (QPID-7528) Add serializationVersionId to the classes implementing Serializable

2016-11-18 Thread Alex Rudyy (JIRA)

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

Alex Rudyy reassigned QPID-7528:


Assignee: Keith Wall  (was: Alex Rudyy)

Keith,
Please review the changes

> Add serializationVersionId to the classes implementing Serializable
> ---
>
> Key: QPID-7528
> URL: https://issues.apache.org/jira/browse/QPID-7528
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.2
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Minor
>
> * The following classes implement Serializable but do not have a 
> serializationVersionId
> ** QpidConnectionFactoryProxy
> ** UnsignedShort
> ** UnsignedLong
> ** StringWriter
> ** UnsignedInteger
> ** UnsignedByte
> ** AuthenticatedPrincipal
> ** UsernamePrincipal
> ** PlainPasswordCallback
> ** GroupPrincipal
> ** DefinedFileServlet
> ** FileServlet
> ** MessageContentServlet
> ** MessageServlet
> ** MetaDataServlet
> ** RestServlet
> ** SaslServlet
> ** StructureServlet
> ** ManagementLogonLogoffReporter
> ** UsernameCachingRMIJRMPServer
> ** AMQConnectionFactory
> ** QpidExchangeOptions
> ** QpidQueueOptions
> ** JCAProvider
> Implement Serializable on Principals not having it implemented as it is a 
> Subject requirement



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (QPID-7528) Add serializationVersionId to the classes implementing Serializable

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 1770380 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1770380 ]

QPID-7528: Add serializationVersionId to the classes implementing Serializable

Implements Serializable on implementations of Principal

> Add serializationVersionId to the classes implementing Serializable
> ---
>
> Key: QPID-7528
> URL: https://issues.apache.org/jira/browse/QPID-7528
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.2
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Minor
>
> * The following classes implement Serializable but do not have a 
> serializationVersionId
> ** QpidConnectionFactoryProxy
> ** UnsignedShort
> ** UnsignedLong
> ** StringWriter
> ** UnsignedInteger
> ** UnsignedByte
> ** AuthenticatedPrincipal
> ** UsernamePrincipal
> ** PlainPasswordCallback
> ** GroupPrincipal
> ** DefinedFileServlet
> ** FileServlet
> ** MessageContentServlet
> ** MessageServlet
> ** MetaDataServlet
> ** RestServlet
> ** SaslServlet
> ** StructureServlet
> ** ManagementLogonLogoffReporter
> ** UsernameCachingRMIJRMPServer
> ** AMQConnectionFactory
> ** QpidExchangeOptions
> ** QpidQueueOptions
> ** JCAProvider
> Implement Serializable on Principals not having it implemented as it is a 
> Subject requirement



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[GitHub] qpid-proton pull request #:

2016-11-18 Thread jirkadanek
Github user jirkadanek commented on the pull request:


https://github.com/apache/qpid-proton/commit/a1888591789d3db2ebd6016d7e7d112902e07598#commitcomment-19878499
  
In proton-c/src/messenger/messenger.c:
In proton-c/src/messenger/messenger.c on line 667:
@astitcher btw, we are now at Proton 0.15 and PN_FLAGS_ALLOW_INSECURE_MECHS 
is still the default


---
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] [Assigned] (QPID-7528) Add serializationVersionId to the classes implementing Serializable

2016-11-18 Thread Alex Rudyy (JIRA)

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

Alex Rudyy reassigned QPID-7528:


Assignee: Alex Rudyy

> Add serializationVersionId to the classes implementing Serializable
> ---
>
> Key: QPID-7528
> URL: https://issues.apache.org/jira/browse/QPID-7528
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.2
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Minor
>
> * The following classes implement Serializable but do not have a 
> serializationVersionId
> ** QpidConnectionFactoryProxy
> ** UnsignedShort
> ** UnsignedLong
> ** StringWriter
> ** UnsignedInteger
> ** UnsignedByte
> ** AuthenticatedPrincipal
> ** UsernamePrincipal
> ** PlainPasswordCallback
> ** GroupPrincipal
> ** DefinedFileServlet
> ** FileServlet
> ** MessageContentServlet
> ** MessageServlet
> ** MetaDataServlet
> ** RestServlet
> ** SaslServlet
> ** StructureServlet
> ** ManagementLogonLogoffReporter
> ** UsernameCachingRMIJRMPServer
> ** AMQConnectionFactory
> ** QpidExchangeOptions
> ** QpidQueueOptions
> ** JCAProvider
> Implement Serializable on Principals not having it implemented as it is a 
> Subject requirement



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Updated] (QPID-7528) Add serializationVersionId to the classes implementing Serializable

2016-11-18 Thread Alex Rudyy (JIRA)

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

Alex Rudyy updated QPID-7528:
-
Affects Version/s: qpid-java-6.2
  Component/s: Java Broker

> Add serializationVersionId to the classes implementing Serializable
> ---
>
> Key: QPID-7528
> URL: https://issues.apache.org/jira/browse/QPID-7528
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.2
>Reporter: Alex Rudyy
>Priority: Minor
>
> * The following classes implement Serializable but do not have a 
> serializationVersionId
> ** QpidConnectionFactoryProxy
> ** UnsignedShort
> ** UnsignedLong
> ** StringWriter
> ** UnsignedInteger
> ** UnsignedByte
> ** AuthenticatedPrincipal
> ** UsernamePrincipal
> ** PlainPasswordCallback
> ** GroupPrincipal
> ** DefinedFileServlet
> ** FileServlet
> ** MessageContentServlet
> ** MessageServlet
> ** MetaDataServlet
> ** RestServlet
> ** SaslServlet
> ** StructureServlet
> ** ManagementLogonLogoffReporter
> ** UsernameCachingRMIJRMPServer
> ** AMQConnectionFactory
> ** QpidExchangeOptions
> ** QpidQueueOptions
> ** JCAProvider
> Implement Serializable on Principals not having it implemented as it is a 
> Subject requirement



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Created] (QPID-7528) Add serializationVersionId to the classes implementing Serializable

2016-11-18 Thread Alex Rudyy (JIRA)
Alex Rudyy created QPID-7528:


 Summary: Add serializationVersionId to the classes implementing 
Serializable
 Key: QPID-7528
 URL: https://issues.apache.org/jira/browse/QPID-7528
 Project: Qpid
  Issue Type: Improvement
Reporter: Alex Rudyy
Priority: Minor


* The following classes implement Serializable but do not have a 
serializationVersionId
** QpidConnectionFactoryProxy
** UnsignedShort
** UnsignedLong
** StringWriter
** UnsignedInteger
** UnsignedByte
** AuthenticatedPrincipal
** UsernamePrincipal
** PlainPasswordCallback
** GroupPrincipal
** DefinedFileServlet
** FileServlet
** MessageContentServlet
** MessageServlet
** MetaDataServlet
** RestServlet
** SaslServlet
** StructureServlet
** ManagementLogonLogoffReporter
** UsernameCachingRMIJRMPServer
** AMQConnectionFactory
** QpidExchangeOptions
** QpidQueueOptions
** JCAProvider

Implement Serializable on Principals not having it implemented as it is a 
Subject requirement




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Resolved] (QPID-7519) Remove unnecessary Jetty dependency (jetty-client) from Broker

2016-11-18 Thread Alex Rudyy (JIRA)

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

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

The changes look good to me

> Remove unnecessary Jetty dependency (jetty-client) from Broker
> --
>
> Key: QPID-7519
> URL: https://issues.apache.org/jira/browse/QPID-7519
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.1
>Reporter: Keith Wall
> Fix For: qpid-java-6.2, qpid-java-6.1.1
>
>
> QPID-7300 added support for CORS using Jetty's CORS filter in its 
> implementation.  Jetty's CORS implementation requires jetty-servlets.jar, but 
> jetty-servlets.jar has a transitive dependency on jetty-client.  jetty-client 
> is not actually required to support CORS.
> http://wiki.eclipse.org/Jetty/Feature/Cross_Origin_Filter



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (QPID-7518) [Java Broker] Reduce cost of calculating size of buffered data in NonBlockingConnection

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 1770362 from [~lorenz.quack] in branch 'java/trunk'
[ https://svn.apache.org/r1770362 ]

QPID-7518: [Java Broker] make field variables volatile

> [Java Broker] Reduce cost of calculating size of buffered data in 
> NonBlockingConnection
> ---
>
> Key: QPID-7518
> URL: https://issues.apache.org/jira/browse/QPID-7518
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
> Fix For: qpid-java-6.2
>
>
> Profiling shows that we spend a lot of time iterating over QpidByteBuffers to 
> establish the size of the the buffered data.  We can instead keep track of 
> this as we add buffers and write data through the delegate



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (QPID-7514) [Java Broker] Do all message delivery processing on the IO threads and remove the QueueRunner

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 1770363 from [~lorenz.quack] in branch 'java/trunk'
[ https://svn.apache.org/r1770363 ]

QPID-7514: [Java Broker] Performance optimisation and refactoring

* move isTransportBlockedForWriting check from CreditManagers to 
PendingWorkIterators
* batch ConsumerTarget notifications when highPrefetch is used

> [Java Broker] Do all message delivery processing on the IO threads and remove 
> the QueueRunner
> -
>
> Key: QPID-7514
> URL: https://issues.apache.org/jira/browse/QPID-7514
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
> Fix For: qpid-java-6.2
>
>
> Currently message delivery processing is split between the assignment of the 
> message to a subscription (which happens on the incoming IO thread or in a 
> queue runner) and the actual delivery which happens on the IO thread of the 
> receiving client.
> Instead we should move all processing onto the IO threads and remove the 
> complications inherent in having separate threads attempting delivery.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (PROTON-1355) Allow controlling peer_hostname independently of connection url

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

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

PROTON-1355: Set ssl.peer_hostname to virtual_host if specified


> Allow controlling peer_hostname independently of connection url
> ---
>
> Key: PROTON-1355
> URL: https://issues.apache.org/jira/browse/PROTON-1355
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: python-binding
>Reporter: Ulf Lilleengen
>Priority: Minor
>
> I've made a patch that sets SSL peer_hostname to virtual_host if set, and 
> falls back to the url hostname if not.
> On 15. nov. 2016 17:38, Alan Conway wrote:
> > On Mon, 2016-11-14 at 23:51 +, Gordon Sim wrote:
> >> > On 14/11/16 14:18, Ulf Lilleengen wrote:
> >>> > > 
> >>> > > I've been playing around with setting Server Name Indication (SNI)
> >>> > >  when using the qpid proton python bindings.
> >>> > > 
> >>> > > For configuring SSL, it seems to be expected that configuration
> >>> > > parameters come from a SSLDomain python object, which maps to the
> >>> > > underlying pn_ssl_domain_t in proton-c.
> >>> > > 
> >>> > > Today, setting SNI is done through the pn_ssl_t instance using
> >>> > > 'pn_ssl_set_peer_hostname'. The pn_ssl_t instance does not seem to
> >>> > > be
> >>> > > exposed in the end APIs in the same way as pn_ssl_domain_t, at
> >>> > > least
> >>> > > not in the python bindings. I tried to work around this in the
> >>> > > python
> >>> > > bindings by passing an extra parameter in addition to the
> >>> > > ssl_domain
> >>> > > instance on connect(), but it didn't seem like a good approach.
> >> > 
> >> > There is already a virtual_host keyword argument for connect(). This
> >> > is 
> >> > used to control the hostname field in the AMQP open frame. That is 
> >> > similar to SNI in TLS. The AMQP spec says:
> >> > 
> >> >  The TLS client peer SHOULD use the server name indication
> >> >  extension as described in RFC-4366 [RFC4366].
> >> > 
> >> >  If it does so, then it is undefined what happens if this
> >> >  differs from hostname in the sasl-init and open frame
> >> >  frames.
> >> > 
> >> > So perhaps using the virtual_host, if specified, for the
> >> > peer_hostname 
> >> > would make sense. (If not specified it could fallback to the hostname
> >> > in 
> >> > the url).
> > I think that is what we did with virtual_host a while back, but I am
> > not sure exactly what was completed and what was discussed. IIRC the
> > discussion was that AMQP hostname/peer_host should be set to
> > virtual_host if that is set, or fall-back to the URL hostname if not.
> > The idea was exactly to avoid the need to muck about with ssl_domains
> > and whatnot, and set the "virtual" hostname in just one



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Resolved] (PROTON-1355) Allow controlling peer_hostname independently of connection url

2016-11-18 Thread Gordon Sim (JIRA)

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

Gordon Sim resolved PROTON-1355.

Resolution: Fixed

Thanks Ulf!

> Allow controlling peer_hostname independently of connection url
> ---
>
> Key: PROTON-1355
> URL: https://issues.apache.org/jira/browse/PROTON-1355
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: python-binding
>Reporter: Ulf Lilleengen
>Priority: Minor
>
> I've made a patch that sets SSL peer_hostname to virtual_host if set, and 
> falls back to the url hostname if not.
> On 15. nov. 2016 17:38, Alan Conway wrote:
> > On Mon, 2016-11-14 at 23:51 +, Gordon Sim wrote:
> >> > On 14/11/16 14:18, Ulf Lilleengen wrote:
> >>> > > 
> >>> > > I've been playing around with setting Server Name Indication (SNI)
> >>> > >  when using the qpid proton python bindings.
> >>> > > 
> >>> > > For configuring SSL, it seems to be expected that configuration
> >>> > > parameters come from a SSLDomain python object, which maps to the
> >>> > > underlying pn_ssl_domain_t in proton-c.
> >>> > > 
> >>> > > Today, setting SNI is done through the pn_ssl_t instance using
> >>> > > 'pn_ssl_set_peer_hostname'. The pn_ssl_t instance does not seem to
> >>> > > be
> >>> > > exposed in the end APIs in the same way as pn_ssl_domain_t, at
> >>> > > least
> >>> > > not in the python bindings. I tried to work around this in the
> >>> > > python
> >>> > > bindings by passing an extra parameter in addition to the
> >>> > > ssl_domain
> >>> > > instance on connect(), but it didn't seem like a good approach.
> >> > 
> >> > There is already a virtual_host keyword argument for connect(). This
> >> > is 
> >> > used to control the hostname field in the AMQP open frame. That is 
> >> > similar to SNI in TLS. The AMQP spec says:
> >> > 
> >> >  The TLS client peer SHOULD use the server name indication
> >> >  extension as described in RFC-4366 [RFC4366].
> >> > 
> >> >  If it does so, then it is undefined what happens if this
> >> >  differs from hostname in the sasl-init and open frame
> >> >  frames.
> >> > 
> >> > So perhaps using the virtual_host, if specified, for the
> >> > peer_hostname 
> >> > would make sense. (If not specified it could fallback to the hostname
> >> > in 
> >> > the url).
> > I think that is what we did with virtual_host a while back, but I am
> > not sure exactly what was completed and what was discussed. IIRC the
> > discussion was that AMQP hostname/peer_host should be set to
> > virtual_host if that is set, or fall-back to the URL hostname if not.
> > The idea was exactly to avoid the need to muck about with ssl_domains
> > and whatnot, and set the "virtual" hostname in just one



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Assigned] (QPID-7521) [Java Broker] Close stream in SSLUtil#readPrivateKey

2016-11-18 Thread Alex Rudyy (JIRA)

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

Alex Rudyy reassigned QPID-7521:


Assignee: Alex Rudyy

> [Java Broker] Close stream in SSLUtil#readPrivateKey
> 
>
> Key: QPID-7521
> URL: https://issues.apache.org/jira/browse/QPID-7521
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, 
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-6.2
>
>
>  SSLUtil#readPrivateKey() should close its resources. The particular ones in 
> use do not leak resources but for correctness we should close them anyway.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Updated] (QPID-7521) [Java Broker] Close stream in SSLUtil#readPrivateKey

2016-11-18 Thread Alex Rudyy (JIRA)

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

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

> [Java Broker] Close stream in SSLUtil#readPrivateKey
> 
>
> Key: QPID-7521
> URL: https://issues.apache.org/jira/browse/QPID-7521
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, 
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-6.2
>
>
>  SSLUtil#readPrivateKey() should close its resources. The particular ones in 
> use do not leak resources but for correctness we should close them anyway.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Assigned] (QPID-7521) [Java Broker] Close stream in SSLUtil#readPrivateKey

2016-11-18 Thread Alex Rudyy (JIRA)

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

Alex Rudyy reassigned QPID-7521:


Assignee: Keith Wall  (was: Alex Rudyy)

> [Java Broker] Close stream in SSLUtil#readPrivateKey
> 
>
> Key: QPID-7521
> URL: https://issues.apache.org/jira/browse/QPID-7521
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, 
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Trivial
> Fix For: qpid-java-6.2
>
>
>  SSLUtil#readPrivateKey() should close its resources. The particular ones in 
> use do not leak resources but for correctness we should close them anyway.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (QPID-7508) Broker occasionally fails to report SUB-1003 in response to a consumer that has become suspended

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 1770359 from oru...@apache.org in branch 'java/branches/6.0.x'
[ https://svn.apache.org/r1770359 ]

QPID-7508: [Java Broker] Add changes missed in the previous merge; the changes 
stop the awakening of selector prematurely

> Broker occasionally fails to report SUB-1003 in response to a consumer that 
> has become suspended
> 
>
> Key: QPID-7508
> URL: https://issues.apache.org/jira/browse/QPID-7508
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.2, qpid-java-6.1.1
>
> Attachments: QPID-7508-possible.patch, 
> TEST-org.apache.qpid.server.logging.ConsumerLoggingTest.testSubscriptionSuspend.txt
>
>
> As demonstrated by the following test failure, the Broker is occasionally 
> failing to produce a {{SUB-1003 Suspended for  ms}}.   The issue is 
> being reported on both the 0-9 and 0-10 code paths.
> It seems that the test failure is new and the issue has been exposed by 
> r1765349 (QPID-7447).
> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-MMS-TestMatrix/lastCompletedBuild/jdk=JDK%201.7%20(latest),label=ubuntu,profile=java-mms.0-10/testReport/org.apache.qpid.server.logging/ConsumerLoggingTest/testSubscriptionSuspend/
> {noformat}
> Error Message
> Expected at least two suspension messages, but got 1
> Stacktrace
> junit.framework.AssertionFailedError: Expected at least two suspension 
> messages, but got 1
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.TestCase.assertTrue(TestCase.java:192)
>   at 
> org.apache.qpid.server.logging.ConsumerLoggingTest.testSubscriptionSuspend(ConsumerLoggingTest.java:328)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (QPID-7525) [Java Broker] Invoke attribute methods on initialisation of reporting in Broker

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 1770348 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1770348 ]

QPID-7525: [Java Broker] Invoke attribute methods on initialisation of 
reporting in Broker

> [Java Broker] Invoke attribute methods on initialisation of reporting in 
> Broker
> ---
>
> Key: QPID-7525
> URL: https://issues.apache.org/jira/browse/QPID-7525
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-6.2
>
>
> BrokerImpl#initialiseStatisticsReporting should read 
> STATISTICS_REPORTING_PERIOD as a long



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (QPID-7520) [Java Broker] Improve writing to buffer in BooleanWriter from AMQP 1.0 codec

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 1770347 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1770347 ]

QPID-7520: [Java Broker] Improve writing to buffer in BooleanWriter from AMQP 
1.0 codec

> [Java Broker] Improve writing to buffer in  BooleanWriter from AMQP 1.0 codec 
> --
>
> Key: QPID-7520
> URL: https://issues.apache.org/jira/browse/QPID-7520
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: 0.32, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, 
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1
>Reporter: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-6.2
>
>
> "if" condition in BooleanWriter#writeBuffer is evaluated using operand "&" 
> instead of "&&" which is not really required by the implementation logic. It 
> seems a "typo".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (QPID-7522) [Java Broker] Fix state check in ReplicatedEnvironmentFacade#tryToRestartEnvironment

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 1770352 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1770352 ]

QPID-7522: [Java Broker] Fix state check in 
ReplicatedEnvironmentFacade#tryToRestartEnvironment

> [Java Broker] Fix state check in  
> ReplicatedEnvironmentFacade#tryToRestartEnvironment
> -
>
> Key: QPID-7522
> URL: https://issues.apache.org/jira/browse/QPID-7522
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, 
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1, 
> qpid-java-6.2
>Reporter: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-6.2
>
>
> ReplicatedEnvironmentFacade#tryToRestartEnvironment calls 
> {{_state.equals(State.RESTARTING)}} but it should be 
> {{_state.get().equals(State.RESTARTING)}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (QPID-7526) [Tests] Always invoke super.setUp and super.tearDown from test setUp() and tearDown accordingly

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 1770346 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1770346 ]

QPID-7526: Test should call super.setUp() and super.tearDown() from their setUp 
and tearDown methods accordingly

> [Tests] Always invoke super.setUp and super.tearDown from test setUp() and 
> tearDown accordingly
> ---
>
> Key: QPID-7526
> URL: https://issues.apache.org/jira/browse/QPID-7526
> Project: Qpid
>  Issue Type: Test
>  Components: Java Tests
>Affects Versions: qpid-java-6.2
>Reporter: Alex Rudyy
>
> * The following tests should call super.setUp in their setUp()
> ** ConsumerListTest
> ** PortFactoryTest
> ** PriorityQueueListTest
> ** ReferenceCountingTest
> ** AMQSession_0_8Test
> ** ClassLoadingAwareObjectInputStreamTest
> ** ChartWriterTest
> ** ConfigFileHelperTest
> ** ConfigReaderTest
> ** ConfigWriterTest
> ** ResultsFileWriterTest
> ** SSLTest
> ** BrokerStartupTest
> ** SupportedProtocolVersionsTest
> ** BrokerLoggingTest
> ** ExternalAuthenticationTest
> ** MessageCompressionTest
> ** ManagementLoggingTest
> ** BasicAuthRestTest
> ** CompressedResponsesRestTest
> ** KeyStoreRestTest
> ** TrustStoreRestTest
> ** GroupRestACLTest
> ** UserRestACLTest
> ** BrokerCommandHelperTest
> ** MaxFrameSizeTest
> * AnonymousAuthenticationManagerTest should call their super.tearDown()



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (QPID-7523) [Java Broker] UpgradeFrom7To8#getConfigVersion should guard against NPE in case cursor is null

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 1770351 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1770351 ]

QPID-7523: [Java Broker] UpgradeFrom7To8#getConfigVersion should guard against 
NPE in case cursor is null

> [Java Broker] UpgradeFrom7To8#getConfigVersion should guard against NPE in 
> case cursor is null
> --
>
> Key: QPID-7523
> URL: https://issues.apache.org/jira/browse/QPID-7523
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.32, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, 
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1
>Reporter: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-6.2
>
>
> UpgradeFrom7To8#getConfigVersion should guard against NPE in case cursor is 
> null



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (QPID-7524) [Java Client] New lines should be specified with '%n' in calls to String.format

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 1770353 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1770353 ]

QPID-7524: [Java Client] New lines should be specified with '%n' in calls to 
String.format

> [Java Client] New lines should be specified with '%n' in calls to 
> String.format
> ---
>
> Key: QPID-7524
> URL: https://issues.apache.org/jira/browse/QPID-7524
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Reporter: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-6.2
>
>
>  We should be using {{%n}} instead of {{\n}} when printing (i.e. not part of 
> a protocol but rather user facing output that is platform dependent) for 
> example in {{OptionParser#printHelp}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (QPID-7521) [Java Broker] Close stream in SSLUtil#readPrivateKey

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 1770350 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1770350 ]

QPID-7521: [Java Broker] Close stream in SSLUtil#readPrivateKey

> [Java Broker] Close stream in SSLUtil#readPrivateKey
> 
>
> Key: QPID-7521
> URL: https://issues.apache.org/jira/browse/QPID-7521
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, 
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1
>Reporter: Alex Rudyy
>Priority: Trivial
> Fix For: qpid-java-6.2
>
>
>  SSLUtil#readPrivateKey() should close its resources. The particular ones in 
> use do not leak resources but for correctness we should close them anyway.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (QPID-7527) [Java Broker] ProtocolOutputConverterImpl$CompositeAMQBodyBlock#getSize and ProtocolOutputConverterImpl$SmallCompositeAMQBodyBlock#getSize should cast operands to long t

2016-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 1770349 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1770349 ]

QPID-7527: [Java Broker] ProtocolOutputConverterImpl should cast operands to 
long to avoid truncation to int

> [Java Broker] ProtocolOutputConverterImpl$CompositeAMQBodyBlock#getSize and 
> ProtocolOutputConverterImpl$SmallCompositeAMQBodyBlock#getSize should cast 
> operands to long to avoid truncation to int
> --
>
> Key: QPID-7527
> URL: https://issues.apache.org/jira/browse/QPID-7527
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.32, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, 
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1
>Reporter: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-6.2
>
>
> ProtocolOutputConverterImpl$CompositeAMQBodyBlock#getSize and 
> ProtocolOutputConverterImpl$SmallCompositeAMQBodyBlock#getSize should cast 
> operands to long to avoid truncation to int.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Created] (QPID-7527) [Java Broker] ProtocolOutputConverterImpl$CompositeAMQBodyBlock#getSize and ProtocolOutputConverterImpl$SmallCompositeAMQBodyBlock#getSize should cast operands to long to

2016-11-18 Thread Alex Rudyy (JIRA)
Alex Rudyy created QPID-7527:


 Summary: [Java Broker] 
ProtocolOutputConverterImpl$CompositeAMQBodyBlock#getSize and 
ProtocolOutputConverterImpl$SmallCompositeAMQBodyBlock#getSize should cast 
operands to long to avoid truncation to int
 Key: QPID-7527
 URL: https://issues.apache.org/jira/browse/QPID-7527
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Affects Versions: qpid-java-6.1, qpid-java-6.0.5, qpid-java-6.0.4, 
qpid-java-6.0.3, qpid-java-6.0.2, qpid-java-6.0.1, qpid-java-6.0, 0.32
Reporter: Alex Rudyy
Priority: Minor
 Fix For: qpid-java-6.2


ProtocolOutputConverterImpl$CompositeAMQBodyBlock#getSize and 
ProtocolOutputConverterImpl$SmallCompositeAMQBodyBlock#getSize should cast 
operands to long to avoid truncation to int.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[jira] [Commented] (PROTON-1355) Allow controlling peer_hostname independently of connection url

2016-11-18 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on PROTON-1355:


GitHub user lulf opened a pull request:

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

PROTON-1355: Set ssl.peer_hostname to virtual_host if specified



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

$ git pull https://github.com/lulf/qpid-proton PROTON-1355

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

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


commit d49ab3f96082a29489d2f1fc8880590d74338f68
Author: Ulf Lilleengen 
Date:   2016-11-18T08:52:02Z

PROTON-1355: Set ssl.peer_hostname to virtual_host if specified




> Allow controlling peer_hostname independently of connection url
> ---
>
> Key: PROTON-1355
> URL: https://issues.apache.org/jira/browse/PROTON-1355
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: python-binding
>Reporter: Ulf Lilleengen
>Priority: Minor
>
> I've made a patch that sets SSL peer_hostname to virtual_host if set, and 
> falls back to the url hostname if not.
> On 15. nov. 2016 17:38, Alan Conway wrote:
> > On Mon, 2016-11-14 at 23:51 +, Gordon Sim wrote:
> >> > On 14/11/16 14:18, Ulf Lilleengen wrote:
> >>> > > 
> >>> > > I've been playing around with setting Server Name Indication (SNI)
> >>> > >  when using the qpid proton python bindings.
> >>> > > 
> >>> > > For configuring SSL, it seems to be expected that configuration
> >>> > > parameters come from a SSLDomain python object, which maps to the
> >>> > > underlying pn_ssl_domain_t in proton-c.
> >>> > > 
> >>> > > Today, setting SNI is done through the pn_ssl_t instance using
> >>> > > 'pn_ssl_set_peer_hostname'. The pn_ssl_t instance does not seem to
> >>> > > be
> >>> > > exposed in the end APIs in the same way as pn_ssl_domain_t, at
> >>> > > least
> >>> > > not in the python bindings. I tried to work around this in the
> >>> > > python
> >>> > > bindings by passing an extra parameter in addition to the
> >>> > > ssl_domain
> >>> > > instance on connect(), but it didn't seem like a good approach.
> >> > 
> >> > There is already a virtual_host keyword argument for connect(). This
> >> > is 
> >> > used to control the hostname field in the AMQP open frame. That is 
> >> > similar to SNI in TLS. The AMQP spec says:
> >> > 
> >> >  The TLS client peer SHOULD use the server name indication
> >> >  extension as described in RFC-4366 [RFC4366].
> >> > 
> >> >  If it does so, then it is undefined what happens if this
> >> >  differs from hostname in the sasl-init and open frame
> >> >  frames.
> >> > 
> >> > So perhaps using the virtual_host, if specified, for the
> >> > peer_hostname 
> >> > would make sense. (If not specified it could fallback to the hostname
> >> > in 
> >> > the url).
> > I think that is what we did with virtual_host a while back, but I am
> > not sure exactly what was completed and what was discussed. IIRC the
> > discussion was that AMQP hostname/peer_host should be set to
> > virtual_host if that is set, or fall-back to the URL hostname if not.
> > The idea was exactly to avoid the need to muck about with ssl_domains
> > and whatnot, and set the "virtual" hostname in just one



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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



[GitHub] qpid-proton pull request #90: PROTON-1355: Set ssl.peer_hostname to virtual_...

2016-11-18 Thread lulf
GitHub user lulf opened a pull request:

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

PROTON-1355: Set ssl.peer_hostname to virtual_host if specified



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

$ git pull https://github.com/lulf/qpid-proton PROTON-1355

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

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


commit d49ab3f96082a29489d2f1fc8880590d74338f68
Author: Ulf Lilleengen 
Date:   2016-11-18T08:52:02Z

PROTON-1355: Set ssl.peer_hostname to virtual_host if specified




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

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



[jira] [Created] (PROTON-1355) Allow controlling peer_hostname independently of connection url

2016-11-18 Thread Ulf Lilleengen (JIRA)
Ulf Lilleengen created PROTON-1355:
--

 Summary: Allow controlling peer_hostname independently of 
connection url
 Key: PROTON-1355
 URL: https://issues.apache.org/jira/browse/PROTON-1355
 Project: Qpid Proton
  Issue Type: Improvement
  Components: python-binding
Reporter: Ulf Lilleengen
Priority: Minor


I've made a patch that sets SSL peer_hostname to virtual_host if set, and falls 
back to the url hostname if not.

On 15. nov. 2016 17:38, Alan Conway wrote:
> On Mon, 2016-11-14 at 23:51 +, Gordon Sim wrote:
>> > On 14/11/16 14:18, Ulf Lilleengen wrote:
>>> > > 
>>> > > I've been playing around with setting Server Name Indication (SNI)
>>> > >  when using the qpid proton python bindings.
>>> > > 
>>> > > For configuring SSL, it seems to be expected that configuration
>>> > > parameters come from a SSLDomain python object, which maps to the
>>> > > underlying pn_ssl_domain_t in proton-c.
>>> > > 
>>> > > Today, setting SNI is done through the pn_ssl_t instance using
>>> > > 'pn_ssl_set_peer_hostname'. The pn_ssl_t instance does not seem to
>>> > > be
>>> > > exposed in the end APIs in the same way as pn_ssl_domain_t, at
>>> > > least
>>> > > not in the python bindings. I tried to work around this in the
>>> > > python
>>> > > bindings by passing an extra parameter in addition to the
>>> > > ssl_domain
>>> > > instance on connect(), but it didn't seem like a good approach.
>> > 
>> > There is already a virtual_host keyword argument for connect(). This
>> > is 
>> > used to control the hostname field in the AMQP open frame. That is 
>> > similar to SNI in TLS. The AMQP spec says:
>> > 
>> >  The TLS client peer SHOULD use the server name indication
>> >  extension as described in RFC-4366 [RFC4366].
>> > 
>> >  If it does so, then it is undefined what happens if this
>> >  differs from hostname in the sasl-init and open frame
>> >  frames.
>> > 
>> > So perhaps using the virtual_host, if specified, for the
>> > peer_hostname 
>> > would make sense. (If not specified it could fallback to the hostname
>> > in 
>> > the url).
> I think that is what we did with virtual_host a while back, but I am
> not sure exactly what was completed and what was discussed. IIRC the
> discussion was that AMQP hostname/peer_host should be set to
> virtual_host if that is set, or fall-back to the URL hostname if not.
> The idea was exactly to avoid the need to muck about with ssl_domains
> and whatnot, and set the "virtual" hostname in just one



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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