[jira] [Created] (PROTON-1228) Windows schannel needs default peer_hostname to match OpenSSL

[Cliff Jansen (JIRA)]

Cliff Jansen created PROTON-1228:


 Summary: Windows schannel needs default peer_hostname to match 
OpenSSL
 Key: PROTON-1228
 URL: https://issues.apache.org/jira/browse/PROTON-1228
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.13.0, 0.14.0
 Environment: Windows
Reporter: Cliff Jansen
Assignee: Cliff Jansen
 Fix For: 0.14.0


The OpenSSL module sets a default peer_hostname from the bound connection.  
schannel.c should do the same to behave the same.



--
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] (DISPATCH-358) Intermittent crashes in qdrouterd under load from parallel senders

[Vishal Sharda (JIRA)]

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

Vishal Sharda updated DISPATCH-358:
---
Attachment: Crash_EXTERNAL.png

I started testing again with latest trunk code that has several bug fixes.  I 
enabled SSL between the routers but not between clients and routers.  I got the 
crash in Crash_EXTERNAL.png while starting/stopping clients/router.

> Intermittent crashes in qdrouterd under load from parallel senders
> --
>
> Key: DISPATCH-358
> URL: https://issues.apache.org/jira/browse/DISPATCH-358
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines
>Reporter: Vishal Sharda
>Assignee: Ted Ross
>Priority: Critical
> Attachments: Crash_EXTERNAL.png, Crash_Java_Router_3.png, 
> Crash_Java_Send.png, Crash_Java_free_qd_connection.png, 
> Crash_Java_same_router.png, Crash_Java_same_router_another.png, 
> Crash_Java_same_router_another_bt.png, Crash_SASL.png, Crash_SASL_2.png, 
> Crash_SR_1.png, Crash_SR_2.png, Crash_bt_double_free_Java_RES_266MB.png, 
> Crash_double_free_Java_RES_266MB.png, Crash_free.png, 
> Crash_sasl_server_done.png, Crash_watch_qdstat.png, Overflow_Error.png
>
>
> In my setup of two inter-connected routers, several senders connecting to one 
> router while few receivers connecting to the other router, I see several 
> crashes in the router to which senders connect.  These crashes are 
> intermittent and happen once in every 10 runs or so.  I have collected the 
> backtraces of all the crashes but do not yet have a test case that can 
> reliably reproduce any of them.



--
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] (DISPATCH-371) qdstat and all other clients stopped connecting to interior router

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy closed DISPATCH-371.
--
   Resolution: Not A Bug
 Assignee: Ganesh Murthy
Fix Version/s: 0.6.0

> qdstat and all other clients stopped connecting to interior router
> --
>
> Key: DISPATCH-371
> URL: https://issues.apache.org/jira/browse/DISPATCH-371
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 3 separate machines 
> each
>Reporter: Vishal Sharda
>Assignee: Ganesh Murthy
>Priority: Blocker
> Fix For: 0.6.0
>
>
> I just updated my sandbox to pull the latest bug fixes.  I see that all the 
> routers in my cluster of 3 interior routers have stopped accepting 
> connections from my clients as well as qdstat.
> The port is properly open but qdstat shows the following error:
> *
> vsharda@millennium-qpid-untouched-latest-6443:~/apache-qpid-dispatch/my_build$
>  sudo netstat -tulpn | grep qdrouterd
> tcp0  0 0.0.0.0:56720.0.0.0:*   LISTEN
>   18460/qdrouterd 
> vsharda@millennium-qpid-untouched-latest-6443:~/apache-qpid-dispatch/my_build$
>  qdstat -c
> LinkDetached: sender 427616d4-8253-4bb3-a332-d1940a12f0e3-$management to 
> $management closed due to: Condition('qd:connection-role', 'Link attach 
> forbidden on inter-router connection')
> **
> If I run the router as standalone, I can see qdstat working fine.



--
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] (DISPATCH-372) qdstat should have a timeout command line argument

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy closed DISPATCH-372.
--
   Resolution: Not A Bug
 Assignee: Ganesh Murthy
Fix Version/s: 0.6.0

> qdstat should have a timeout command line argument
> --
>
> Key: DISPATCH-372
> URL: https://issues.apache.org/jira/browse/DISPATCH-372
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: michael goulish
>Assignee: Ganesh Murthy
> Fix For: 0.6.0
>
>
> qdstat should have a timeout command line argument.
> but -- it doesn't.
> sometimes when the router is busy, it is helpful to allow a longer timeout.



--
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-372) qdstat should have a timeout command line argument

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy commented on DISPATCH-372:


Hi Mick, qdstat and qdmanage both have a --timeout command line argument 
already. Please look in 
qpid-dispatch/python/qpid_dispatch_internal/tools/command.py
Thanks

> qdstat should have a timeout command line argument
> --
>
> Key: DISPATCH-372
> URL: https://issues.apache.org/jira/browse/DISPATCH-372
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: michael goulish
>
> qdstat should have a timeout command line argument.
> but -- it doesn't.
> sometimes when the router is busy, it is helpful to allow a longer timeout.



--
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] (DISPATCH-372) qdstat should have a timeout command line argument

[michael goulish (JIRA)]

michael goulish created DISPATCH-372:


 Summary: qdstat should have a timeout command line argument
 Key: DISPATCH-372
 URL: https://issues.apache.org/jira/browse/DISPATCH-372
 Project: Qpid Dispatch
  Issue Type: Improvement
Reporter: michael goulish


qdstat should have a timeout command line argument.
but -- it doesn't.

sometimes when the router is busy, it is helpful to allow a longer timeout.





--
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] (DISPATCH-367) balanced distribution needs to be more... balanced.

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy reassigned DISPATCH-367:
--

Assignee: Ganesh Murthy

> balanced distribution needs to be more... balanced.
> ---
>
> Key: DISPATCH-367
> URL: https://issues.apache.org/jira/browse/DISPATCH-367
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
>Reporter: Ken Giusti
>Assignee: Ganesh Murthy
> Fix For: 0.6.0
>
>
> When blocking sends are done to a balanced address with multiple consumers on 
> the same router all the messages go to one of the consumers.
> I would expect that the messages would be evenly distributed across all 
> _locally_attached_ consumers.



--
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-369) investigate excursions in memory usage

[michael goulish (JIRA)]

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

michael goulish commented on DISPATCH-369:
--

...and without anything interesting showing up in the output from 'qdstat -m'.



> investigate excursions in memory usage
> --
>
> Key: DISPATCH-369
> URL: https://issues.apache.org/jira/browse/DISPATCH-369
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
>Reporter: michael goulish
>Assignee: michael goulish
> Attachments: n_senders_vs_MEM_three_trials.jpg
>
>
> I don't know if this is a bug or not.  I'm Jirifying it as a way of 
> remembering an interesting behavior that my testing has shown, so that I can 
> continue developing the testing and  come back to this later.
> ...
> While measuring router memory usage under varying message rate and number of 
> senders -- when I run the same test multiple times, I am occasionally (about 
> 1 in 4 times or so) seeing a test in which memory usage is much higher than 
> the others.
> For example:
>   In this test:
>   {
> straight-through topology ( 1 sender --> 1 address --> 1 receiver )
> 200 senders
> 200 messages per second
> 100 bytes per message
>   }
> I record router memory usage at the point when all receivers are just hitting 
> 10,000 messages.   (This is because it grows -- see previous JIRA.)
> In three iterations I get the following memory usage:
>66 MB
>63 MB
>   181 MB
> Something similar, but less drastic, happened occasionally at lower levels in 
> the test.  
> In this case, this is a tripling of memory usage for the same scenario.  I 
> doubt that this is the result of slightly  different timing in a block 
> allocation of data structures.  What just happened?
> Start by investigating with "qdstat -m"  and see if that shows some or all of 
> the difference.



--
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] (DISPATCH-366) When delivery fails the router sends the RELEASED disposition, not MODIFIED

[Ted Ross (JIRA)]

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

Ted Ross reassigned DISPATCH-366:
-

Assignee: Ted Ross

> When delivery fails the router sends the RELEASED disposition, not MODIFIED
> ---
>
> Key: DISPATCH-366
> URL: https://issues.apache.org/jira/browse/DISPATCH-366
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
>Reporter: Ken Giusti
>Assignee: Ted Ross
>Priority: Blocker
> Fix For: 0.7.0, 0.6.1
>
>
> The router does not properly distinguish between a delivery failure and 
> undeliverable.
> In the case of a delivery failure - where the router cannot ensure that the 
> message wasn't consumed - the router must send back the MODIFIED terminal 
> disposition with the delivery-failed flag set. This is necessary as the 
> sender must increment the message's delivery-count if it retransmits.
> In the case of an undeliverable message - where the router cannot forward a 
> message to the destination - the router must send back the RELEASED terminal 
> disposition.  RELEASED informs the sender that the message was not acted 
> upon.  The sender must not increment the message's delivery-count if it 
> retransmits.
> Currently the router uses RELEASED in both these cases.



--
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] (DISPATCH-370) qdmanage tool hangs if --type option is "linkRoute" or "address"

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy resolved DISPATCH-370.

   Resolution: Fixed
Fix Version/s: 0.7.0

> qdmanage tool hangs if --type option is "linkRoute" or "address"
> 
>
> Key: DISPATCH-370
> URL: https://issues.apache.org/jira/browse/DISPATCH-370
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
> Fix For: 0.7.0
>
>
> Using qdmanage tool in the following way :
> qdmanage read --type linkRoute
> it doesn't reply with :
> BadRequestStatus: No name or identity provided
> but hangs and then exit for timeout :
> Timeout: Connection amqp://localhost:5672/$management timed out: Waiting for 
> response
> The same happens using "address" as type.



--
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-369) investigate excursions in memory usage

[michael goulish (JIRA)]

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

michael goulish commented on DISPATCH-369:
--

I rebuilt dispatch without the memory pooling feature, expecting that this 
would make the memory blow-ups go away.  It did not!  On the 7th run of my 
test, I saw memory go from 60 MB  (Resident Set Size) to 480 MB between one 
printout of 'top' and the next.  (3 seconds)  -- same behavior I was seeing 
with memory pooling enabled.

> investigate excursions in memory usage
> --
>
> Key: DISPATCH-369
> URL: https://issues.apache.org/jira/browse/DISPATCH-369
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
>Reporter: michael goulish
>Assignee: michael goulish
> Attachments: n_senders_vs_MEM_three_trials.jpg
>
>
> I don't know if this is a bug or not.  I'm Jirifying it as a way of 
> remembering an interesting behavior that my testing has shown, so that I can 
> continue developing the testing and  come back to this later.
> ...
> While measuring router memory usage under varying message rate and number of 
> senders -- when I run the same test multiple times, I am occasionally (about 
> 1 in 4 times or so) seeing a test in which memory usage is much higher than 
> the others.
> For example:
>   In this test:
>   {
> straight-through topology ( 1 sender --> 1 address --> 1 receiver )
> 200 senders
> 200 messages per second
> 100 bytes per message
>   }
> I record router memory usage at the point when all receivers are just hitting 
> 10,000 messages.   (This is because it grows -- see previous JIRA.)
> In three iterations I get the following memory usage:
>66 MB
>63 MB
>   181 MB
> Something similar, but less drastic, happened occasionally at lower levels in 
> the test.  
> In this case, this is a tripling of memory usage for the same scenario.  I 
> doubt that this is the result of slightly  different timing in a block 
> allocation of data structures.  What just happened?
> Start by investigating with "qdstat -m"  and see if that shows some or all of 
> the difference.



--
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-370) qdmanage tool hangs if --type option is "linkRoute" or "address"

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-370 - Added read operation for linkRoute, autoLink, address


> qdmanage tool hangs if --type option is "linkRoute" or "address"
> 
>
> Key: DISPATCH-370
> URL: https://issues.apache.org/jira/browse/DISPATCH-370
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
>
> Using qdmanage tool in the following way :
> qdmanage read --type linkRoute
> it doesn't reply with :
> BadRequestStatus: No name or identity provided
> but hangs and then exit for timeout :
> Timeout: Connection amqp://localhost:5672/$management timed out: Waiting for 
> response
> The same happens using "address" as type.



--
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-1227) Go Client cannot send message in fire-and-forget mode

[Alan Conway (JIRA)]

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

Alan Conway commented on PROTON-1227:
-

I can reproduce it. An interesting one. All the Send methods block for credit 
to avoid unbounded local buffering - that is deliberate and important "good 
practice" for Go. Most AMQP brokers will either give you credit or close your 
attach with a "no such address" error. However for an unsubscribed address, 
dispatch will simply not give you any credit until there are subscribers - it 
is not an error. So even with AtMostOnce or SendForget() the Go API will block 
forever waiting for credit, which is not what you expect.

I need to think about this! At the very least it needs better documentation and 
it might need a change in behavior. You can do what you want with 
SendForgetTimeout() with a short timeout but there might be a better solution, 
forcing the user to choose a timeout is fragile.

> Go Client cannot send message in fire-and-forget mode
> -
>
> Key: PROTON-1227
> URL: https://issues.apache.org/jira/browse/PROTON-1227
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: go-binding
>Affects Versions: 0.14.0
> Environment: RHEL 6.8x
>Reporter: Jiri Danek
>Assignee: Alan Conway
> Attachments: goclientfaf.pcapng, main.go
>
>
> Steps to reproduce: {{go run main.go 127.0.0.1/jms.queue.myqueue}}
> The attached program creates a sender on a at-most-once (a.k.a. 
> fire-and-forget) link. Yet when I Send() a message to qpid-dispatch and have 
> no receiver listening on the same address, the sender timeouts on sending as 
> if it was in at-least-once mode.
> I captured what is happening in the attached packet dump.



--
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-317) Show tooltip for long values on left panel on topology page

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-317: Show a tooltip that contains the full value when mouse is over 
values on the left-hand table on topology page. Also show schema descriptions 
when mouse is over attribute names for the same table.


> Show tooltip for long values on left panel on topology page
> ---
>
> Key: DISPATCH-317
> URL: https://issues.apache.org/jira/browse/DISPATCH-317
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 0.7.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Minor
> Fix For: 0.7.0
>
>
> On the topology page there is a panel on the left side. Long values are 
> truncated. 
> Either enable a horizontal scroll bar in the area or display the full value 
> in a tooltip pop when the mouse moves over 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] (DISPATCH-317) Show tooltip for long values on left panel on topology page

[Ernest Allen (JIRA)]

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

Ernest Allen resolved DISPATCH-317.
---
   Resolution: Fixed
Fix Version/s: 0.7.0

> Show tooltip for long values on left panel on topology page
> ---
>
> Key: DISPATCH-317
> URL: https://issues.apache.org/jira/browse/DISPATCH-317
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 0.7.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Minor
> Fix For: 0.7.0
>
>
> On the topology page there is a panel on the left side. Long values are 
> truncated. 
> Either enable a horizontal scroll bar in the area or display the full value 
> in a tooltip pop when the mouse moves over 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

Re: Review Request 48362: PROTON-1221: c++ container::schedule() support.

[Alan Conway]

> On June 7, 2016, 9:40 p.m., Andrew Stitcher wrote:
> > You need to compile this code with C++03 and fix up the places that end up 
> > needing a feature macro to avoid breakage.
> 
> Alan Conway wrote:
> Yep, known limitation. I need to add C++03 callback support. This is a 
> first cut in C++11 without worrying about that. All your comments will apply 
> to the next cut.
> 
> Quetion: How to organize examples for features that are used differntly 
> in C++03 and C++11?
> 
> - separate c++11/c++03 examples?
> - conditionalized examples that work under both, with different example 
> code chunks selected by #ifdef?
> 
> Clean C++11 examples would be nice. They have to be defined against a 
> specific standard: 11, 14 or 17. We could choose a base standard (11) and use 
> conditional macros for features of 14/17 but I think we should stick to clean 
> c++11 - these are proton examples not C++ tutorials, if we can't write them 
> in C++11 we should rethink the API. That means separate examples (with some 
> redundancy) are needed at least for features that can't be used the same way 
> in C++03 (schedule, inject)
> 
> "Universal" conditionalized examples based on 03, with fake_cpp11.hpp, 
> #if PN_CPP_HAS_STD_FUNCTION etc. : easier for us to maintain, maybe easier 
> for users transitioning from 03 to 11 (side-by-side code) but cluttered for 
> users that are on 11. On the other hand very few of the examples actually 
> *need* C++11 features, so if we do have users stuck on older compilers it's a 
> bit obnoxious to make the base examples uncompilable when they could easily 
> be portable. It really hinges on how many users are in that position.
> 
> A hybrid of the above: conditionalized examples where C++11 and 03 are 
> nearly the same (basically what we have now) and separate examples where they 
> diverge.
> 
> I'm not sure, thoughts?
> 
> Andrew Stitcher wrote:
> We've already decided this:
> 
> The main examples will be C++11 with a separate C++03 directory with the 
> basic examples (about 4 I think, I don't remember exactly which).
> (I think c++11 is sufficient although 14 would bring the convenience of 
> make_unique<>)
> 
> We decided that mt is C++11 only, I don't think we decided this for 
> function injection.
> 
> [Write this down, you seem to keep on forgetting we made this decision!]

Thanks, it is on the list of things I keep forgetting but I can't remember 
where I left it.


> On June 7, 2016, 9:40 p.m., Andrew Stitcher wrote:
> > examples/cpp/scheduled_send.cpp, line 44
> > 
> >
> > Yep that's a good idea, lets add double constructors to duration (just 
> > not as pzrt of this change)
> 
> Alan Conway wrote:
> Agreed, will restrain myself :) I think we need double `op*` rather than 
> constructors to keep the units unambiguous: `duration 
> d(2.0*duration::SECOND)`. A double ctor will still have you doing `duration d 
> (2.0*duration::SECOND.milliseconds())`
> 
> Andrew Stitcher wrote:
> That would be completely unambiguous, but I think that double seconds is 
> pretty unambiguous tbh. `duration d(2.2); // duration of 2.2s`. Having the 
> operator*(double, duration) operator*(duration, double) is still a good idea.

I considered that, but I think it is error-prone if duration(1) and 
duration(1.0) mean different things. Another (less explicit) solution is to 
have `const int64_t duration::SECOND` instead of the constants being 
`duration`: then all the right conversions happen implicitly with the normal 
C++ arithmetic promotion and conversion rules, no need for extra ctor or ops. 
Explicit is probably better though.


> On June 7, 2016, 9:40 p.m., Andrew Stitcher wrote:
> > proton-c/bindings/cpp/include/proton/container.hpp, line 201
> > 
> >
> > Need to add a new feature flag I'll need to look up the actual name, 
> > but PN_CPP_HAS_STD_FUNCTION will do for now.
> 
> Alan Conway wrote:
> See examples question above
> 
> Andrew Stitcher wrote:
> No, this is in a shared header file you *must* put a feature macro in 
> here. Whether the examples are 03 or 11 doesn't matter.

Agreed, over-pasting.


> On June 7, 2016, 9:40 p.m., Andrew Stitcher wrote:
> > examples/cpp/scheduled_send.cpp, line 89
> > 
> >
> > Should the delay here take account of the actual now time?
> > 
> > In other words, are we trying for a fixed frequency or an "at least" 
> > delay?
> 
> Alan Conway wrote:
> For purposes of showing how to use schedule() I don't think it matters - 
> I'll add a comment to clarify this this example is doing a delay *between* 
> sends. Making it fixed frequency would allow us to show the use of now(), so 
> we could do that too.

Got 

[jira] [Commented] (DISPATCH-371) qdstat and all other clients stopped connecting to interior router

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy commented on DISPATCH-371:


Please use different ports. 

> qdstat and all other clients stopped connecting to interior router
> --
>
> Key: DISPATCH-371
> URL: https://issues.apache.org/jira/browse/DISPATCH-371
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 3 separate machines 
> each
>Reporter: Vishal Sharda
>Priority: Blocker
>
> I just updated my sandbox to pull the latest bug fixes.  I see that all the 
> routers in my cluster of 3 interior routers have stopped accepting 
> connections from my clients as well as qdstat.
> The port is properly open but qdstat shows the following error:
> *
> vsharda@millennium-qpid-untouched-latest-6443:~/apache-qpid-dispatch/my_build$
>  sudo netstat -tulpn | grep qdrouterd
> tcp0  0 0.0.0.0:56720.0.0.0:*   LISTEN
>   18460/qdrouterd 
> vsharda@millennium-qpid-untouched-latest-6443:~/apache-qpid-dispatch/my_build$
>  qdstat -c
> LinkDetached: sender 427616d4-8253-4bb3-a332-d1940a12f0e3-$management to 
> $management closed due to: Condition('qd:connection-role', 'Link attach 
> forbidden on inter-router connection')
> **
> If I run the router as standalone, I can see qdstat working fine.



--
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] (DISPATCH-366) When delivery fails the router sends the RELEASED disposition, not MODIFIED

[Ken Giusti (JIRA)]

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

Ken Giusti updated DISPATCH-366:

Fix Version/s: (was: 0.6.0)
   0.7.0
   0.6.1

> When delivery fails the router sends the RELEASED disposition, not MODIFIED
> ---
>
> Key: DISPATCH-366
> URL: https://issues.apache.org/jira/browse/DISPATCH-366
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
>Reporter: Ken Giusti
>Priority: Blocker
> Fix For: 0.7.0, 0.6.1
>
>
> The router does not properly distinguish between a delivery failure and 
> undeliverable.
> In the case of a delivery failure - where the router cannot ensure that the 
> message wasn't consumed - the router must send back the MODIFIED terminal 
> disposition with the delivery-failed flag set. This is necessary as the 
> sender must increment the message's delivery-count if it retransmits.
> In the case of an undeliverable message - where the router cannot forward a 
> message to the destination - the router must send back the RELEASED terminal 
> disposition.  RELEASED informs the sender that the message was not acted 
> upon.  The sender must not increment the message's delivery-count if it 
> retransmits.
> Currently the router uses RELEASED in both these cases.



--
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-371) qdstat and all other clients stopped connecting to interior router

[Vishal Sharda (JIRA)]

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

Vishal Sharda commented on DISPATCH-371:


Hi Ganesh, Can I share the same port between inter-router and normal listeners 
or they have to use different ports?

> qdstat and all other clients stopped connecting to interior router
> --
>
> Key: DISPATCH-371
> URL: https://issues.apache.org/jira/browse/DISPATCH-371
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 3 separate machines 
> each
>Reporter: Vishal Sharda
>Priority: Blocker
>
> I just updated my sandbox to pull the latest bug fixes.  I see that all the 
> routers in my cluster of 3 interior routers have stopped accepting 
> connections from my clients as well as qdstat.
> The port is properly open but qdstat shows the following error:
> *
> vsharda@millennium-qpid-untouched-latest-6443:~/apache-qpid-dispatch/my_build$
>  sudo netstat -tulpn | grep qdrouterd
> tcp0  0 0.0.0.0:56720.0.0.0:*   LISTEN
>   18460/qdrouterd 
> vsharda@millennium-qpid-untouched-latest-6443:~/apache-qpid-dispatch/my_build$
>  qdstat -c
> LinkDetached: sender 427616d4-8253-4bb3-a332-d1940a12f0e3-$management to 
> $management closed due to: Condition('qd:connection-role', 'Link attach 
> forbidden on inter-router connection')
> **
> If I run the router as standalone, I can see qdstat working fine.



--
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] (DISPATCH-370) qdmanage tool hangs if --type option is "linkRoute" or "address"

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy reassigned DISPATCH-370:
--

Assignee: Ganesh Murthy

> qdmanage tool hangs if --type option is "linkRoute" or "address"
> 
>
> Key: DISPATCH-370
> URL: https://issues.apache.org/jira/browse/DISPATCH-370
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
>
> Using qdmanage tool in the following way :
> qdmanage read --type linkRoute
> it doesn't reply with :
> BadRequestStatus: No name or identity provided
> but hangs and then exit for timeout :
> Timeout: Connection amqp://localhost:5672/$management timed out: Waiting for 
> response
> The same happens using "address" as type.



--
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-371) qdstat and all other clients stopped connecting to interior router

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy commented on DISPATCH-371:


Hi Vishal, Your clients are forbidden from communicating to the router on 
inter-router listeners. Listeners with role: inter-router are used exclusively 
for inter-router traffic. Please create new listeners with role : normal and 
have your clients connect to those normal listeners.

> qdstat and all other clients stopped connecting to interior router
> --
>
> Key: DISPATCH-371
> URL: https://issues.apache.org/jira/browse/DISPATCH-371
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 3 separate machines 
> each
>Reporter: Vishal Sharda
>Priority: Blocker
>
> I just updated my sandbox to pull the latest bug fixes.  I see that all the 
> routers in my cluster of 3 interior routers have stopped accepting 
> connections from my clients as well as qdstat.
> The port is properly open but qdstat shows the following error:
> *
> vsharda@millennium-qpid-untouched-latest-6443:~/apache-qpid-dispatch/my_build$
>  sudo netstat -tulpn | grep qdrouterd
> tcp0  0 0.0.0.0:56720.0.0.0:*   LISTEN
>   18460/qdrouterd 
> vsharda@millennium-qpid-untouched-latest-6443:~/apache-qpid-dispatch/my_build$
>  qdstat -c
> LinkDetached: sender 427616d4-8253-4bb3-a332-d1940a12f0e3-$management to 
> $management closed due to: Condition('qd:connection-role', 'Link attach 
> forbidden on inter-router connection')
> **
> If I run the router as standalone, I can see qdstat working fine.



--
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] (DISPATCH-370) qdmanage tool hangs if --type option is "linkRoute"

[Paolo Patierno (JIRA)]

Paolo Patierno created DISPATCH-370:
---

 Summary: qdmanage tool hangs if --type option is "linkRoute"
 Key: DISPATCH-370
 URL: https://issues.apache.org/jira/browse/DISPATCH-370
 Project: Qpid Dispatch
  Issue Type: Bug
Affects Versions: 0.6.0
Reporter: Paolo Patierno


Using qdmanage tool in the following way :

qdmanage read --type linkRoute

it doesn't reply with :

BadRequestStatus: No name or identity provided

but hangs and then exit for timeout :

Timeout: Connection amqp://localhost:5672/$management timed out: Waiting for 
response



--
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] (DISPATCH-371) qdstat and all other clients stopped connecting to interior router

[Vishal Sharda (JIRA)]

Vishal Sharda created DISPATCH-371:
--

 Summary: qdstat and all other clients stopped connecting to 
interior router
 Key: DISPATCH-371
 URL: https://issues.apache.org/jira/browse/DISPATCH-371
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Router Node
Affects Versions: 0.6.0
 Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 3 separate machines each
Reporter: Vishal Sharda
Priority: Blocker


I just updated my sandbox to pull the latest bug fixes.  I see that all the 
routers in my cluster of 3 interior routers have stopped accepting connections 
from my clients as well as qdstat.

The port is properly open but qdstat shows the following error:

*

vsharda@millennium-qpid-untouched-latest-6443:~/apache-qpid-dispatch/my_build$ 
sudo netstat -tulpn | grep qdrouterd
tcp0  0 0.0.0.0:56720.0.0.0:*   LISTEN  
18460/qdrouterd 
vsharda@millennium-qpid-untouched-latest-6443:~/apache-qpid-dispatch/my_build$ 
qdstat -c
LinkDetached: sender 427616d4-8253-4bb3-a332-d1940a12f0e3-$management to 
$management closed due to: Condition('qd:connection-role', 'Link attach 
forbidden on inter-router connection')

**

If I run the router as standalone, I can see qdstat working fine.




--
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] (DISPATCH-370) qdmanage tool hangs if --type option is "linkRoute" or "address"

[Paolo Patierno (JIRA)]

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

Paolo Patierno updated DISPATCH-370:

Description: 
Using qdmanage tool in the following way :

qdmanage read --type linkRoute

it doesn't reply with :

BadRequestStatus: No name or identity provided

but hangs and then exit for timeout :

Timeout: Connection amqp://localhost:5672/$management timed out: Waiting for 
response

The same happens using "address" as type.

  was:
Using qdmanage tool in the following way :

qdmanage read --type linkRoute

it doesn't reply with :

BadRequestStatus: No name or identity provided

but hangs and then exit for timeout :

Timeout: Connection amqp://localhost:5672/$management timed out: Waiting for 
response

Summary: qdmanage tool hangs if --type option is "linkRoute" or 
"address"  (was: qdmanage tool hangs if --type option is "linkRoute")

> qdmanage tool hangs if --type option is "linkRoute" or "address"
> 
>
> Key: DISPATCH-370
> URL: https://issues.apache.org/jira/browse/DISPATCH-370
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
>
> Using qdmanage tool in the following way :
> qdmanage read --type linkRoute
> it doesn't reply with :
> BadRequestStatus: No name or identity provided
> but hangs and then exit for timeout :
> Timeout: Connection amqp://localhost:5672/$management timed out: Waiting for 
> response
> The same happens using "address" as type.



--
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 48362: PROTON-1221: c++ container::schedule() support.

[Andrew Stitcher]

> On June 7, 2016, 9:40 p.m., Andrew Stitcher wrote:
> > You need to compile this code with C++03 and fix up the places that end up 
> > needing a feature macro to avoid breakage.
> 
> Alan Conway wrote:
> Yep, known limitation. I need to add C++03 callback support. This is a 
> first cut in C++11 without worrying about that. All your comments will apply 
> to the next cut.
> 
> Quetion: How to organize examples for features that are used differntly 
> in C++03 and C++11?
> 
> - separate c++11/c++03 examples?
> - conditionalized examples that work under both, with different example 
> code chunks selected by #ifdef?
> 
> Clean C++11 examples would be nice. They have to be defined against a 
> specific standard: 11, 14 or 17. We could choose a base standard (11) and use 
> conditional macros for features of 14/17 but I think we should stick to clean 
> c++11 - these are proton examples not C++ tutorials, if we can't write them 
> in C++11 we should rethink the API. That means separate examples (with some 
> redundancy) are needed at least for features that can't be used the same way 
> in C++03 (schedule, inject)
> 
> "Universal" conditionalized examples based on 03, with fake_cpp11.hpp, 
> #if PN_CPP_HAS_STD_FUNCTION etc. : easier for us to maintain, maybe easier 
> for users transitioning from 03 to 11 (side-by-side code) but cluttered for 
> users that are on 11. On the other hand very few of the examples actually 
> *need* C++11 features, so if we do have users stuck on older compilers it's a 
> bit obnoxious to make the base examples uncompilable when they could easily 
> be portable. It really hinges on how many users are in that position.
> 
> A hybrid of the above: conditionalized examples where C++11 and 03 are 
> nearly the same (basically what we have now) and separate examples where they 
> diverge.
> 
> I'm not sure, thoughts?

We've already decided this:

The main examples will be C++11 with a separate C++03 directory with the basic 
examples (about 4 I think, I don't remember exactly which).
(I think c++11 is sufficient although 14 would bring the convenience of 
make_unique<>)

We decided that mt is C++11 only, I don't think we decided this for function 
injection.

[Write this down, you seem to keep on forgetting we made this decision!]


> On June 7, 2016, 9:40 p.m., Andrew Stitcher wrote:
> > examples/cpp/scheduled_send.cpp, line 44
> > 
> >
> > Yep that's a good idea, lets add double constructors to duration (just 
> > not as pzrt of this change)
> 
> Alan Conway wrote:
> Agreed, will restrain myself :) I think we need double `op*` rather than 
> constructors to keep the units unambiguous: `duration 
> d(2.0*duration::SECOND)`. A double ctor will still have you doing `duration d 
> (2.0*duration::SECOND.milliseconds())`

That would be completely unambiguous, but I think that double seconds is pretty 
unambiguous tbh. `duration d(2.2); // duration of 2.2s`. Having the 
operator*(double, duration) operator*(duration, double) is still a good idea.


> On June 7, 2016, 9:40 p.m., Andrew Stitcher wrote:
> > proton-c/bindings/cpp/include/proton/container.hpp, line 201
> > 
> >
> > Need to add a new feature flag I'll need to look up the actual name, 
> > but PN_CPP_HAS_STD_FUNCTION will do for now.
> 
> Alan Conway wrote:
> See examples question above

No, this is in a shared header file you *must* put a feature macro in here. 
Whether the examples are 03 or 11 doesn't matter.


- Andrew


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


On June 7, 2016, 9:23 p.m., Alan Conway wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48362/
> ---
> 
> (Updated June 7, 2016, 9:23 p.m.)
> 
> 
> Review request for qpid, Andrew Stitcher, Cliff Jansen, and Justin Ross.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> PROTON-1221: c++ container::schedule() support.
> 
> 
> Diffs
> -
> 
>   examples/cpp/CMakeLists.txt 06ec1a49c00a98c3a602c9b6e76bf311345c397b 
>   examples/cpp/README.dox 897b302da0c0c132093b5f9977d28ac274cfeea9 
>   examples/cpp/mt/epoll_container.cpp 
> feea3007a8b732a47177a50d6ff385f9d60f1a63 
>   examples/cpp/scheduled_send.cpp PRE-CREATION 
>   proton-c/bindings/cpp/include/proton/container.hpp 
> 9665346cef187fccf59049ea4f5ce927dd46b60b 
>   proton-c/bindings/cpp/include/proton/default_container.hpp 
> f50869cb28b9d94784ab3329dcec43085eab4393 
>   proton-c/bindings/cpp/src/container_impl.hpp 
> 

Re: Review Request 48362: PROTON-1221: c++ container::schedule() support.

[Alan Conway]

On Tue, 2016-06-07 at 20:15 -0400, Michael Goulish wrote:
> 
> 
> > 
> > 
> > In other words, are we trying for a fixed frequency or an "at
> > least"
> > delay?
> > 
> What I need this feature for is to be able to send messages at a
> fixed frequency.

OK that's 2 votes, I'll redo the example for fixed frequency :)


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

Re: Review Request 48362: PROTON-1221: c++ container::schedule() support.

[Alan Conway]

> On June 7, 2016, 9:40 p.m., Andrew Stitcher wrote:
> > You need to compile this code with C++03 and fix up the places that end up 
> > needing a feature macro to avoid breakage.

Yep, known limitation. I need to add C++03 callback support. This is a first 
cut in C++11 without worrying about that. All your comments will apply to the 
next cut.

Quetion: How to organize examples for features that are used differntly in 
C++03 and C++11?

- separate c++11/c++03 examples?
- conditionalized examples that work under both, with different example code 
chunks selected by #ifdef?

Clean C++11 examples would be nice. They have to be defined against a specific 
standard: 11, 14 or 17. We could choose a base standard (11) and use 
conditional macros for features of 14/17 but I think we should stick to clean 
c++11 - these are proton examples not C++ tutorials, if we can't write them in 
C++11 we should rethink the API. That means separate examples (with some 
redundancy) are needed at least for features that can't be used the same way in 
C++03 (schedule, inject)

"Universal" conditionalized examples based on 03, with fake_cpp11.hpp, #if 
PN_CPP_HAS_STD_FUNCTION etc. : easier for us to maintain, maybe easier for 
users transitioning from 03 to 11 (side-by-side code) but cluttered for users 
that are on 11. On the other hand very few of the examples actually *need* 
C++11 features, so if we do have users stuck on older compilers it's a bit 
obnoxious to make the base examples uncompilable when they could easily be 
portable. It really hinges on how many users are in that position.

A hybrid of the above: conditionalized examples where C++11 and 03 are nearly 
the same (basically what we have now) and separate examples where they diverge.

I'm not sure, thoughts?


> On June 7, 2016, 9:40 p.m., Andrew Stitcher wrote:
> > examples/cpp/scheduled_send.cpp, line 29
> > 
> >
> > This is C++11 only don't need "fake_cpp11.hpp", and can just use 
> > "override" directly.

See examples question above


> On June 7, 2016, 9:40 p.m., Andrew Stitcher wrote:
> > examples/cpp/scheduled_send.cpp, line 54
> > 
> >
> > Should be able to combine into a single line with no loss of 
> > readability (IMO):
> > One common style seems to be -
> > 
> > ```
> > c.schedule(timeout, [this]() {
> > this->cancel();
> > });
> > ```

See examples question above.


> On June 7, 2016, 9:40 p.m., Andrew Stitcher wrote:
> > examples/cpp/scheduled_send.cpp, line 89
> > 
> >
> > Should the delay here take account of the actual now time?
> > 
> > In other words, are we trying for a fixed frequency or an "at least" 
> > delay?

For purposes of showing how to use schedule() I don't think it matters - I'll 
add a comment to clarify this this example is doing a delay *between* sends. 
Making it fixed frequency would allow us to show the use of now(), so we could 
do that too.


> On June 7, 2016, 9:40 p.m., Andrew Stitcher wrote:
> > proton-c/bindings/cpp/include/proton/container.hpp, line 201
> > 
> >
> > Need to add a new feature flag I'll need to look up the actual name, 
> > but PN_CPP_HAS_STD_FUNCTION will do for now.

See examples question above


> On June 7, 2016, 9:40 p.m., Andrew Stitcher wrote:
> > examples/cpp/scheduled_send.cpp, line 44
> > 
> >
> > Yep that's a good idea, lets add double constructors to duration (just 
> > not as pzrt of this change)

Agreed, will restrain myself :) I think we need double `op*` rather than 
constructors to keep the units unambiguous: `duration d(2.0*duration::SECOND)`. 
A double ctor will still have you doing `duration d 
(2.0*duration::SECOND.milliseconds())`


- Alan


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


On June 7, 2016, 9:23 p.m., Alan Conway wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48362/
> ---
> 
> (Updated June 7, 2016, 9:23 p.m.)
> 
> 
> Review request for qpid, Andrew Stitcher, Cliff Jansen, and Justin Ross.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> PROTON-1221: c++ container::schedule() support.
> 
> 
> Diffs
> -
> 
>   examples/cpp/CMakeLists.txt 06ec1a49c00a98c3a602c9b6e76bf311345c397b 
>   examples/cpp/README.dox 897b302da0c0c132093b5f9977d28ac274cfeea9 
>   

[jira] [Assigned] (QPID-7247) Implement preferences model and REST API

[Keith Wall (JIRA)]

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

Keith Wall reassigned QPID-7247:


Assignee: Keith Wall

> Implement preferences model and REST API
> 
>
> Key: QPID-7247
> URL: https://issues.apache.org/jira/browse/QPID-7247
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.1
>
>
> Implement the preferences model and the REST API described by:
> https://cwiki.apache.org/confluence/display/qpid/Preference+Store
> After this work it will be possible to add/update/remove preference from the 
> REST API, but there will be no persistence.  At this stage all preferences 
> will be available to all users.   There will be no security in preferences 
> layer.



--
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-368) Router in bad state in two inter-connected routers

[Ted Ross (JIRA)]

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

Ted Ross commented on DISPATCH-368:
---

DISPATCH-364 fixes two issues: First, it prevents normal clients from using 
inter-router listeners and consuming inter-router resources.  Secondly, it 
fixes a bug where inter-router connections did not relinquish all their 
resources when closed.  This is why the test fails after some time with the 
"overflow" error.


> Router in bad state in two inter-connected routers
> --
>
> Key: DISPATCH-368
> URL: https://issues.apache.org/jira/browse/DISPATCH-368
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines
>Reporter: Eric Leu
>Assignee: Ted Ross
> Fix For: 0.6.0
>
>
> The setup of two inter-connected routers is the same as in DISPATCH-358. Let 
> the routers be A and B.  Senders connect to A and receivers connect to B. 
> While senders are sending messages to A, restart router B every 10 sec.  
> Senders check tracker status to make sure messages are accepted by the 
> receivers.  After running for some time, router A is in bad state.   No 
> messages sent are accepted.   After that point, I keep router B up without 
> restarting.  The problem does not go away.  Restart senders and receivers and 
> does not help.  I also notice the error in the log:
> 
> 2016-06-07 14:13:39.287550 -0700 AGENT (debug) Add entity: RouterNodeEntity 
> (address=amqp:/_topo/0/Router.A.1, cost=None, id=Router.A.1, 
> instance=1465333922, linkState=[], 
> nextHop=None, routerLink=None, type=org.apache.qpid.dispatch.router.node, 
> validOrigins=None)
> 2016-06-07 14:13:39.294891 -0700 ROUTER (error) Control message error: 
> opcode=HELLO body=
> {'seen': ['Router.A.0'], 'area': '0', 'id': 'Router.A.1', 'instance': 
> 1465333922L}
> Traceback (most recent call last):
>   File 
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/engine.py",
>  line 137, 
> in handleControlMessage
> self.hello_protocol.handle_hello(msg, now, link_id, cost)
>   File 
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/hello.py", 
> line 55, 
> in handle_hello
> self.node_tracker.neighbor_refresh(msg.id, msg.instance, link_id, cost, 
> now)
>   File 
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py", 
> line 207, 
> in neighbor_refresh
> if node.set_link_id(link_id):
>   File 
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py", 
> line 410, 
> in set_link_id
> self.adapter.set_link(self.maskbit, link_id)
> OverflowError: signed integer is greater than maximum



--
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] (DISPATCH-368) Router in bad state in two inter-connected routers

[Ted Ross (JIRA)]

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

Ted Ross resolved DISPATCH-368.
---
   Resolution: Fixed
Fix Version/s: 0.6.0

> Router in bad state in two inter-connected routers
> --
>
> Key: DISPATCH-368
> URL: https://issues.apache.org/jira/browse/DISPATCH-368
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines
>Reporter: Eric Leu
>Assignee: Ted Ross
> Fix For: 0.6.0
>
>
> The setup of two inter-connected routers is the same as in DISPATCH-358. Let 
> the routers be A and B.  Senders connect to A and receivers connect to B. 
> While senders are sending messages to A, restart router B every 10 sec.  
> Senders check tracker status to make sure messages are accepted by the 
> receivers.  After running for some time, router A is in bad state.   No 
> messages sent are accepted.   After that point, I keep router B up without 
> restarting.  The problem does not go away.  Restart senders and receivers and 
> does not help.  I also notice the error in the log:
> 
> 2016-06-07 14:13:39.287550 -0700 AGENT (debug) Add entity: RouterNodeEntity 
> (address=amqp:/_topo/0/Router.A.1, cost=None, id=Router.A.1, 
> instance=1465333922, linkState=[], 
> nextHop=None, routerLink=None, type=org.apache.qpid.dispatch.router.node, 
> validOrigins=None)
> 2016-06-07 14:13:39.294891 -0700 ROUTER (error) Control message error: 
> opcode=HELLO body=
> {'seen': ['Router.A.0'], 'area': '0', 'id': 'Router.A.1', 'instance': 
> 1465333922L}
> Traceback (most recent call last):
>   File 
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/engine.py",
>  line 137, 
> in handleControlMessage
> self.hello_protocol.handle_hello(msg, now, link_id, cost)
>   File 
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/hello.py", 
> line 55, 
> in handle_hello
> self.node_tracker.neighbor_refresh(msg.id, msg.instance, link_id, cost, 
> now)
>   File 
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py", 
> line 207, 
> in neighbor_refresh
> if node.set_link_id(link_id):
>   File 
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py", 
> line 410, 
> in set_link_id
> self.adapter.set_link(self.maskbit, link_id)
> OverflowError: signed integer is greater than maximum



--
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-368) Router in bad state in two inter-connected routers

[Ted Ross (JIRA)]

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

Ted Ross commented on DISPATCH-368:
---

The fix for DISPATCH-364 should also fix this issue.

> Router in bad state in two inter-connected routers
> --
>
> Key: DISPATCH-368
> URL: https://issues.apache.org/jira/browse/DISPATCH-368
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines
>Reporter: Eric Leu
>
> The setup of two inter-connected routers is the same as in DISPATCH-358. Let 
> the routers be A and B.  Senders connect to A and receivers connect to B. 
> While senders are sending messages to A, restart router B every 10 sec.  
> Senders check tracker status to make sure messages are accepted by the 
> receivers.  After running for some time, router A is in bad state.   No 
> messages sent are accepted.   After that point, I keep router B up without 
> restarting.  The problem does not go away.  Restart senders and receivers and 
> does not help.  I also notice the error in the log:
> 
> 2016-06-07 14:13:39.287550 -0700 AGENT (debug) Add entity: RouterNodeEntity 
> (address=amqp:/_topo/0/Router.A.1, cost=None, id=Router.A.1, 
> instance=1465333922, linkState=[], 
> nextHop=None, routerLink=None, type=org.apache.qpid.dispatch.router.node, 
> validOrigins=None)
> 2016-06-07 14:13:39.294891 -0700 ROUTER (error) Control message error: 
> opcode=HELLO body=
> {'seen': ['Router.A.0'], 'area': '0', 'id': 'Router.A.1', 'instance': 
> 1465333922L}
> Traceback (most recent call last):
>   File 
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/engine.py",
>  line 137, 
> in handleControlMessage
> self.hello_protocol.handle_hello(msg, now, link_id, cost)
>   File 
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/hello.py", 
> line 55, 
> in handle_hello
> self.node_tracker.neighbor_refresh(msg.id, msg.instance, link_id, cost, 
> now)
>   File 
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py", 
> line 207, 
> in neighbor_refresh
> if node.set_link_id(link_id):
>   File 
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py", 
> line 410, 
> in set_link_id
> self.adapter.set_link(self.maskbit, link_id)
> OverflowError: signed integer is greater than maximum



--
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] (DISPATCH-368) Router in bad state in two inter-connected routers

[Ted Ross (JIRA)]

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

Ted Ross reassigned DISPATCH-368:
-

Assignee: Ted Ross

> Router in bad state in two inter-connected routers
> --
>
> Key: DISPATCH-368
> URL: https://issues.apache.org/jira/browse/DISPATCH-368
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines
>Reporter: Eric Leu
>Assignee: Ted Ross
>
> The setup of two inter-connected routers is the same as in DISPATCH-358. Let 
> the routers be A and B.  Senders connect to A and receivers connect to B. 
> While senders are sending messages to A, restart router B every 10 sec.  
> Senders check tracker status to make sure messages are accepted by the 
> receivers.  After running for some time, router A is in bad state.   No 
> messages sent are accepted.   After that point, I keep router B up without 
> restarting.  The problem does not go away.  Restart senders and receivers and 
> does not help.  I also notice the error in the log:
> 
> 2016-06-07 14:13:39.287550 -0700 AGENT (debug) Add entity: RouterNodeEntity 
> (address=amqp:/_topo/0/Router.A.1, cost=None, id=Router.A.1, 
> instance=1465333922, linkState=[], 
> nextHop=None, routerLink=None, type=org.apache.qpid.dispatch.router.node, 
> validOrigins=None)
> 2016-06-07 14:13:39.294891 -0700 ROUTER (error) Control message error: 
> opcode=HELLO body=
> {'seen': ['Router.A.0'], 'area': '0', 'id': 'Router.A.1', 'instance': 
> 1465333922L}
> Traceback (most recent call last):
>   File 
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/engine.py",
>  line 137, 
> in handleControlMessage
> self.hello_protocol.handle_hello(msg, now, link_id, cost)
>   File 
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/hello.py", 
> line 55, 
> in handle_hello
> self.node_tracker.neighbor_refresh(msg.id, msg.instance, link_id, cost, 
> now)
>   File 
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py", 
> line 207, 
> in neighbor_refresh
> if node.set_link_id(link_id):
>   File 
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py", 
> line 410, 
> in set_link_id
> self.adapter.set_link(self.maskbit, link_id)
> OverflowError: signed integer is greater than maximum



--
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] (DISPATCH-364) Inter-router listeners should not permit normal endpoint traffic

[Ted Ross (JIRA)]

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

Ted Ross resolved DISPATCH-364.
---
Resolution: Fixed

> Inter-router listeners should not permit normal endpoint traffic
> 
>
> Key: DISPATCH-364
> URL: https://issues.apache.org/jira/browse/DISPATCH-364
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
>Reporter: Ted Ross
>Assignee: Ted Ross
>
> A router network can be configured such that normal clients connect to the 
> network using listeners designated with the inter-router role.  Since there 
> can be only a limited number of routers in a network (128 in 0.6.0), it 
> doesn't take many connected clients to clog up the inter-router connection 
> space.
> The router node should be modified such that normal links attaching over 
> inter-router connections are forbidden.



--
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] (DISPATCH-365) Standalone router crashes if an interior router attempts to connect to it

[Ted Ross (JIRA)]

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

Ted Ross resolved DISPATCH-365.
---
   Resolution: Fixed
Fix Version/s: 0.6.0

> Standalone router crashes if an interior router attempts to connect to it
> -
>
> Key: DISPATCH-365
> URL: https://issues.apache.org/jira/browse/DISPATCH-365
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines
>Reporter: Vishal Sharda
>Assignee: Ted Ross
>Priority: Critical
> Fix For: 0.6.0
>
> Attachments: config1_standalone.conf, config2_nossl.conf
>
>
> I accidentally pointed my interior router to a standalone router.  The 
> standalone router did not ignore the connection request and crashed.  The 
> attached config files reproduce the crash.



--
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-364) Inter-router listeners should not permit normal endpoint traffic

[ASF subversion and git services (JIRA)]

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

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

Commit 3dcf3346a1efdb3ffdff007c00818cfca04c1e0a in qpid-dispatch's branch 
refs/heads/master from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=3dcf334 ]

DISPATCH-364 - Forbid normal link attaches from endpoints on inter-router 
listeners.


> Inter-router listeners should not permit normal endpoint traffic
> 
>
> Key: DISPATCH-364
> URL: https://issues.apache.org/jira/browse/DISPATCH-364
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
>Reporter: Ted Ross
>Assignee: Ted Ross
>
> A router network can be configured such that normal clients connect to the 
> network using listeners designated with the inter-router role.  Since there 
> can be only a limited number of routers in a network (128 in 0.6.0), it 
> doesn't take many connected clients to clog up the inter-router connection 
> space.
> The router node should be modified such that normal links attaching over 
> inter-router connections are forbidden.



--
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-365) Standalone router crashes if an interior router attempts to connect to it

[ASF subversion and git services (JIRA)]

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

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

Commit 2661d282dcaceaba45958c8160d1e2f08673d8aa in qpid-dispatch's branch 
refs/heads/master from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=2661d28 ]

DISPATCH-365 - Don't handle inter-router link detaches on non inter-router 
connections.


> Standalone router crashes if an interior router attempts to connect to it
> -
>
> Key: DISPATCH-365
> URL: https://issues.apache.org/jira/browse/DISPATCH-365
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines
>Reporter: Vishal Sharda
>Assignee: Ted Ross
>Priority: Critical
> Attachments: config1_standalone.conf, config2_nossl.conf
>
>
> I accidentally pointed my interior router to a standalone router.  The 
> standalone router did not ignore the connection request and crashed.  The 
> attached config files reproduce the crash.



--
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-364) Inter-router listeners should not permit normal endpoint traffic

[ASF subversion and git services (JIRA)]

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

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

Commit d4b88c1515c403246accc8b0dda5dc3430924ed8 in qpid-dispatch's branch 
refs/heads/master from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=d4b88c1 ]

DISPATCH-364 - Added a test to verify attach-failure on the inter-router 
listener.


> Inter-router listeners should not permit normal endpoint traffic
> 
>
> Key: DISPATCH-364
> URL: https://issues.apache.org/jira/browse/DISPATCH-364
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
>Reporter: Ted Ross
>Assignee: Ted Ross
>
> A router network can be configured such that normal clients connect to the 
> network using listeners designated with the inter-router role.  Since there 
> can be only a limited number of routers in a network (128 in 0.6.0), it 
> doesn't take many connected clients to clog up the inter-router connection 
> space.
> The router node should be modified such that normal links attaching over 
> inter-router connections are forbidden.



--
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-7296) Use connection property to determine if message delay (notValidBefore) is supported or not

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7296:
-
Fix Version/s: (was: qpid-java-6.2)
   qpid-java-7.0.0

> Use connection property to determine if message delay (notValidBefore) is 
> supported or not
> --
>
> Key: QPID-7296
> URL: https://issues.apache.org/jira/browse/QPID-7296
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker, Java Client
>Reporter: Keith Wall
> Fix For: qpid-java-7.0.0
>
>
> QPID-7255 introduced support of message delays. 
> Make the Broker provide a connection property that reveals that it supports 
> the notValidBefore feature.  Make clients detect this feature and warn if the 
> application tries to make use of the address options.



--
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-7276) Message delay improvements

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7276:
-
Description: 
QPID-7255 introduced support of message delays.  To make the feature more 
useful/usable, the following additions are identified:

# Extend the Queue UI to allow {{holdOnPublishEnabled}} to be enabled when 
creating or updating a queue.  
# Reveal through the UI when a Queue Entry is held.
# Make the Message content UI treat {{NotValidBefore}} as a date/time.

  was:
QPID-7255 introduced support of message delays.  To make the feature more 
useful/usable, the following additions are identified:

# Make the Broker provide a connection property that reveals that it supports 
the notValidBefore feature.  Make clients detect this feature and warn if the 
application tries to make use of the address options.
# Extend the Queue UI to allow {{holdOnPublishEnabled}} to be enabled when 
creating or updating a queue.  
# Reveal through the UI when a Queue Entry is held.
# Make the Message content UI treat {{NotValidBefore}} as a date/time.


> Message delay improvements
> --
>
> Key: QPID-7276
> URL: https://issues.apache.org/jira/browse/QPID-7276
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
>
> QPID-7255 introduced support of message delays.  To make the feature more 
> useful/usable, the following additions are identified:
> # Extend the Queue UI to allow {{holdOnPublishEnabled}} to be enabled when 
> creating or updating a queue.  
> # Reveal through the UI when a Queue Entry is held.
> # Make the Message content UI treat {{NotValidBefore}} as a date/time.



--
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-7296) Use connection property to determine if message delay (notValidBefore) is supported or not

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7296:
-
Component/s: Java Client

> Use connection property to determine if message delay (notValidBefore) is 
> supported or not
> --
>
> Key: QPID-7296
> URL: https://issues.apache.org/jira/browse/QPID-7296
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker, Java Client
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> QPID-7255 introduced support of message delays. 
> Make the Broker provide a connection property that reveals that it supports 
> the notValidBefore feature.  Make clients detect this feature and warn if the 
> application tries to make use of the address options.



--
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-7296) Use connection property to determine if message delay (notValidBefore) is supported or not

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7296:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-6.2

> Use connection property to determine if message delay (notValidBefore) is 
> supported or not
> --
>
> Key: QPID-7296
> URL: https://issues.apache.org/jira/browse/QPID-7296
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> QPID-7255 introduced support of message delays. 
> Make the Broker provide a connection property that reveals that it supports 
> the notValidBefore feature.  Make clients detect this feature and warn if the 
> application tries to make use of the address options.



--
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-7296) Use connection property to determine if message delay (notValidBefore) is supported or not

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7296:
-
Summary: Use connection property to determine if message delay 
(notValidBefore) is supported or not  (was: Use connection property to 
determine if message delay (notValidBefore )is supported or not)

> Use connection property to determine if message delay (notValidBefore) is 
> supported or not
> --
>
> Key: QPID-7296
> URL: https://issues.apache.org/jira/browse/QPID-7296
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> QPID-7255 introduced support of message delays. 
> Make the Broker provide a connection property that reveals that it supports 
> the notValidBefore feature.  Make clients detect this feature and warn if the 
> application tries to make use of the address options.



--
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-7296) Use connection property to show determine if message delay is supported or not

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7296:
-
Description: 
QPID-7255 introduced support of message delays. 

Make the Broker provide a connection property that reveals that it supports the 
notValidBefore feature.  Make clients detect this feature and warn if the 
application tries to make use of the address options.


  was:
QPID-7255 introduced support of message delays.  To make the feature more 
useful/usable, the following additions are identified:

# Make the Broker provide a connection property that reveals that it supports 
the notValidBefore feature.  Make clients detect this feature and warn if the 
application tries to make use of the address options.
# Extend the Queue UI to allow {{holdOnPublishEnabled}} to be enabled when 
creating or updating a queue.  
# Reveal through the UI when a Queue Entry is held.
# Make the Message content UI treat {{NotValidBefore}} as a date/time.


> Use connection property to show determine if message delay is supported or not
> --
>
> Key: QPID-7296
> URL: https://issues.apache.org/jira/browse/QPID-7296
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> QPID-7255 introduced support of message delays. 
> Make the Broker provide a connection property that reveals that it supports 
> the notValidBefore feature.  Make clients detect this feature and warn if the 
> application tries to make use of the address options.



--
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-7296) Use connection property to determine if message delay (notValidBefore )is supported or not

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7296:
-
Summary: Use connection property to determine if message delay 
(notValidBefore )is supported or not  (was: Use connection property to show 
determine if message delay is supported or not)

> Use connection property to determine if message delay (notValidBefore )is 
> supported or not
> --
>
> Key: QPID-7296
> URL: https://issues.apache.org/jira/browse/QPID-7296
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> QPID-7255 introduced support of message delays. 
> Make the Broker provide a connection property that reveals that it supports 
> the notValidBefore feature.  Make clients detect this feature and warn if the 
> application tries to make use of the address options.



--
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-7296) Use connection property to show determine if message delay is supported or not

[Keith Wall (JIRA)]

Keith Wall created QPID-7296:


 Summary: Use connection property to show determine if message 
delay is supported or not
 Key: QPID-7296
 URL: https://issues.apache.org/jira/browse/QPID-7296
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Keith Wall
 Fix For: qpid-java-6.1


QPID-7255 introduced support of message delays.  To make the feature more 
useful/usable, the following additions are identified:

# Make the Broker provide a connection property that reveals that it supports 
the notValidBefore feature.  Make clients detect this feature and warn if the 
application tries to make use of the address options.
# Extend the Queue UI to allow {{holdOnPublishEnabled}} to be enabled when 
creating or updating a queue.  
# Reveal through the UI when a Queue Entry is held.
# Make the Message content UI treat {{NotValidBefore}} as a date/time.



--
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-7292) Qpid clients should verify the server-final message when using SCRAM-* authentication

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7292:
-
Fix Version/s: qpid-java-6.2

> Qpid clients should verify the server-final message when using SCRAM-* 
> authentication
> -
>
> Key: QPID-7292
> URL: https://issues.apache.org/jira/browse/QPID-7292
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Reporter: Rob Godfrey
> Fix For: qpid-java-6.2
>
>
> QPID-7282 addressed the issue that the Java Broker was not sending the 
> server-final message in the SCRAM-* SASL exchange, however this omission was 
> not causing the clients to fail, since they blindly accept the server's 
> acceptance of their credentials.
> Clients implementing SCRAM-* or similar protocols which include a client 
> verification step, should perform the verification of the server and fail or 
> warn (to be configured by a system property) if the verification does not 
> occur or it fails.



--
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-6981) SSLSender does not send the close_notify bytes during client initiated connection close

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-6981:
-
Fix Version/s: qpid-java-6.2

> SSLSender does not send the close_notify bytes during client initiated 
> connection close 
> 
>
> Key: QPID-6981
> URL: https://issues.apache.org/jira/browse/QPID-6981
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client, Java Common
>Affects Versions: qpid-java-6.0
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> If I close an connection that uses TLS from the client side (AMQP 0-10 or 
> 0-9), the socket is successfully closed, but the SSL close_notify bytes are 
> never sent over the wire.  The Java Broker logs a stack trace to report this. 
> The client side problem is in {{SSLSender#tearDownSSLConnection}}.  
> The following in the log of 
> {{SSLTest.testCreateSSLConnectionUsingConnectionURLParams}} augments with 
> extra trace in tearDownSSLConnection/IoSender.
> {noformat}
> 2016-01-09 17:01:01,047 DEBUG 
> [IoRcvr-/127.0.0.1:51231-localhost/127.0.0.1:51229] o.a.q.t.Connection RECV: 
> [conn:618c5d94] ch=0 ConnectionCloseOk()
> 2016-01-09 17:01:01,048 DEBUG 
> [IoRcvr-/127.0.0.1:51231-localhost/127.0.0.1:51229] o.a.q.t.n.s.s.SSLSender 
> Closing SSL connection
> 2016-01-09 17:01:01,048 DEBUG 
> [IoRcvr-/127.0.0.1:51231-localhost/127.0.0.1:51229] o.a.q.t.n.s.s.SSLSender 
> SSLEngine result Status = BUFFER_OVERFLOW HandshakeStatus = NEED_WRAP
> bytesConsumed = 0 bytesProduced = 0 (tearDownSSLConnection initial wrap)
> 2016-01-09 17:01:01,048 DEBUG [IO-/127.0.0.1:51231] 
> o.a.q.s.t.MultiVersionProtocolEngine Closed
> 2016-01-09 17:01:01,048 DEBUG 
> [IoRcvr-/127.0.0.1:51231-localhost/127.0.0.1:51229] o.a.q.t.n.s.s.SSLSender 
> SSLEngine result Status = CLOSED HandshakeStatus = NEED_UNWRAP
> bytesConsumed = 0 bytesProduced = 85 (tearDownSSLConnection loop wrap)
> ##  These 85 bytes never go down the wire
> 2016-01-09 17:01:01,048 DEBUG 
> [IoRcvr-/127.0.0.1:51231-localhost/127.0.0.1:51229] o.a.q.t.Connection 
> connection closed: conn:618c5d94
> {noformat}
> The Java Broker logs the a stack trace at debug complaining that it never 
> received the close_notify.  It otherwise ignores the condition.
> {noformat}
> 2016-01-09 17:01:01,055 DEBUG [IO-/127.0.0.1:51231] 
> o.a.q.s.t.NonBlockingConnectionTLSDelegate Exception when closing SSLEngine
> javax.net.ssl.SSLException: Inbound closed before receiving peer's 
> close_notify: possible truncation attack?
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) 
> ~[na:1.8.0_45]
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) 
> ~[na:1.8.0_45]
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634) 
> ~[na:1.8.0_45]
> at 
> sun.security.ssl.SSLEngineImpl.closeInbound(SSLEngineImpl.java:1561) 
> ~[na:1.8.0_45]
> at 
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.shutdownOutput(NonBlockingConnectionTLSDelegate.java:364)
>  ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at 
> org.apache.qpid.server.transport.NonBlockingConnection.shutdownOutput(NonBlockingConnection.java:409)
>  [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at 
> org.apache.qpid.server.transport.NonBlockingConnection.shutdown(NonBlockingConnection.java:360)
>  [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at 
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:299)
>  [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at 
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:108)
>  [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at 
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:502)
>  [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:340)
>  [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:86)
>  [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at 
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:460) 
> [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> 

[jira] [Updated] (QPID-7123) [Java Client] Closing an SSL connection may timeout

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7123:
-
Fix Version/s: qpid-java-6.2

> [Java Client] Closing an SSL connection may timeout
> ---
>
> Key: QPID-7123
> URL: https://issues.apache.org/jira/browse/QPID-7123
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.2
>
> Attachments: 
> TEST-org.apache.qpid.client.ssl.SSLTest.testSSLConnectionToPlainPortRejected.txt
>
>
> As highlighted by the following test faiure on Apache CI.
> It appears that there is a path through the SSLSender/Receiver which doesn't 
> notify the mutex.
> {noformat}
> org.apache.qpid.client.ssl.SSLTest.testSSLConnectionToPlainPortRejected
> Failing for the past 1 build (Since Failed#2151 )
> Took 1 min 0 sec.
> add description
> Error Message
> Unexpected exception message : Error creating connection: SSL Engine timed 
> out after waiting 6ms. for a response.To get more info,run with 
> -Djavax.net.debug=ssl
> Stacktrace
> junit.framework.AssertionFailedError: Unexpected exception message : Error 
> creating connection: SSL Engine timed out after waiting 6ms. for a 
> response.To get more info,run with -Djavax.net.debug=ssl
>   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.client.ssl.SSLTest.testSSLConnectionToPlainPortRejected(SSLTest.java:153)
> Standard Output
> 15:43:17,172 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - 
> About to instantiate appender of type [ch.qos.logback.core.FileAppender]
> 15:43:17,172 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - 
> Naming appender as 
> [FILE-org.apache.qpid.client.ssl.SSLTest.testSSLConnectionToPlainPortRejected]
> 15:43:17,172 |-INFO in 
> ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default 
> type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] 
> property
> 15:43:17,173 |-INFO in 
> ch.qos.logback.core.FileAppender[FILE-org.apache.qpid.client.ssl.SSLTest.testSSLConnectionToPlainPortRejected]
>  - File property is set to 
> [/home/jenkins/jenkins-slave/workspace/Qpid-Java-Java-BDB-TestMatrix/jdk/JDK 
> 1.7 
> (latest)/label/Ubuntu/profile/java-bdb.0-9-1/systests/target/surefire-reports/java-bdb.0-9-1/TEST-org.apache.qpid.client.ssl.SSLTest.testSSLConnectionToPlainPortRejected.txt]
> {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] [Updated] (QPID-7198) LDAP and OAUTH2 Authentication Providers should cache authentication results for a short period

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7198:
-
Fix Version/s: qpid-java-6.1

> LDAP and OAUTH2 Authentication Providers should cache authentication results 
> for a short period
> ---
>
> Key: QPID-7198
> URL: https://issues.apache.org/jira/browse/QPID-7198
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
>
> The OAUTH2 and LDAP authentication providers should be changed to cache 
> authentication results for a short (configurable) period.  If the same 
> authentication provider receives the same credentials again (i.e. matching 
> username and password in the case of LDAP), it should reuse the cached 
> authentication result.   The cached authentication result should expire 
> automatically.  Negative authentication results should be cached too.
> This will serve to reduce load on authentication backends (such as 
> Directories).  It will be especially useful when the REST API to used for 
> programmatically monitoring the Broker which otherwise may create an 
> excessive load on the backend.
> The authentication provider must not retain the user passwords in clear.  The 
> size of the cache should be constrained.



--
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-7245) Configuration upgrader for realm qualified identities

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7245:
-
Fix Version/s: qpid-java-6.2

> Configuration upgrader for realm qualified identities
> -
>
> Key: QPID-7245
> URL: https://issues.apache.org/jira/browse/QPID-7245
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.1
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> Produce an automated configuration upgrader that acts on authentication and 
> group provider records.  The upgrader must populate the realm attribute 
> applying the same rules as the defaulting rules used by the providers 
> themselves, ensuring a unique name is produced.
> The configuration upgrader must upgrade the {{createdBy}} and 
> {{lastUpdatedBy}} attributes to be realm qualified. This can only be done if 
> there is exactly one authentication provider.
> Automatic upgrade of the ACL rules and JMSXUserId within sent messages are 
> out of scope.



--
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-7244) Expose realm qualified authenticate name to messaging clients

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7244:
-
Fix Version/s: qpid-java-6.2

> Expose realm qualified authenticate name to messaging clients
> -
>
> Key: QPID-7244
> URL: https://issues.apache.org/jira/browse/QPID-7244
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> We want messaging clients to be capable of publishing messages with the 
> {{JMSXUserId}} populated with a realm qualified authenticated name.
> To enable this for 0-8..0-10 change message source {{$virtualhostproperties}} 
> to have an extra header {{authenticatedUser}} which will contain the 
> serialised form of the principal.   For 1.0, a non-normative (probably qpid 
> specific) connection property could be used by the open performative 
> (discussion required).
> The Java Broker messageAuthorizationRequired feature must be relaxed to allow 
> either the the realm qualified form, or bare form. The latter is required for 
> compatibility with clients which don't support the feature.



--
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-7293) Rationalise broker logging levels

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7293:
-
Fix Version/s: (was: qpid-java-7.0.0)
   qpid-java-6.2

> Rationalise broker logging levels
> -
>
> Key: QPID-7293
> URL: https://issues.apache.org/jira/browse/QPID-7293
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> We need to ensure that logging levels are used consistently throughout the 
> Java Broker keeping in mind the expected use-case for each level. 
> We think the protocol level logging (which may contain secrets, depending on 
> the SASL mechanism in-use) should take place at TRACE level,



--
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-7283) [Java Broker] Simplify SASL authentication functionality accros broker AMQP layers

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7283:
-
Fix Version/s: qpid-java-6.2

> [Java Broker] Simplify SASL authentication functionality accros broker AMQP 
> layers
> --
>
> Key: QPID-7283
> URL: https://issues.apache.org/jira/browse/QPID-7283
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Alex Rudyy
> Fix For: qpid-java-6.2
>
>
> At the moment SASL authentication functionality in existing AMQP layers uses 
> SaslServer created with authentication provider and calls SaslServer directly 
> to process client responses. We can encapsulate SaslServer server under 
> special SASL authentication API and simplify the existing SASL functionality. 



--
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-7293) Rationalise broker logging levels

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7293:
-
Fix Version/s: qpid-java-7.0.0

> Rationalise broker logging levels
> -
>
> Key: QPID-7293
> URL: https://issues.apache.org/jira/browse/QPID-7293
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-7.0.0
>
>
> We need to ensure that logging levels are used consistently throughout the 
> Java Broker keeping in mind the expected use-case for each level. 
> We think the protocol level logging (which may contain secrets, depending on 
> the SASL mechanism in-use) should take place at TRACE level,



--
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-6907) Add ability to restrict read in ACLs

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-6907:
-
Fix Version/s: (was: Future)
   qpid-java-6.2

> Add ability to restrict read in ACLs
> 
>
> Key: QPID-6907
> URL: https://issues.apache.org/jira/browse/QPID-6907
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> Currently the ACL mechanism has no way to restrict what a management user can 
> see.   If the user can authenticate, then they are entitled to see all the 
> objects beneath Broker.  There is no way to express user A should have 
> management permission to read below virtual host X.
> ACLs do have an ACCESS permission, be this is used to govern connections to 
> virtual hosts for messaging.



--
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-6990) [Java Broker] Support password expiry

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-6990:
-
Fix Version/s: (was: Future)
   qpid-java-6.2

> [Java Broker] Support password expiry
> -
>
> Key: QPID-6990
> URL: https://issues.apache.org/jira/browse/QPID-6990
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
> Attachments: QPID-6990.patch
>
>
> Enhance the Java Broker authentication mechanism so that it supports password 
> expiry.  For channels that support  changing a password (e.g. management over 
> HTTP) after I login with a password that needs to be changed, the system 
> should prompt me to change my password, perhaps disallowing my attempts to do 
> other work until I have do so. 
> The system would support perpetual accounts (typically for application use).  
> It would also allow accounts to be created in such a way that they require 
> change on first use.



--
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-6991) NonBlockingConnection does not gracefully close TLS connections

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-6991:
-
Fix Version/s: (was: Future)
   qpid-java-6.2

> NonBlockingConnection does not gracefully close TLS connections
> ---
>
> Key: QPID-6991
> URL: https://issues.apache.org/jira/browse/QPID-6991
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> As exposed by QPID-6975, NonBlockingConnection's handling of TLS connection 
> close is deficient.
> Currently for AMQP 0-8..0-10, the receipt of the AMQP connection close from 
> the client causes the NBC#_closed to be marked true 
> (NonBlockingConnection#close is called from the protocol layer) and the 
> NonBlockingConnectionDelegate and SocketChannel are shutdown immediately (as 
> that invocation of #doWork finishes).  This means that the Broker never reads 
> the SSL close_notify that ought to be sent by the client, so the following 
> warning is logged:
> {noformat}
> 2016-01-09 17:01:01,055 DEBUG [IO-/127.0.0.1:51231] 
> o.a.q.s.t.NonBlockingConnectionTLSDelegate Exception when closing SSLEngine
> javax.net.ssl.SSLException: Inbound closed before receiving peer's 
> close_notify: possible truncation attack?
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) 
> ~[na:1.8.0_45]
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) 
> ~[na:1.8.0_45]
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634) 
> ~[na:1.8.0_45]
> at 
> sun.security.ssl.SSLEngineImpl.closeInbound(SSLEngineImpl.java:1561) 
> ~[na:1.8.0_45]
> at 
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.shutdownOutput(NonBlockingConnectionTLSDelegate.java:364)
>  ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at 
> org.apache.qpid.server.transport.NonBlockingConnection.shutdownOutput(NonBlockingConnection.java:409)
>  [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at 
> org.apache.qpid.server.transport.NonBlockingConnection.shutdown(NonBlockingConnection.java:360)
>  [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at 
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:299)
>  [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at 
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:108)
>  [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at 
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:502)
>  [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:340)
>  [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:86)
>  [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at 
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:460) 
> [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {noformat}
> For AMQP 1.0, things are a little better.  The protocol layer does not 
> currently immediately close the connection and so the connection is left open 
> and the the SSL close_notify will be read.
> The process on connection close for TLS connections on non Windows platform 
> needs to be something like:
> # write AMQP close-ok
> # install ConnectionCloseTicker
> # close SSLEngine outbound
> # write again (to send the close_notify  bytes)
> # socket channel shutdown outbound
> # socket channel should remain registered for OP_READ until -1 is 
> encountered, or CCT ticker is timed-out, 
> # close SSLEngine inbound
> # socket channel shutdown inbound



--
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-7168) Allow authentication providers to resolve a realm qualified user identity into a displayable name

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7168:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-6.2

> Allow authentication providers to resolve a realm qualified user identity 
> into a displayable name
> -
>
> Key: QPID-7168
> URL: https://issues.apache.org/jira/browse/QPID-7168
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> Extend the Authentication Provider interface to allow implementations to 
> resolve a realm qualified user identity into a human readable name.  If the 
> authentication provider does not recognise the realm, it is not capable of 
> resolving names or the name is not known, the provider must return null.  
> Callers must be prepared to handle null.
> Internally, providers may implement this method by calling out to the 
> authentication backend. Alternatively, the provider may maintain a cache of 
> names, populated as users authenticate.  The provider should be prepared to 
> be queried many times for a user's name during the lifetime of Broker's 
> execution, so should take steps to avoid expensive processing, if necessary.



--
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-7243) Make legacy JMS client publish messages with domain qualified userid

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7243:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-6.2

> Make legacy JMS client publish messages with domain qualified userid
> 
>
> Key: QPID-7243
> URL: https://issues.apache.org/jira/browse/QPID-7243
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> The Java Client currently populates {{JMSXUserId}} of published messages with 
> the userid that the client used to authenticate to the Broker.   When the 
> client is in use with the Java Broker which supports the feature, it should 
> pass the domain qualified name, supplied by the Broker instead.
> To do this, message source $virtualhostproperties will have an extra header 
> authenticatedUser which will contain the serialised form of the principal.
> If this is populated, the client MUST use this value in preference to the 
> value it used when it authenticated.



--
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-7242) Make existing authentication/group providers produce realm qualified principals

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7242:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-6.2

> Make existing authentication/group providers produce realm qualified 
> principals 
> 
>
> Key: QPID-7242
> URL: https://issues.apache.org/jira/browse/QPID-7242
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> Change all existing authentication and group providers to produce realm 
> qualified principals.
> Each authentication and group provider will have a {{realm}} attribute.  
> Validation ({{#onValidate}}) must ensure that the realm name used by each 
> provider is unique.
> For some providers, the realm name may be default-able: authentication/group 
> backends can default to the domain name (the host portion of a URI) of the 
> authentication/group server e.g. directory.example.com in the case of an 
> Directory (LDAP).  For non-server backed providers, an realm can be 
> constructed using the other realm suggested by RFC-4120 (e.g. 
> {{qpid:SCRAM-SHA256/myscramprovider}}).  For some providers, such as 
> Kerberos, the realm must be supplied by the user.
> The Principals produced by the authentication and group providers must carry 
> the realm.  The serialised form of the Principal will be a string where the 
> {{uriEscape(name) + '@' + domain}}.  Principal equality must include the 
> realm too.
> For this change. ConfiguredObject#createdBy/lastUpdatedBy remain Strings (for 
> now).
> Existing ACL rules consider only a principal's name, so existing ACL 
> behaviour should be unchanged by this change.



--
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-7246) Make ACL module realm aware

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7246:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-6.2

> Make ACL module realm aware
> ---
>
> Key: QPID-7246
> URL: https://issues.apache.org/jira/browse/QPID-7246
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> Make the existing ACL module realm aware.
> The parser will need to be adapted to accept realm qualified user/group 
> names.  Currently some symbols, such as the {{=}} and {{/}} within X500 
> realms will choke the parser.  Perhaps insisting that the name is quoted will 
> help?
> Change RuleSet#isRelevant() so that applicability of the rule is considers 
> realm in addition to the Principal's name.
> In order to ease upgrade, to allow existing ACL rules files to contain to 
> work without change, it may be better to allow an instance of AccessControl 
> to be associated with a default authentication provider and default group 
> provider.  If the ACL rule is written in term of of the identity without 
> realm, the authorisation engine would fallback to either of the two 
> associated providers,  thus a rule {{ACL ALLOW 'fred'...}} would be treated 
> as if it were {{ACL ALLOW 'f...@ldap.example.com'}}.  At configuration 
> upgrade time, if there is a singleton authentication provider and singleton 
> group provider, these would be associated with the Access Control Provider 
> automatically.



--
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-7093) Make the display of createdBy/lastUpdatedBy user information human readable

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7093:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-6.2

> Make the display of createdBy/lastUpdatedBy user information human readable
> ---
>
> Key: QPID-7093
> URL: https://issues.apache.org/jira/browse/QPID-7093
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> For some authentication providers, the id that represents a person is not 
> human readable.  For instance, when using the Google OAuth2, the identities 
> are 16 digit numbers.  This present a usability problem in the web management 
> console when viewing audit trail information createdBy/lastUpdateBy as the 
> operator will have no reasonable way to find out the name of the user that 
> created or updated an object.
> Authentication Providers will have the ability to resolve a userid into a 
> displayable name (QPID-7168).



--
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-7167) Make user/group names produced by LDAP authentication and group provider be realm qualified

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7167:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-6.2

> Make user/group names produced by LDAP authentication and group provider be 
> realm qualified
> ---
>
> Key: QPID-7167
> URL: https://issues.apache.org/jira/browse/QPID-7167
> Project: Qpid
>  Issue Type: Sub-task
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> For the LDAP provider, identities (users/groups) produced should be in the 
> form:
> {noformat}{identity}@{realm}{noformat}
> where identity is the distinguished name of the user which has been encoded 
> (how?).  The realm should be any valid realm defined by Section 6 RFC-4120.
> For the LDAP Provider, the realm could be defaulted, perhaps to be the full 
> qualified host name of the LDAP server itself.



--
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-7092) User identity must be unique

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7092:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-6.2

> User identity must be unique
> 
>
> Key: QPID-7092
> URL: https://issues.apache.org/jira/browse/QPID-7092
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> The Java Broker's model has an authentication provider associated with each 
> port.  This means that a single Broker may be configured to use more than 
> authentication provider at once.  For instance, it would be possible to use 
> LDAP authentication for messaging connections and use OAUTH2 for management.
> Currently a user's identity within the Broker represented by a simple name 
> (string).  This approach gives rise to the possibility of a conflict: a user 
> 'fred' from an authentication provider A may not be the same person as user 
> 'fred' from authentication system B.  At the moment the group provider 
> implementations and access control can not distinguish.  
> Authentication providers need to have the ability to produce a unique stable 
> identifier for each user.Group providers and access control providers 
> need a mechanism ability to act for only identities from a particular 
> authentication provider source(s).  



--
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-7166) Make user/group names produced by authentication and group providers realm qualified

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7166:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-6.2

> Make user/group names produced by authentication and group providers realm 
> qualified
> 
>
> Key: QPID-7166
> URL: https://issues.apache.org/jira/browse/QPID-7166
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> Change the existing authentication providers/group providers to produce 
> principals contain a realm qualified names.
> The realm qualified name will be in the form: 
> {noformat}{identity}@{realm}{noformat}  The identity and realm will need to 
> be encoded (how?).
> The formation of the realm name will follow Section 6 RFC-4120. Ultimately 
> all authentication and group providers will have an {{realmName}}.  The 
> Broker will enforce a business rule that all realm names are unique.
> Some authentication provides will capable of defaulting the realm name.  For 
> instance, an LDAP authentication provider might default its realm name to be 
> the full qualified domain name of the LDAP server itself.  If the provider 
> has a default, this must be overridable, to allow duplicate realm names to be 
> avoided.
> https://cwiki.apache.org/confluence/display/qpid/Identity+in+the+Java+Broker



--
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-6986) Management: Users should not be able to view an object to which they have no access

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-6986:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-6.2

> Management: Users should not be able to view an object to which they have no 
> access
> ---
>
> Key: QPID-6986
> URL: https://issues.apache.org/jira/browse/QPID-6986
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> In a managed service scenario, a single Broker may hosts applications 
> belonging to different groups.   For management purposes, an operator needs 
> to be able to enter the management console and check on queues, messages, 
> exchanges etc of his application.
> However, the Broker should have the ability to restrict an operator from 
> viewing the objects of a virtual host to which he has no access permission.  
> Currently the Broker enforces CRUD permissions on all objects in the 
> hierarchy, but this does not impose restrictions on *view*.
> The view restriction needs to apply to the Web Management Console and the 
> REST-API.
> An interesting case is Connections.  Connections are children on a Port but 
> become associated with a Virtualhost.  A management user with access 
> permission a virtual host needs to be able to see the connections associated 
> with that virtual host, even if he doesn't have permission to view the Broker 
> or Port directly.
>  



--
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-6989) Define an initial profile that defines a fixed password

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-6989:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-6.2

> Define an initial profile that defines a fixed password
> ---
>
> Key: QPID-6989
> URL: https://issues.apache.org/jira/browse/QPID-6989
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> Chiefly for development use-cases, define an initial profile that defines a 
> Sha256 authentication provider with a well know username/password guest:guest.
> This profile will also require AES256 configuration encryption.



--
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-6987) Define an initial profile which uses an OTP authentication provider

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-6987:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-6.2

> Define an initial profile which uses an OTP authentication provider
> ---
>
> Key: QPID-6987
> URL: https://issues.apache.org/jira/browse/QPID-6987
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> In order to make the Broker more secure out  of the box, the Broker should 
> support an initial profile that configures a 
> {{OneTimePasswordAuthenticationProvider}} as its only authentication 
> provider.  On startup this authentication provider will generate a OTP which 
> is printed to standard out, which remains valid for this Broker invocation 
> only.  The user would then use the one-time password to access the Broker, 
> and replace the authentication provider with one of their choosing. 



--
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-6988) Define an anonymous Broker initial profile and make this the default

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-6988:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-6.2

> Define an anonymous Broker initial profile and make this the default
> 
>
> Key: QPID-6988
> URL: https://issues.apache.org/jira/browse/QPID-6988
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> Switch the Java Broker's default configuration to use the anonymous 
> authentication provider.  Remove the {{etc/passwd}} directory from the 
> distribution.
> config-systests.json should continue to use password authentication, but it 
> should be switch to use a {{PlainAuthenticationProvider}}



--
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-7104) [Java Broker] Creating multiple state transition methods on a ConfiguredObject should cause an error

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7104:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-7.0.0

> [Java Broker] Creating multiple state transition methods on a 
> ConfiguredObject should cause an error
> 
>
> Key: QPID-7104
> URL: https://issues.apache.org/jira/browse/QPID-7104
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.32, qpid-java-6.0
>Reporter: Lorenz Quack
> Fix For: qpid-java-7.0.0
>
>
> Currently nothing prevents one from annotating several methods with the same 
> @StateTransition. However, the behaviour is not well defined.
> Ideally, we would catch this during compile-time.



--
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-7125) [Java Broker] REST API return code when deleting a resource which does not exist

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7125:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-6.2

> [Java Broker] REST API return code when deleting a resource which does not 
> exist
> 
>
> Key: QPID-7125
> URL: https://issues.apache.org/jira/browse/QPID-7125
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Rob Godfrey
>Priority: Minor
> Fix For: qpid-java-6.2
>
>
> From this mail: 
> http://qpid.2158936.n2.nabble.com/potential-java-broker-REST-API-bug-tp7639681.html
>  
> {quote}
> A DELETE request, if not resulting in an error, will always return HTTP 
> status 200 and no body content, no matter if a queue with that name exists or 
> not
> {quote}
> There seem to be a number of views on the correct behaviour here in REST 
> APIs, based somewhat on how one interprets the notion of idempotence.
> See for example 
> http://stackoverflow.com/questions/23486992/rest-api-proper-http-status-code-for-invalid-delete
>   and 
> http://stackoverflow.com/questions/6439416/deleting-a-resource-using-http-delete
>  
> http://www.restapitutorial.com/lessons/httpmethods.html suggests 404 for such 
> a case, but also points mentions how 204 (empty body) and 200 (which maybe 
> should return the representation of the deleted entity) can be used in the 
> non failure 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] (QPID-7138) [Java Broker] Broker should detect duplicate IDs in configured objects

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7138:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-7.0.0

> [Java Broker] Broker should detect duplicate IDs in configured objects
> --
>
> Key: QPID-7138
> URL: https://issues.apache.org/jira/browse/QPID-7138
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: 0.28, 0.30, 0.32, qpid-java-6.0, qpid-java-6.0.1
>Reporter: Alex Rudyy
> Fix For: qpid-java-7.0.0
>
>
> Currently UUID uniqueness is enforced only amongst immediate siblings.  This 
> means that, say, a virtual host with queue with UUID A would reject a second 
> queue with the same UUID A.  Currently if a second virtual host had a queue 
> with same UUID A, this would be allowed.  This presents a problem for clients 
> (including the Web Management Console) that expect UUID to be universally 
> unique.
> Change ACO so that object UUID are universally so.The validatation would 
> need to be applied as new objects are created, as the Broker starts up and as 
> Virtualhosts are recovered.  This latter may or may not be at start-up time.



--
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-7272) [Java Broker] Direct memory QpidByteBuffer created in message conversion modules should be disposed as soon as possible after becoming unused

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7272:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-7.0.0

> [Java Broker] Direct memory QpidByteBuffer created in message conversion 
> modules should be disposed as soon as possible after becoming unused
> -
>
> Key: QPID-7272
> URL: https://issues.apache.org/jira/browse/QPID-7272
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0
>Reporter: Alex Rudyy
> Fix For: qpid-java-7.0.0
>
>
> Direct memory QpidByteBuffer in 
> MessageConverter_to_1_0#convertServerMessage(...) is not disposed 
> programmatically. We rely on GC to release it from memory when it became 
> unused. There is a risk that when such QpidByteBuffers are not "garbage 
> collected" soon enough Broker might run out of direct memory on heavy loads.
> Currently a user who relies heavily of message conversion with high rates of 
> message flow, may see an OOM direct.



--
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-7194) Give client an ordered preferences to drive AMQP protocol selection

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7194:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-7.0.0

> Give client an ordered preferences to drive AMQP protocol selection
> ---
>
> Key: QPID-7194
> URL: https://issues.apache.org/jira/browse/QPID-7194
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-7.0.0
>
>
> Give the client an optional configuration parameter (system property and/or 
> connection url property), that allows it to drive AMQP selection by an 
> ordered preference list.



--
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-7197) Prevent deletion of objects that are in use

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7197:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-6.2

> Prevent deletion of objects that are in use
> ---
>
> Key: QPID-7197
> URL: https://issues.apache.org/jira/browse/QPID-7197
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> Enhance the facilities of the CO framework to prevent the deletion of the 
> objects that are in use elsewhere in the model.  Specifically this means 
> searching for other COs that have an attribute that refers to the object that 
> is about to be deleted,.  



--
This message was sent by Atlassian JIRA
(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-7279) [Java Broker] with config encryption creating a JDBC VirtualHost fails

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7279:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-6.2

> [Java Broker] with config encryption creating a JDBC VirtualHost fails
> --
>
> Key: QPID-7279
> URL: https://issues.apache.org/jira/browse/QPID-7279
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.2
>
>
> If configuration encryption is enabled on the broker creating a JDBC 
> VirtualHost via the WMC fails with the following error:
> {{422 - Encrypted value is not valid Base 64 data: 'myPassword'}}
> Also we might not want to log the content of the invalid data due to its 
> potential sensitive nature.



--
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-7289) [Java Broker] SASL challenges and response should be masked in the log file

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7289:
-
Fix Version/s: (was: qpid-java-6.1)
   qpid-java-6.2

> [Java Broker] SASL challenges and response should be masked in the log file
> ---
>
> Key: QPID-7289
> URL: https://issues.apache.org/jira/browse/QPID-7289
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.3, qpid-java-6.1
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.2
>
>
> The broker logs the SAL negotiation at DEBUG level. This includes the 
> challenges and response going between the client and the broker.
> These contain potentially sensitive information (e.g., user credentials) and 
> should therefore be masked.
> On AMQP 0-9 they are masked.
> On AMQP 0-10 they are not masked.
> I did not test 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] [Updated] (QPID-7287) Query parser fails silently with expression such as a + b

[Keith Wall (JIRA)]

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

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

> Query parser fails silently with expression such as a + b
> -
>
> Key: QPID-7287
> URL: https://issues.apache.org/jira/browse/QPID-7287
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.1
>
>
> There is a defect in the order-by (and select) parsing when the input is in 
> the form a + b.  It seems the parser fails, but the exception is not reported 
> back  to the client, nor it is reported to the logs.



--
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-7116) Ability to utilise group information from a LDAP compatible directory

[Keith Wall (JIRA)]

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

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

Documentation looks reasonable too.

> Ability to utilise group information from a LDAP compatible directory
> -
>
> Key: QPID-7116
> URL: https://issues.apache.org/jira/browse/QPID-7116
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.1
>
> Attachments: 0001-WIP-unification.patch, 0002-WIP-LDAP-groups.patch
>
>
> The Java Broker can already authenticate users against an LDAP compatible 
> directory.  It should also be able to use the same information source as a 
> source of group information too.
> The authentication provide needs to accept optional attributes governing 
> where the group information will be found:
> {{groupSearchContext}} - the base entry for the role search. If not 
> specified, the search base is the top-level directory context.
> {{groupSearchFilter}} - the LDAP search filter for selecting group entries.  
> A {0} token within the filter will be replaced by the distinguish name of the 
> authenticated user.
> {{groupAttributeName}} - the name of the attribute that contains the name of 
> the role.
> After the authentication provider has successfully bound (authenticated) the 
> user, it should perform a second query for the groups.  It should build a 
> {{GroupPrincipal}} for each group to which the user belongs and return this 
> as part of the AuthenticationResult.   If the group search attributes are not 
> found, the group search should be skipped.
> A future version if the LDAP Authentication Provider may offer the ability to 
> cache the group results for a DN period of time.  This would serve to avoid 
> hitting the Directory several times authentication (it already hits the 
> Directory twice if {{bindWithoutSearch}} is false, this will add a third).



--
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-7274) [Java Client] Asynchronous client acknowledgements

[Jakub Scholz (JIRA)]

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

Jakub Scholz commented on QPID-7274:


Hi Keith,

I tested this with AMQP 0-10 and it works perfectly. Thanks for looking into it.

Jakub

> [Java Client] Asynchronous client acknowledgements
> --
>
> Key: QPID-7274
> URL: https://issues.apache.org/jira/browse/QPID-7274
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Reporter: Jakub Scholz
>Assignee: Alex Rudyy
> Fix For: qpid-java-6.1
>
> Attachments: sync_ack.patch
>
>
> When the application is using client acknowledgements, they are always done 
> in a synchronous way with a sync() being issues after the acknowledgement. 
> This can have significant impact on the performance of the client 
> applications and it should be possible to configure the client to use 
> asynchronous acknowledgements.
> The Java AMQP 0-10 client has already a connection URL option called 
> "sync_ack" which should affect whether acknowledgements are synchronous or 
> asynchronous, but it is used only for auto acknowledgements. It has no effect 
> to client acknowledgements.
> Attached is a (trivial) patch which synchronizes the acknowledgements based 
> on the sync_ack option. It seems to work fine. However, the sync_ack option 
> is by default set to false. So using this option would mean that the current 
> behavior would change for all current applications using client 
> acknowledgements. I'm not sure that is desired. Would it be better to add a 
> new option "sync_client_ack" for the client acknowledgements which would sync 
> by default? Please let me know what the preferred option is and I can update 
> the patch.



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