[jira] [Commented] (PROTON-1275) [proton-j] [reactor] socket connection interrupt causes unhandled IllegalArgumentException

2016-08-25 Thread James Birdsall (JIRA)

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

James Birdsall commented on PROTON-1275:


I got a chance to pull down your change and try it out today. The exception was 
never a deterministic repro, but after running for most of an hour and not 
seeing anything, I think this fix is good.

Thanks!



> [proton-j] [reactor] socket connection interrupt causes unhandled 
> IllegalArgumentException
> --
>
> Key: PROTON-1275
> URL: https://issues.apache.org/jira/browse/PROTON-1275
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.13.0
> Environment: Windows 10
>Reporter: James Birdsall
>Assignee: Robbie Gemmell
>Priority: Minor
> Fix For: 0.15.0
>
>
> IOHandler.handleBound() is trying to make an outbound connection and catches 
> an IOException. handleBound() then tries to clean up, but the cleanup appears 
> to assume that some traffic actually occurred, whereas in our case the socket 
> didn't even connect. This assumption becomes a problem on the last line of 
> the cleanup:
> bq.{{transport.pop(transport.pending());   // Force generation of 
> TRANSPORT_HEAD_CLOSE (not in C code)}}
> ...because transport.pending() returns -1, and that -1 eventually becomes the 
> argument to a call to ByteBuffer.position() and ta da! 
> IllegalArgumentException.
> I worked around the problem for the moment by protecting the call to pop():
> bq.{{if (transport.pending() >= 0) { transport.pop(transport.pending()); }}}
> ...and that seems to work fine. The rest of the cleanup may not be necessary 
> in that particular circumstance but it doesn't seem to do any harm either.
> I did the investigation using a copy of qpid-proton master that I grabbed 
> from github last week, so the line numbers should be pretty close to current.
> The call stack from the original IOException, for reference. Reading the docs 
> on ClosedByInterruptException, it doesn't sound like something that's likely 
> to happen often. It may be happening to me due to bugs elsewhere in our code. 
> I'm reporting it despite that because, regardless of why this condition 
> occurs, when it happens the path between the connection attempt being 
> interrupted and the unhandled exception is entirely within the Proton-J 
> codebase - it's up to Proton-J to defend itself against this occurrence.
> {quote}
> java.nio.channels.ClosedByInterruptException
> at java.nio.channels.spi.AbstractInterruptibleChannel.end(Unknown Source)
> at sun.nio.ch.SocketChannelImpl.connect(Unknown Source)
> at 
> org.apache.qpid.proton.reactor.impl.IOHandler.handleBound(IOHandler.java:155)
> at 
> org.apache.qpid.proton.reactor.impl.IOHandler.onUnhandled(IOHandler.java:375)
> at 
> org.apache.qpid.proton.engine.BaseHandler.onConnectionBound(BaseHandler.java:58)
> at org.apache.qpid.proton.engine.BaseHandler.handle(BaseHandler.java:131)
> at org.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:108)
> at 
> org.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:307)
> at 
> org.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:276)
> at 
> com.microsoft.azure.servicebus.MessagingFactory$RunReactor.run(MessagingFactory.java:355)
> at java.lang.Thread.run(Unknown Source)
> {quote}
> Call stack from the IllegalArgumentException, showing the location of the 
> fatal call to ByteBuffer.position(-1).
> {quote}
> java.nio.Buffer.position(Unknown Source)
> org.apache.qpid.proton.engine.impl.ssl.SimpleSslTransportWrapper.pop(SimpleSslTransportWrapper.java:413)
> org.apache.qpid.proton.engine.impl.ssl.SslImpl$UnsecureClientAwareTransportWrapper.pop(SslImpl.java:185)
> org.apache.qpid.proton.engine.impl.TransportImpl.pop(TransportImpl.java:1476)
> org.apache.qpid.proton.reactor.impl.IOHandler.handleBound(IOHandler.java:164)
> org.apache.qpid.proton.reactor.impl.IOHandler.onUnhandled(IOHandler.java:372)
> org.apache.qpid.proton.engine.BaseHandler.onConnectionBound(BaseHandler.java:58)
> org.apache.qpid.proton.engine.BaseHandler.handle(BaseHandler.java:131)
> org.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:108)
> org.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:307)
> org.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:276)
> com.microsoft.azure.servicebus.MessagingFactory$RunReactor.run(MessagingFactory.java:355)
> {quote}



--
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-1291) calling close again on a closed endpoints marks it modified and emits the related event again

2016-08-25 Thread ASF subversion and git services (JIRA)

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

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

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

PROTON-1291 Check local state on open / close calls

When open or close is called on an endpoint, check that the state
doesn't already reflect the request to avoid marking the endpoint as
modified when it shouldn't be

> calling close again on a closed endpoints marks it modified and emits the 
> related event again
> -
>
> Key: PROTON-1291
> URL: https://issues.apache.org/jira/browse/PROTON-1291
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.14.0
>Reporter: Robbie Gemmell
> Fix For: 0.15.0
>
>
> The trigger for noticing PROTON-1290 was that the endpoint was unexpectedly 
> marked modified after being closed a second time, with the related close 
> event also emitted a second time. Neither should occur in this 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] [Commented] (PROTON-1224) Proton-J SSL uses deprecated Bouncy Castle functionality

2016-08-25 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on PROTON-1224:


Github user JemDay commented on the issue:

https://github.com/apache/qpid-proton/pull/79
  
Robbie

Thanks, i've taken a quick look and nothing leaps out at me, i'll try 
pulling this down and checking locally. I will try and get to this today but it 
might stretch to tomorrow.

I'd also like to discuss off-line another enhancement we'd like to make 
whereby we can provide/inject an SSLContext directly - this is the way we can 
conform with our in-house security constraints and mechanisms.

Jem..


> Proton-J SSL uses deprecated Bouncy Castle functionality
> 
>
> Key: PROTON-1224
> URL: https://issues.apache.org/jira/browse/PROTON-1224
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: 0.12.2
>Reporter: Jem Day
>
> The BouncyCastle project deprecated functionality used by the proton-j driver 
> in version 1.48. This causes run-time issues for us as our application 
> containers are using newer BC versions.
> Thanks for you patience with this, hopefully this is now cleaner PR, I have 
> closed the original PR #75
> Jem



--
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 issue #79: PROTON-1224: support newer BouncyCastle versions

2016-08-25 Thread JemDay
Github user JemDay commented on the issue:

https://github.com/apache/qpid-proton/pull/79
  
Robbie

Thanks, i've taken a quick look and nothing leaps out at me, i'll try 
pulling this down and checking locally. I will try and get to this today but it 
might stretch to tomorrow.

I'd also like to discuss off-line another enhancement we'd like to make 
whereby we can provide/inject an SSLContext directly - this is the way we can 
conform with our in-house security constraints and mechanisms.

Jem..


---
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] [Comment Edited] (QPID-7400) Allow Proton 0.14 to be used without warning

2016-08-25 Thread Justin Ross (JIRA)

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

Justin Ross edited comment on QPID-7400 at 8/25/16 7:05 PM:


Reviewed by me.  Approved for 1.35.0.


was (Author: justi9):
Reviewed by me.  Approved for 0.14.0.

> Allow Proton 0.14 to be used without warning
> 
>
> Key: QPID-7400
> URL: https://issues.apache.org/jira/browse/QPID-7400
> Project: Qpid
>  Issue Type: Improvement
>Affects Versions: 1.35
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 1.35
>
>
> Proton 0.14 has been released, and built and tested with qpid-cpp 1.35 
> without problem. So qpid-cpp should not warn on this version of Proton any 
> longer.



--
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-7400) Allow Proton 0.14 to be used without warning

2016-08-25 Thread ASF subversion and git services (JIRA)

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

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

Commit 722a69beed99ad0dc29ccde1a0dee4059be86c44 in qpid-cpp's branch 
refs/heads/1.35.x from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=722a69b ]

QPID-7400: Allow Proton 0.14 to be used without warning.


> Allow Proton 0.14 to be used without warning
> 
>
> Key: QPID-7400
> URL: https://issues.apache.org/jira/browse/QPID-7400
> Project: Qpid
>  Issue Type: Improvement
>Affects Versions: 1.35
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 1.35
>
>
> Proton 0.14 has been released, and built and tested with qpid-cpp 1.35 
> without problem. So qpid-cpp should not warn on this version of Proton any 
> longer.



--
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-7400) Allow Proton 0.14 to be used without warning

2016-08-25 Thread ASF subversion and git services (JIRA)

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

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

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

QPID-7400: Allow Proton 0.14 to be used without warning.


> Allow Proton 0.14 to be used without warning
> 
>
> Key: QPID-7400
> URL: https://issues.apache.org/jira/browse/QPID-7400
> Project: Qpid
>  Issue Type: Improvement
>Affects Versions: 1.35
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 1.35
>
>
> Proton 0.14 has been released, and built and tested with qpid-cpp 1.35 
> without problem. So qpid-cpp should not warn on this version of Proton any 
> longer.



--
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-7400) Allow Proton 0.14 to be used without warning

2016-08-25 Thread Andrew Stitcher (JIRA)
Andrew Stitcher created QPID-7400:
-

 Summary: Allow Proton 0.14 to be used without warning
 Key: QPID-7400
 URL: https://issues.apache.org/jira/browse/QPID-7400
 Project: Qpid
  Issue Type: Improvement
Affects Versions: 1.35
Reporter: Andrew Stitcher
Assignee: Andrew Stitcher
 Fix For: 1.35


Proton 0.14 has been released, and built and tested with qpid-cpp 1.35 without 
problem. So qpid-cpp should not warn on this version of Proton any longer.



--
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-1291) calling close again on a closed endpoints marks it modified and emits the related event again

2016-08-25 Thread Robbie Gemmell (JIRA)
Robbie Gemmell created PROTON-1291:
--

 Summary: calling close again on a closed endpoints marks it 
modified and emits the related event again
 Key: PROTON-1291
 URL: https://issues.apache.org/jira/browse/PROTON-1291
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Affects Versions: 0.14.0
Reporter: Robbie Gemmell
 Fix For: 0.15.0


The trigger for noticing PROTON-1290 was that the endpoint was unexpectedly 
marked modified after being closed a second time, with the related close event 
also emitted a second time. Neither should occur in this 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] [Commented] (PROTON-1224) Proton-J SSL uses deprecated Bouncy Castle functionality

2016-08-25 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on PROTON-1224:


Github user gemmellr commented on the issue:

https://github.com/apache/qpid-proton/pull/79
  
@JemDay I've made some updates to your patch, if youd like to give things a 
look over and try out and let me know how you get on that would be good, then I 
can merge it (might squash things first, left them separate for now).


> Proton-J SSL uses deprecated Bouncy Castle functionality
> 
>
> Key: PROTON-1224
> URL: https://issues.apache.org/jira/browse/PROTON-1224
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: 0.12.2
>Reporter: Jem Day
>
> The BouncyCastle project deprecated functionality used by the proton-j driver 
> in version 1.48. This causes run-time issues for us as our application 
> containers are using newer BC versions.
> Thanks for you patience with this, hopefully this is now cleaner PR, I have 
> closed the original PR #75
> Jem



--
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 issue #79: PROTON-1224: support newer BouncyCastle versions

2016-08-25 Thread gemmellr
Github user gemmellr commented on the issue:

https://github.com/apache/qpid-proton/pull/79
  
@JemDay I've made some updates to your patch, if youd like to give things a 
look over and try out and let me know how you get on that would be good, then I 
can merge it (might squash things first, left them separate for now).


---
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-1224) Proton-J SSL uses deprecated Bouncy Castle functionality

2016-08-25 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on PROTON-1224:


GitHub user gemmellr opened a pull request:

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

PROTON-1224: support newer BouncyCastle versions

Update based on PR #78

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

$ git pull https://github.com/gemmellr/qpid-proton bouncycastle-update

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

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


commit 0642fa59caa0e62bb19485b83248ca65d91e213f
Author: Jem Day 
Date:   2016-08-22T20:37:39Z

PROTON-1224: Support newer BouncyCastle Implementations

Support new version of BouncyCastle library via existing reflection
mechanism.
Added Unit-tests

commit 24873ebd1191af7b03937fa93329458c69eb80b7
Author: Robert Gemmell 
Date:   2016-08-25T14:48:06Z

PROTON-1224: rework loading of bouncycastle to ensure failure is detected, 
but suppressed since its optional, and actually reported at the point usage 
would fail. Fix up various whitespace etc issues.




> Proton-J SSL uses deprecated Bouncy Castle functionality
> 
>
> Key: PROTON-1224
> URL: https://issues.apache.org/jira/browse/PROTON-1224
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: 0.12.2
>Reporter: Jem Day
>
> The BouncyCastle project deprecated functionality used by the proton-j driver 
> in version 1.48. This causes run-time issues for us as our application 
> containers are using newer BC versions.
> Thanks for you patience with this, hopefully this is now cleaner PR, I have 
> closed the original PR #75
> Jem



--
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 #79: PROTON-1224: support newer BouncyCastle versio...

2016-08-25 Thread gemmellr
GitHub user gemmellr opened a pull request:

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

PROTON-1224: support newer BouncyCastle versions

Update based on PR #78

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

$ git pull https://github.com/gemmellr/qpid-proton bouncycastle-update

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

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


commit 0642fa59caa0e62bb19485b83248ca65d91e213f
Author: Jem Day 
Date:   2016-08-22T20:37:39Z

PROTON-1224: Support newer BouncyCastle Implementations

Support new version of BouncyCastle library via existing reflection
mechanism.
Added Unit-tests

commit 24873ebd1191af7b03937fa93329458c69eb80b7
Author: Robert Gemmell 
Date:   2016-08-25T14:48:06Z

PROTON-1224: rework loading of bouncycastle to ensure failure is detected, 
but suppressed since its optional, and actually reported at the point usage 
would fail. Fix up various whitespace etc issues.




---
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] (QPIDJMS-201) Consumer handling of no drain response can unsubscribe a durable subscription

2016-08-25 Thread ASF subversion and git services (JIRA)

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

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

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

QPIDJMS-201 disabling the new tests due to instability

Tests unstable due to issue resolved in PROTON-1290 which suppresses
flow frames from being emitted when they shouldn't.  

> Consumer handling of no drain response can unsubscribe a durable subscription
> -
>
> Key: QPIDJMS-201
> URL: https://issues.apache.org/jira/browse/QPIDJMS-201
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.10.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.11.0
>
>
> When a MessageConsumer fails to receive a response to a drain request it 
> closes the consumer instance which triggers the link to be closed, if that 
> happens to be a consumer on a durable subscription it also results in the 
> subscription being unsubscribed.  The handler needs to detach the receiver in 
> this case instead of closing it.  



--
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-6982) [Java Broker] Refactor VirtualHost to remove unnecessary methods

2016-08-25 Thread Alex Rudyy (JIRA)

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

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

> [Java Broker] Refactor VirtualHost to remove unnecessary methods
> 
>
> Key: QPID-6982
> URL: https://issues.apache.org/jira/browse/QPID-6982
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> There are a number of methods on VirtualHost that are unused or would be 
> better moved to other interfaces (e.g. removeQueue should removed and callers 
> should call a method on the queue object instead)



--
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-6982) [Java Broker] Refactor VirtualHost to remove unnecessary methods

2016-08-25 Thread ASF subversion and git services (JIRA)

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

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

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

QPID-6982: [Java Broker] Cache await attainment timeout evaluation result in 
order to fix performance degradation

> [Java Broker] Refactor VirtualHost to remove unnecessary methods
> 
>
> Key: QPID-6982
> URL: https://issues.apache.org/jira/browse/QPID-6982
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> There are a number of methods on VirtualHost that are unused or would be 
> better moved to other interfaces (e.g. removeQueue should removed and callers 
> should call a method on the queue object instead)



--
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] [Reopened] (QPID-6982) [Java Broker] Refactor VirtualHost to remove unnecessary methods

2016-08-25 Thread Alex Rudyy (JIRA)

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

Alex Rudyy reopened QPID-6982:
--

The change introduced in commit under revision 
[r1748537|https://svn.apache.org/r1748537] caused performance degradation: 
context variable awaitAttainmentTimeout is evaluated every time when method 
AbstractConfiguredObject#getAwaitAttainmentTimeout() is called from different 
parts of broker including DefaultDestionation#send(..). 



> [Java Broker] Refactor VirtualHost to remove unnecessary methods
> 
>
> Key: QPID-6982
> URL: https://issues.apache.org/jira/browse/QPID-6982
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> There are a number of methods on VirtualHost that are unused or would be 
> better moved to other interfaces (e.g. removeQueue should removed and callers 
> should call a method on the queue object instead)



--
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 51336: PROTON-1287: c++: missing empty() method on message_id, annotation_key

2016-08-25 Thread Gordon Sim


> On Aug. 23, 2016, 4:50 p.m., Andrew Stitcher wrote:
> > proton-c/bindings/cpp/include/proton/message_id.hpp, line 45
> > 
> >
> > This is an actual API change (even if it is a correct one).
> > 
> > Can message_id really be empty?
> 
> Alan Conway wrote:
> No, but it can be missing from the message properties, which is different 
> from being present with 0 or "". If it is missing there's no safe/sensible 
> way to choose a default "empty" value - should it be an empty string or 
> binary, or a 0 integer? Also it is quite valid not to set a correlation_id, 
> which is semantically different from a correlation-id of 0 or "", so we do 
> need to represent "missing value" somehow.
> 
> Andrew Stitcher wrote:
> Ok, I think you actually answered that message_id *can* be empty! It's 
> empty if correlation_id is not set at all.
> 
> In which case this is a bug fix.
> 
> Alan Conway wrote:
> Well technically: message_id can only be one of 4 types, NULL is not one 
> of them. So a message_id cannot be empty, which is why I didn't have it there 
> originally. However it can be *missing* from a message, so adding the "empty" 
> possibility allows us to model that in a natural way which is similar to how 
> C, python etc. model it with empty pn_data_t, NULL, None etc.
> 
> Andrew Stitcher wrote:
> Now we're really getting to quibles!
> 
> I'd say that a correlation_id can't be null (but there might not be one 
> at all) but the type modelling it message_id can be null to model that it 
> isn't present!
> 
> Alan Conway wrote:
> Now we are just agreeing in an argumentative way.

Just to join in the pedantry, both message_id and correlation_id *can* be null. 
The properties section is a list, and a null entry in that list is perfectly 
valid (indeed would be required e.g. if you didn't want to provide a 
correlation-id value but did want to provide a content-type).


- Gordon


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


On Aug. 24, 2016, 3:33 p.m., Alan Conway wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51336/
> ---
> 
> (Updated Aug. 24, 2016, 3:33 p.m.)
> 
> 
> Review request for qpid and Andrew Stitcher.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> Added empty() to scalar_base()
> 
> Moved internal::scalar_base to proton::scalar_base. All it's public member
> functions are part of the public API for proton::scalar, message_id and 
> annotation_key
> so putting the class that contains them in the namespace internal makes that 
> unclear
> and prevents doxygen from documenting them.
> 
> Moved internal::value_base::empty() and type() to proton::value. There's no 
> need for them
> to be on the internal class and they are public API.
> 
> Note all scalar types need empty() because although the restricted types are
> only allowed to be set as specific typesm, they can be missing from a message
> which is represented by empty().
> 
> 
> Diffs
> -
> 
>   proton-c/bindings/cpp/include/proton/annotation_key.hpp 
> c0c8ca6cd4d09a5d1720dd2ac8a16a71f91ab8b3 
>   proton-c/bindings/cpp/include/proton/codec/encoder.hpp 
> 847e0a9f29aba973f96fa06e3268a1bbe063cd53 
>   proton-c/bindings/cpp/include/proton/internal/scalar_base.hpp 
> 2e491d193d604d52b7ec91af510770fc9b4ac66e 
>   proton-c/bindings/cpp/include/proton/message.hpp 
> 3f683f655346293ab6c043c56d9caed47a391b85 
>   proton-c/bindings/cpp/include/proton/message_id.hpp 
> 84f8ab0c28d5afa39e19a78040c0e07fd96b19b9 
>   proton-c/bindings/cpp/include/proton/scalar.hpp 
> ab7cb2a514d697c365cf568b4be7a842ae29aa3e 
>   proton-c/bindings/cpp/include/proton/value.hpp 
> e7e9f7933038c1ba23b5afdbb102d59208e9ea4c 
>   proton-c/bindings/cpp/src/encoder.cpp 
> e718c402a46d5423b70d178c1903b6ad767eeec5 
>   proton-c/bindings/cpp/src/message.cpp 
> ca5f2d5e010f4ffe4bb8bf8b39ed84b6d25db945 
>   proton-c/bindings/cpp/src/message_test.cpp 
> 68205c9a04fe6e1edb2000bcc9091ef02748878f 
>   proton-c/bindings/cpp/src/scalar_base.cpp 
> c005122dedcfabe135bb62fe6c16eafe4da630cb 
>   proton-c/bindings/cpp/src/value.cpp 
> c2232431f9f093e3530342ea5e3680a62737a4c8 
> 
> Diff: https://reviews.apache.org/r/51336/diff/
> 
> 
> Testing
> ---
> 
> ctest -R cpp on f23 clang/gcc 03/11, appveyor, travis
> 
> 
> Thanks,
> 
> Alan Conway
> 
>



[jira] [Resolved] (QPID-7346) [Java Broker] Improve Principals to record their origin

2016-08-25 Thread Alex Rudyy (JIRA)

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

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

Changes look good to me.

> [Java Broker] Improve Principals to record their origin
> ---
>
> Key: QPID-7346
> URL: https://issues.apache.org/jira/browse/QPID-7346
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.1
>
> Attachments: 
> 0001-QPID-7346-Java-Broker-WIP-Save-the-origin-of-a-Princ.patch, 
> reverting-changes-for-principal-databases.diff
>
>
> Currently the broker uses a variety of different Principals (e.g., 
> {{UsernamePrincipal}}, {{GroupPrincipal}}, ...).
> To make (de-)serialisation and future migration to a more sophisticate 
> principal representation easier the principals should capture their origin 
> (e.g., {{OAuth2AuthenticationProvider}}, {{FileBasedGroupProvider}}, ...).



--
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-7352) [Java Broker] Principal serialisation

2016-08-25 Thread Alex Rudyy (JIRA)

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

Alex Rudyy resolved QPID-7352.
--
Resolution: Fixed
  Assignee: (was: Alex Rudyy)

Latest changes have been reviewed with no further comments.

> [Java Broker] Principal serialisation
> -
>
> Key: QPID-7352
> URL: https://issues.apache.org/jira/browse/QPID-7352
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
>
> Implement a Jackson serialiser for Principals and add a corresponding 
> {{AttributeValueConverter}} that takes the serialised form any produces 
> Generic Principals. The serialised form is to include the reference to the 
> AuthenticationProvider (name and type). Group Providers need the 
> corresponding change.
> Update the preference store and preference store recoverer to store the 
> principal's serialised form for {{owner}} and {{visibilityList}}, and recover 
> generic principal objects.



--
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 51336: PROTON-1287: c++: missing empty() method on message_id, annotation_key

2016-08-25 Thread Alan Conway


> On Aug. 23, 2016, 4:50 p.m., Andrew Stitcher wrote:
> > proton-c/bindings/cpp/include/proton/message_id.hpp, line 45
> > 
> >
> > This is an actual API change (even if it is a correct one).
> > 
> > Can message_id really be empty?
> 
> Alan Conway wrote:
> No, but it can be missing from the message properties, which is different 
> from being present with 0 or "". If it is missing there's no safe/sensible 
> way to choose a default "empty" value - should it be an empty string or 
> binary, or a 0 integer? Also it is quite valid not to set a correlation_id, 
> which is semantically different from a correlation-id of 0 or "", so we do 
> need to represent "missing value" somehow.
> 
> Andrew Stitcher wrote:
> Ok, I think you actually answered that message_id *can* be empty! It's 
> empty if correlation_id is not set at all.
> 
> In which case this is a bug fix.
> 
> Alan Conway wrote:
> Well technically: message_id can only be one of 4 types, NULL is not one 
> of them. So a message_id cannot be empty, which is why I didn't have it there 
> originally. However it can be *missing* from a message, so adding the "empty" 
> possibility allows us to model that in a natural way which is similar to how 
> C, python etc. model it with empty pn_data_t, NULL, None etc.
> 
> Andrew Stitcher wrote:
> Now we're really getting to quibles!
> 
> I'd say that a correlation_id can't be null (but there might not be one 
> at all) but the type modelling it message_id can be null to model that it 
> isn't present!

Now we are just agreeing in an argumentative way.


- Alan


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


On Aug. 24, 2016, 3:33 p.m., Alan Conway wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51336/
> ---
> 
> (Updated Aug. 24, 2016, 3:33 p.m.)
> 
> 
> Review request for qpid and Andrew Stitcher.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> Added empty() to scalar_base()
> 
> Moved internal::scalar_base to proton::scalar_base. All it's public member
> functions are part of the public API for proton::scalar, message_id and 
> annotation_key
> so putting the class that contains them in the namespace internal makes that 
> unclear
> and prevents doxygen from documenting them.
> 
> Moved internal::value_base::empty() and type() to proton::value. There's no 
> need for them
> to be on the internal class and they are public API.
> 
> Note all scalar types need empty() because although the restricted types are
> only allowed to be set as specific typesm, they can be missing from a message
> which is represented by empty().
> 
> 
> Diffs
> -
> 
>   proton-c/bindings/cpp/include/proton/annotation_key.hpp 
> c0c8ca6cd4d09a5d1720dd2ac8a16a71f91ab8b3 
>   proton-c/bindings/cpp/include/proton/codec/encoder.hpp 
> 847e0a9f29aba973f96fa06e3268a1bbe063cd53 
>   proton-c/bindings/cpp/include/proton/internal/scalar_base.hpp 
> 2e491d193d604d52b7ec91af510770fc9b4ac66e 
>   proton-c/bindings/cpp/include/proton/message.hpp 
> 3f683f655346293ab6c043c56d9caed47a391b85 
>   proton-c/bindings/cpp/include/proton/message_id.hpp 
> 84f8ab0c28d5afa39e19a78040c0e07fd96b19b9 
>   proton-c/bindings/cpp/include/proton/scalar.hpp 
> ab7cb2a514d697c365cf568b4be7a842ae29aa3e 
>   proton-c/bindings/cpp/include/proton/value.hpp 
> e7e9f7933038c1ba23b5afdbb102d59208e9ea4c 
>   proton-c/bindings/cpp/src/encoder.cpp 
> e718c402a46d5423b70d178c1903b6ad767eeec5 
>   proton-c/bindings/cpp/src/message.cpp 
> ca5f2d5e010f4ffe4bb8bf8b39ed84b6d25db945 
>   proton-c/bindings/cpp/src/message_test.cpp 
> 68205c9a04fe6e1edb2000bcc9091ef02748878f 
>   proton-c/bindings/cpp/src/scalar_base.cpp 
> c005122dedcfabe135bb62fe6c16eafe4da630cb 
>   proton-c/bindings/cpp/src/value.cpp 
> c2232431f9f093e3530342ea5e3680a62737a4c8 
> 
> Diff: https://reviews.apache.org/r/51336/diff/
> 
> 
> Testing
> ---
> 
> ctest -R cpp on f23 clang/gcc 03/11, appveyor, travis
> 
> 
> Thanks,
> 
> Alan Conway
> 
>