[jira] [Created] (QPID-7679) Memory leak in DirectExchange
Cliff Jansen created QPID-7679: -- Summary: Memory leak in DirectExchange Key: QPID-7679 URL: https://issues.apache.org/jira/browse/QPID-7679 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: qpid-cpp-0.34 Reporter: Cliff Jansen Assignee: Cliff Jansen The Exchange::unbind call for DirectExchange is coded assuming that the binding actually exists. If the binding does not exist, this has the side effect of creating a Bindingkey in the BindingKey map that remains in the map until broker exit. The management count of bindings is not updated so there is no indication there of the problem. A well behaved 0_10 program that creates a queue, creates a direct binding, deletes the binding and then deletes the queue results in a second implicit unbind when the queue is deleted (usually on the QueueDeleteBody, but if an autodelete queue, it can also happen on the MessageCancelBody ending a subscription). TopicExchange and FanOutExchange explicitly guard against non-existence of the binding/queue pair on unbind(). Presumably, DirectExchange should do the same. HeadersExchange doesn't check but doesn't "remember" the pair. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1312) BlockingConnection leaks Proton-C memory
[ https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1312. -- Resolution: Fixed > BlockingConnection leaks Proton-C memory > > > Key: PROTON-1312 > URL: https://issues.apache.org/jira/browse/PROTON-1312 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9, 0.15.0 >Reporter: Cliff Jansen > Assignee: Cliff Jansen > Labels: leak, reproducer > Fix For: 0.17.0 > > Attachments: ml8.py > > > The attached program leaks the underlying connection (the C proton > object) associated with the BlockingConnection on each loop iteration > on proton 0.9 as used by Satellite. Without the receiver, it cleans > up fine. > On master, the program leaks both the reactor and the connection > associated with the BlockingConnection for each loop. The receiver > creation can be commented out and it still leaks both objects. > Other objects may leak too (presumably session), but I have not > examined further. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1378) Two reactor final events generated
[ https://issues.apache.org/jira/browse/PROTON-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1378. -- Resolution: Fixed > Two reactor final events generated > -- > > Key: PROTON-1378 > URL: https://issues.apache.org/jira/browse/PROTON-1378 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.16.0 >Reporter: Cliff Jansen > Assignee: Cliff Jansen > Fix For: 0.17.0 > > > pn_reactor_process will insert a second PN_REACTOR_FINAL into the collector > in pn_reactor_run. This is mostly harmless but leaves a reference to the > reactor. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1378) Two reactor final events generated
Cliff Jansen created PROTON-1378: Summary: Two reactor final events generated Key: PROTON-1378 URL: https://issues.apache.org/jira/browse/PROTON-1378 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.16.0 Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.17.0 pn_reactor_process will insert a second PN_REACTOR_FINAL into the collector in pn_reactor_run. This is mostly harmless but leaves a reference to the reactor. -- 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-1340) [Visual Studio 2013] Event_loop injection triggers an exception when the container is being destroyed
[ https://issues.apache.org/jira/browse/PROTON-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648676#comment-15648676 ] Cliff Jansen commented on PROTON-1340: -- Yes this should be fixed as part of 0.16. That is the intention. Previous attempts to make the Windows code behave like the Linux version have had mixed results, with injection a known outage. Fixes were being worked on but were suspended when the new experimental connection_engine was emerging, since it provided a better target for a clean multithreaded model that was not Posix-centric. I have raised https://issues.apache.org/jira/browse/PROTON-1349 for the more general work. As workable Windows snapshots are available I will post there. I will keep this open until a working inject example is available on master. > [Visual Studio 2013] Event_loop injection triggers an exception when the > container is being destroyed > - > > Key: PROTON-1340 > URL: https://issues.apache.org/jira/browse/PROTON-1340 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.14.0 >Reporter: Adel Boutros >Assignee: Cliff Jansen > Labels: windows > Fix For: 0.16.0 > > > Full details here: > http://qpid.2158936.n2.nabble.com/Proton-c-0-14-0-Visual-Studio-2013-Exception-when-destroying-the-container-impl-after-using-the-evenp-td7653029.html > We have the exception when building in RelWithDebInfo mode -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1349) C "proactor" implementation on windows
Cliff Jansen created PROTON-1349: Summary: C "proactor" implementation on windows Key: PROTON-1349 URL: https://issues.apache.org/jira/browse/PROTON-1349 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.16.0 Provide the Windows counterpart to the work in https://issues.apache.org/jira/browse/PROTON-1344 Including a thread safe inject. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1312) BlockingConnection leaks Proton-C memory
[ https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated PROTON-1312: - Attachment: ml8.py > BlockingConnection leaks Proton-C memory > > > Key: PROTON-1312 > URL: https://issues.apache.org/jira/browse/PROTON-1312 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9, 0.15.0 >Reporter: Cliff Jansen > Attachments: ml8.py > > > The attached program leaks the underlying connection (the C proton > object) associated with the BlockingConnection on each loop iteration > on proton 0.9 as used by Satellite. Without the receiver, it cleans > up fine. > On master, the program leaks both the reactor and the connection > associated with the BlockingConnection for each loop. The receiver > creation can be commented out and it still leaks both objects. > Other objects may leak too (presumably session), but I have not > examined further. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1312) BlockingConnection leaks Proton-C memory
Cliff Jansen created PROTON-1312: Summary: BlockingConnection leaks Proton-C memory Key: PROTON-1312 URL: https://issues.apache.org/jira/browse/PROTON-1312 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9, 0.15.0 Reporter: Cliff Jansen The attached program leaks the underlying connection (the C proton object) associated with the BlockingConnection on each loop iteration on proton 0.9 as used by Satellite. Without the receiver, it cleans up fine. On master, the program leaks both the reactor and the connection associated with the BlockingConnection for each loop. The receiver creation can be commented out and it still leaks both objects. Other objects may leak too (presumably session), but I have not examined further. -- 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-7393) Unavailable buffers in Windows SSL
[
https://issues.apache.org/jira/browse/QPID-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen resolved QPID-7393.
Resolution: Fixed
> Unavailable buffers in Windows SSL
> --
>
> Key: QPID-7393
> URL: https://issues.apache.org/jira/browse/QPID-7393
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker, C++ Client
>Affects Versions: qpid-cpp-1.35.0
> Environment: Windows SChannel
> Reporter: Cliff Jansen
>Assignee: Cliff Jansen
> Fix For: qpid-cpp-1.35.0
>
>
> From the user list (acartcat cartwright_and...@cat.com):
> > I get the following error in the broker, looks like the same error as
> > QPID-5033.
> [...]
> > 2016-05-26 05:22:23 [System] error No IO buffers available: getQueuedBuffer
> > with empty queue. Debug data: 0 1 0 3 0 0 1
> [...]
> > This can be triggered on demand using:
> > qpid-send -b ssl:.com:5671 --connection-options {protocol:amqp1.0}
> > -a testerq --content-string=hello --messages 200
> In my testing, qpid-send must also be Windows based. I do not see the error
> if it is sent from a client running on Linux.
> This error is caused by the SChannel driver generating (valid but
> useless) empty SSL packets when a zero length write is requested from
> the codec on the client side. On the server side, these are
> processed and empty read callbacks are generated, even after close.
> The WSAENOBUFS happens as a side effect of recursive calls to
> sslDataIn while processing adjacent empty packets.
--
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-7393) Unavailable buffers in Windows SSL
Cliff Jansen created QPID-7393:
--
Summary: Unavailable buffers in Windows SSL
Key: QPID-7393
URL: https://issues.apache.org/jira/browse/QPID-7393
Project: Qpid
Issue Type: Bug
Components: C++ Broker, C++ Client
Affects Versions: qpid-cpp-1.35.0
Environment: Windows SChannel
Reporter: Cliff Jansen
Assignee: Cliff Jansen
Fix For: qpid-cpp-1.35.0
>From the user list (acartcat cartwright_and...@cat.com):
> I get the following error in the broker, looks like the same error as
> QPID-5033.
[...]
> 2016-05-26 05:22:23 [System] error No IO buffers available: getQueuedBuffer
> with empty queue. Debug data: 0 1 0 3 0 0 1
[...]
> This can be triggered on demand using:
> qpid-send -b ssl:.com:5671 --connection-options {protocol:amqp1.0}
> -a testerq --content-string=hello --messages 200
In my testing, qpid-send must also be Windows based. I do not see the error
if it is sent from a client running on Linux.
This error is caused by the SChannel driver generating (valid but
useless) empty SSL packets when a zero length write is requested from
the codec on the client side. On the server side, these are
processed and empty read callbacks are generated, even after close.
The WSAENOBUFS happens as a side effect of recursive calls to
sslDataIn while processing adjacent empty packets.
--
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-7373) memory leak in broker with idle worker threads
[
https://issues.apache.org/jira/browse/QPID-7373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen resolved QPID-7373.
Resolution: Fixed
see also https://reviews.apache.org/r/50759/
> memory leak in broker with idle worker threads
> --
>
> Key: QPID-7373
> URL: https://issues.apache.org/jira/browse/QPID-7373
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: qpid-cpp-0.34
> Environment: linux epoll and perhaps PosixPoller and Solaris ECFPoller
> Reporter: Cliff Jansen
>Assignee: Cliff Jansen
>
> If a C++ broker is lightly loaded with many short lived connections such that
> at least one worker thread remains unwoken from the epoll_wait, its
> DeletionManager::ThreadStatus::handles grows without bound and the associated
> handles retain a shared_ptr ref and never go away.
> To reproduce check RSS from ps (or malloc_stats) when running a simple
> program that creates a connection and nothing else:
> hex5: cat foo.cpp
> {code}
> #include
> #include
> using namespace qpid::messaging;
> int main(int argc, char** argv) {
> std::string broker = argc > 1 ? argv[1] : "127.0.0.1:5672";
> Connection connection(broker);
> try {
> connection.open();
> connection.close();
> return 0;
> } catch(const std::exception& error) {
> std::cerr << error.what() << std::endl;
> connection.close();
> return 1;
> }
> }
> {code}
> hex5: while true; do LD_LIBRARY_PATH=../rt/b/amqp/b/q35x/rt/lib64 ./foo ;
> done
--
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 50759: Force periodic cleanup of EpollPoller memory
> On Aug. 4, 2016, 2:57 p.m., Andrew Stitcher wrote:
> > src/qpid/sys/epoll/EpollPoller.cpp, line 573
> > <https://reviews.apache.org/r/50759/diff/2/?file=1462305#file1462305line573>
> >
> > Tiny quibble:
> >
> > Could be
> >
> > if (now_ >= targetTimeout) ...
I tried that first! There is no >= operator in AbsTime.
> On Aug. 4, 2016, 2:57 p.m., Andrew Stitcher wrote:
> > src/qpid/sys/epoll/EpollPoller.cpp, line 568
> > <https://reviews.apache.org/r/50759/diff/2/?file=1462305#file1462305line568>
> >
> > formatting suggestion:
> >
> > Move line 571 to here
> > AbsTime now_(now());
> > Even though it's not logically needed here.
> >
> > Because, then you can make this neater by formatting it as
> >
> > if (timeout ...) {
> > timeoutMs = ...
> > } else if (now_ ...) {
> > timeoutMs = ...
> > } else {
> > ...
> > timeoutMS = ...
> > }
> >
> > Which I think is a clearer expression of the code.
Will do.
- Cliff
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/50759/#review144765
---
On Aug. 4, 2016, 3:32 a.m., Cliff Jansen wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50759/
> ---
>
> (Updated Aug. 4, 2016, 3:32 a.m.)
>
>
> Review request for qpid and Andrew Stitcher.
>
>
> Bugs: qpid-7373
> https://issues.apache.org/jira/browse/qpid-7373
>
>
> Repository: qpid-cpp
>
>
> Description
> ---
>
> If a C++ broker is lightly loaded with many short lived connections such that
> at least one worker thread remains unwoken from the epoll_wait, its
> DeletionManager::ThreadStatus::handles grows without bound and the associated
> handles retain a shared_ptr ref and never go away.
>
> This patch allows IO threads a maximum of one minute to accumulate
> DeletionManager shared pointer references before resuming the wait loop which
> involves calling
>
> PollerHandleDeletionManager.markAllUnusedInThisThread();
>
> The overhead is small on brokers light thread load and non-existent on busy
> brokers.
>
>
> Diffs
> -
>
> src/qpid/sys/epoll/EpollPoller.cpp 6fdf996
>
> Diff: https://reviews.apache.org/r/50759/diff/
>
>
> Testing
> ---
>
> Jira test case, PollerTest.cpp
>
>
> Thanks,
>
> Cliff Jansen
>
>
Re: Review Request 50759: Force periodic cleanup of EpollPoller memory
> On Aug. 3, 2016, 7:07 p.m., Chug Rolke wrote: > > src/qpid/sys/epoll/EpollPoller.cpp, line 552 > > <https://reviews.apache.org/r/50759/diff/1/?file=1461569#file1461569line552> > > > > Before these changes the code was very friendly to low power > > configurations by not waking up unnecessarily. Now it wakes up once a > > minute regardless which might be enough to never let the host get to sleep. > > > > How about waking up once an hour or once every three hours? the test case causes memory growth of 50MB per hour. One minute is probably a decent balance. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/50759/#review144647 ------- On Aug. 4, 2016, 3:32 a.m., Cliff Jansen wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/50759/ > --- > > (Updated Aug. 4, 2016, 3:32 a.m.) > > > Review request for qpid and Andrew Stitcher. > > > Bugs: qpid-7373 > https://issues.apache.org/jira/browse/qpid-7373 > > > Repository: qpid-cpp > > > Description > --- > > If a C++ broker is lightly loaded with many short lived connections such that > at least one worker thread remains unwoken from the epoll_wait, its > DeletionManager::ThreadStatus::handles grows without bound and the associated > handles retain a shared_ptr ref and never go away. > > This patch allows IO threads a maximum of one minute to accumulate > DeletionManager shared pointer references before resuming the wait loop which > involves calling > > PollerHandleDeletionManager.markAllUnusedInThisThread(); > > The overhead is small on brokers light thread load and non-existent on busy > brokers. > > > Diffs > - > > src/qpid/sys/epoll/EpollPoller.cpp 6fdf996 > > Diff: https://reviews.apache.org/r/50759/diff/ > > > Testing > --- > > Jira test case, PollerTest.cpp > > > Thanks, > > Cliff Jansen > >
Re: Review Request 50759: Force periodic cleanup of EpollPoller memory
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/50759/ --- (Updated Aug. 4, 2016, 3:32 a.m.) Review request for qpid and Andrew Stitcher. Changes --- Incorporating most suggestions but dealing with test issues: truncation when converting to millisecs and negative durations. see response to https://reviews.apache.org/r/50759/#comment210664 Bugs: qpid-7373 https://issues.apache.org/jira/browse/qpid-7373 Repository: qpid-cpp Description --- If a C++ broker is lightly loaded with many short lived connections such that at least one worker thread remains unwoken from the epoll_wait, its DeletionManager::ThreadStatus::handles grows without bound and the associated handles retain a shared_ptr ref and never go away. This patch allows IO threads a maximum of one minute to accumulate DeletionManager shared pointer references before resuming the wait loop which involves calling PollerHandleDeletionManager.markAllUnusedInThisThread(); The overhead is small on brokers light thread load and non-existent on busy brokers. Diffs (updated) - src/qpid/sys/epoll/EpollPoller.cpp 6fdf996 Diff: https://reviews.apache.org/r/50759/diff/ Testing --- Jira test case, PollerTest.cpp Thanks, Cliff Jansen
Re: Review Request 50759: Force periodic cleanup of EpollPoller memory
> On Aug. 3, 2016, 6:33 p.m., Andrew Stitcher wrote: > > src/qpid/sys/epoll/EpollPoller.cpp, line 669 > > <https://reviews.apache.org/r/50759/diff/1/?file=1461569#file1461569line669> > > > > I think it would be easier to understand all the timer manipulations to > > put something like: > > > > timeoutMs = std::min(Duration(now(), targetTimeout)/TIME_MSEC, > > maxEpollWait); > > > > [Or you could make maxEpollWait a Duration which might be neater and do: > > > > timeoutMs = std::min(Duration(now(), targetTimeout), maxEpollWait) / > > TIME_MSEC; > > > > which I think should work because of the implicit conversion from > > Duration->int64_t.] > > > > at the top of the loop and remove the recalculation from here. I tried the latter, but ran into testing problems. If Duration(now(), targetTimeout) is not a multiple of TIME_MSEC, the wakeup is just before the targetTimeout and the code does successive waits with timeoutMs=0 until the clock moves past targetTimeout. I also had some weird example where now() was past targetTimeout and caused a negative duration. I will load a newer version for review. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/50759/#review144631 --- On Aug. 3, 2016, 5:43 p.m., Cliff Jansen wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/50759/ > --- > > (Updated Aug. 3, 2016, 5:43 p.m.) > > > Review request for qpid and Andrew Stitcher. > > > Bugs: qpid-7373 > https://issues.apache.org/jira/browse/qpid-7373 > > > Repository: qpid-cpp > > > Description > --- > > If a C++ broker is lightly loaded with many short lived connections such that > at least one worker thread remains unwoken from the epoll_wait, its > DeletionManager::ThreadStatus::handles grows without bound and the associated > handles retain a shared_ptr ref and never go away. > > This patch allows IO threads a maximum of one minute to accumulate > DeletionManager shared pointer references before resuming the wait loop which > involves calling > > PollerHandleDeletionManager.markAllUnusedInThisThread(); > > The overhead is small on brokers light thread load and non-existent on busy > brokers. > > > Diffs > - > > src/qpid/sys/epoll/EpollPoller.cpp 6fdf996 > > Diff: https://reviews.apache.org/r/50759/diff/ > > > Testing > --- > > Jira test case, PollerTest.cpp > > > Thanks, > > Cliff Jansen > >
Review Request 50759: Force periodic cleanup of EpollPoller memory
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/50759/ --- Review request for qpid and Andrew Stitcher. Bugs: qpid-7373 https://issues.apache.org/jira/browse/qpid-7373 Repository: qpid-cpp Description --- If a C++ broker is lightly loaded with many short lived connections such that at least one worker thread remains unwoken from the epoll_wait, its DeletionManager::ThreadStatus::handles grows without bound and the associated handles retain a shared_ptr ref and never go away. This patch allows IO threads a maximum of one minute to accumulate DeletionManager shared pointer references before resuming the wait loop which involves calling PollerHandleDeletionManager.markAllUnusedInThisThread(); The overhead is small on brokers light thread load and non-existent on busy brokers. Diffs - src/qpid/sys/epoll/EpollPoller.cpp 6fdf996 Diff: https://reviews.apache.org/r/50759/diff/ Testing --- Jira test case, PollerTest.cpp Thanks, Cliff Jansen
[jira] [Created] (QPID-7373) memory leak in broker with idle worker threads
Cliff Jansen created QPID-7373:
--
Summary: memory leak in broker with idle worker threads
Key: QPID-7373
URL: https://issues.apache.org/jira/browse/QPID-7373
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: qpid-cpp-0.34
Environment: linux epoll and perhaps PosixPoller and Solaris ECFPoller
Reporter: Cliff Jansen
Assignee: Cliff Jansen
If a C++ broker is lightly loaded with many short lived connections such that
at least one worker thread remains unwoken from the epoll_wait, its
DeletionManager::ThreadStatus::handles grows without bound and the associated
handles retain a shared_ptr ref and never go away.
To reproduce check RSS from ps (or malloc_stats) when running a simple program
that creates a connection and nothing else:
hex5: cat foo.cpp
{code}
#include
#include
using namespace qpid::messaging;
int main(int argc, char** argv) {
std::string broker = argc > 1 ? argv[1] : "127.0.0.1:5672";
Connection connection(broker);
try {
connection.open();
connection.close();
return 0;
} catch(const std::exception& error) {
std::cerr << error.what() << std::endl;
connection.close();
return 1;
}
}
{code}
hex5: while true; do LD_LIBRARY_PATH=../rt/b/amqp/b/q35x/rt/lib64 ./foo ; done
--
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
Review Request 50574: make messaging_handler copyable
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/50574/ --- Review request for qpid and Andrew Stitcher. Bugs: PROTON-1241 https://issues.apache.org/jira/browse/PROTON-1241 Repository: qpid-proton-git Description --- Rework messaging_handler to elliminate delete reference to messaging_adapter from header files. deal with event flow in copy case versus move case. Add test Diffs - proton-c/bindings/cpp/CMakeLists.txt 1561134 proton-c/bindings/cpp/include/proton/messaging_handler.hpp 8520846 proton-c/bindings/cpp/src/handler.cpp cda8acb proton-c/bindings/cpp/src/handler_test.cpp PRE-CREATION proton-c/bindings/cpp/src/messaging_adapter.hpp 846b466 proton-c/bindings/cpp/src/messaging_adapter.cpp 37fc4e0 Diff: https://reviews.apache.org/r/50574/diff/ Testing --- ctest Thanks, Cliff Jansen
[jira] [Resolved] (PROTON-1267) Service Bus example
[ https://issues.apache.org/jira/browse/PROTON-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1267. -- Resolution: Fixed Example using Service Bus sessions. > Service Bus example > --- > > Key: PROTON-1267 > URL: https://issues.apache.org/jira/browse/PROTON-1267 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: 0.14.0 >Reporter: Cliff Jansen > Assignee: Cliff Jansen > Fix For: 0.14.0 > > > Provide a simple example using Microsoft Service Bus including some relevant > notes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1267) Service Bus example
Cliff Jansen created PROTON-1267: Summary: Service Bus example Key: PROTON-1267 URL: https://issues.apache.org/jira/browse/PROTON-1267 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Affects Versions: 0.14.0 Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.14.0 Provide a simple example using Microsoft Service Bus including some relevant notes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1264) on_receiver_open event after close
[ https://issues.apache.org/jira/browse/PROTON-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated PROTON-1264: - Attachment: slow_attach A Service Bus example trace. Note that it is normal for the responding attach to be delayed indefinitely since the attach frame filter content is populated from the next available message whenever it eventually arrives. > on_receiver_open event after close > -- > > Key: PROTON-1264 > URL: https://issues.apache.org/jira/browse/PROTON-1264 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.14.0 >Reporter: Cliff Jansen > Assignee: Cliff Jansen >Priority: Minor > Attachments: slow_attach > > > If the peer is slow to respond with its attach frame from a receiver open and > the initiator gives up and closes the receiver, the eventual attach frame > from the peer will generate an on_receiver_open() event. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1264) on_receiver_open event after close
Cliff Jansen created PROTON-1264: Summary: on_receiver_open event after close Key: PROTON-1264 URL: https://issues.apache.org/jira/browse/PROTON-1264 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: 0.14.0 Reporter: Cliff Jansen Assignee: Cliff Jansen Priority: Minor If the peer is slow to respond with its attach frame from a receiver open and the initiator gives up and closes the receiver, the eventual attach frame from the peer will generate an on_receiver_open() event. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1260) provide convenience operations for described types
Cliff Jansen created PROTON-1260: Summary: provide convenience operations for described types Key: PROTON-1260 URL: https://issues.apache.org/jira/browse/PROTON-1260 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Affects Versions: 0.14.0 Reporter: Cliff Jansen Assignee: Cliff Jansen Priority: Minor Manipulating described types is not a frequent activity, but currently requires using encoder/decoder classes to inspect/modify. See examples/cpp/selected_recv.cpp. Same issue for server side code. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1257) c++ cached_map core dump on assignment
[ https://issues.apache.org/jira/browse/PROTON-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen closed PROTON-1257. Resolution: Fixed > c++ cached_map core dump on assignment > -- > > Key: PROTON-1257 > URL: https://issues.apache.org/jira/browse/PROTON-1257 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.14.0 >Reporter: Cliff Jansen > Assignee: Cliff Jansen >Priority: Critical > Fix For: 0.14.0 > > > The copy created is deleted but the pn_unique_ptr still points to the > released memory. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1257) c++ cached_map core dump on assignment
Cliff Jansen created PROTON-1257: Summary: c++ cached_map core dump on assignment Key: PROTON-1257 URL: https://issues.apache.org/jira/browse/PROTON-1257 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: 0.14.0 Reporter: Cliff Jansen Assignee: Cliff Jansen The copy created is deleted but the pn_unique_ptr still points to the released memory. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1233) Windows schannel: match OpenSSL and require non-null hostname for PN_SSL_VERIFY_PEER_NAME
[ https://issues.apache.org/jira/browse/PROTON-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen closed PROTON-1233. Resolution: Fixed > Windows schannel: match OpenSSL and require non-null hostname for > PN_SSL_VERIFY_PEER_NAME > - > > Key: PROTON-1233 > URL: https://issues.apache.org/jira/browse/PROTON-1233 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Cliff Jansen > Assignee: Cliff Jansen > Fix For: 0.14.0 > > > A user should not be permitted to omit setting the peer hostname and use > verify peer name at the same 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] [Commented] (PROTON-1233) Windows schannel: match OpenSSL and require non-null hostname for PN_SSL_VERIFY_PEER_NAME
[ https://issues.apache.org/jira/browse/PROTON-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15323754#comment-15323754 ] Cliff Jansen commented on PROTON-1233: -- Commit 622dc1f fixes the problem doing some hand tests with the ssl.ccp example. I am leaving this JIRA open until a proper CI test is constructed along with the other Proton-C SSL tests. > Windows schannel: match OpenSSL and require non-null hostname for > PN_SSL_VERIFY_PEER_NAME > - > > Key: PROTON-1233 > URL: https://issues.apache.org/jira/browse/PROTON-1233 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Cliff Jansen > Assignee: Cliff Jansen > Fix For: 0.14.0 > > > A user should not be permitted to omit setting the peer hostname and use > verify peer name at the same 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] [Created] (PROTON-1234) Windows IO modules need updating to match Posix improvements
Cliff Jansen created PROTON-1234: Summary: Windows IO modules need updating to match Posix improvements Key: PROTON-1234 URL: https://issues.apache.org/jira/browse/PROTON-1234 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.14.0 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen The Posix IO and OpenSSL modules have had improvements not yet transferred to the Windows side. These include better error messages, logging and probably some basic bug fixes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1233) Windows schannel: match OpenSSL and require non-null hostname for PN_SSL_VERIFY_PEER_NAME
Cliff Jansen created PROTON-1233: Summary: Windows schannel: match OpenSSL and require non-null hostname for PN_SSL_VERIFY_PEER_NAME Key: PROTON-1233 URL: https://issues.apache.org/jira/browse/PROTON-1233 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.14.0 A user should not be permitted to omit setting the peer hostname and use verify peer name at the same 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] [Closed] (PROTON-1229) Document and test virtual_host option
[ https://issues.apache.org/jira/browse/PROTON-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen closed PROTON-1229. Resolution: Fixed > Document and test virtual_host option > - > > Key: PROTON-1229 > URL: https://issues.apache.org/jira/browse/PROTON-1229 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: 0.14.0 >Reporter: Cliff Jansen > Assignee: Cliff Jansen > Fix For: 0.14.0 > > > Enhance examples, CI, and user doc and source doc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1229) Document and test virtual_host option
Cliff Jansen created PROTON-1229: Summary: Document and test virtual_host option Key: PROTON-1229 URL: https://issues.apache.org/jira/browse/PROTON-1229 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Affects Versions: 0.14.0 Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.14.0 Enhance examples, CI, and user doc and source doc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1228) Windows schannel needs default peer_hostname to match OpenSSL
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] [Closed] (PROTON-1226) Handler not set on inbound connection
[ https://issues.apache.org/jira/browse/PROTON-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen closed PROTON-1226. Resolution: Fixed > Handler not set on inbound connection > - > > Key: PROTON-1226 > URL: https://issues.apache.org/jira/browse/PROTON-1226 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0, 0.14.0 >Reporter: Cliff Jansen > Assignee: Cliff Jansen > Fix For: 0.13.0 > > > Historically, the handler was always specified before the connection was > created so that the PN_CONNECTION_INIT could go to the correct handler, > whereas the rest of the connection options could only be applied later, after > creation. > For inbound connections, the handler was set on the listener > (pn_reactor_acceptor()) and the reactor set it for the accepted connections. > History has changed. Nobody processes PN_CONNECTION_INIT except the global > handler, so deferred setting of the handler is probably OK, allowing the > handler to be set at the same time as the other non-transport options. > Alternatively, the caller of on_accept() must separately apply the handler > (which might change per connection on a listener) to make the new > listen_handler interface work as intended. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1194) C++ flow control
[ https://issues.apache.org/jira/browse/PROTON-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen closed PROTON-1194. Resolution: Fixed Available in 0.13 Updated example for clarity based on feedback for 0.14 > C++ flow control > > > Key: PROTON-1194 > URL: https://issues.apache.org/jira/browse/PROTON-1194 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: 0.12.2 >Reporter: Cliff Jansen > Assignee: Cliff Jansen >Priority: Blocker > Fix For: 0.13.0 > > > Provide basic flow control primitives: receiver::add_credit, receiver::drain > and handler event callbacks to note drain begin and completion. -- 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-1226) Handler not set on inbound connection
[ https://issues.apache.org/jira/browse/PROTON-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15315632#comment-15315632 ] Cliff Jansen commented on PROTON-1226: -- I have a copy of the same fix in my copy of the 0.13 release branch: https://github.com/cliffjansen/qpid-proton/tree/cj13_pn1226 It compiles and runs ctest on rhel6 & 7 and Windows 7/VS 2008 Also the flow_control example runs fine with this patch. The code is largely cut and pasted from other Proton C++ binding code, so I think it is unlikely that it would introduce some new syntax error on some compiler. > Handler not set on inbound connection > - > > Key: PROTON-1226 > URL: https://issues.apache.org/jira/browse/PROTON-1226 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0, 0.14.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: 0.14.0 > > > Historically, the handler was always specified before the connection was > created so that the PN_CONNECTION_INIT could go to the correct handler, > whereas the rest of the connection options could only be applied later, after > creation. > For inbound connections, the handler was set on the listener > (pn_reactor_acceptor()) and the reactor set it for the accepted connections. > History has changed. Nobody processes PN_CONNECTION_INIT except the global > handler, so deferred setting of the handler is probably OK, allowing the > handler to be set at the same time as the other non-transport options. > Alternatively, the caller of on_accept() must separately apply the handler > (which might change per connection on a listener) to make the new > listen_handler interface work as intended. -- 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-1226) Handler not set on inbound connection
[ https://issues.apache.org/jira/browse/PROTON-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15314815#comment-15314815 ] Cliff Jansen commented on PROTON-1226: -- The CI test works fine with above fix. On further investigation, option 1 doesn't even make sense in the case of connection_engine, which does not use a pn_handler_t intermediary and doesn't want apply() to set any C reactor context on the connection. I originally thought option 1 might be the better option for consistency between connection_engine and container, but that is clearly not the case. For clarity, this fix correctly honours the connection_option handler for the connection as a whole. It does not address any outstanding issues related to providing separate handlers for links or sessions. > Handler not set on inbound connection > - > > Key: PROTON-1226 > URL: https://issues.apache.org/jira/browse/PROTON-1226 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0, 0.14.0 >Reporter: Cliff Jansen > Assignee: Cliff Jansen > Fix For: 0.14.0 > > > Historically, the handler was always specified before the connection was > created so that the PN_CONNECTION_INIT could go to the correct handler, > whereas the rest of the connection options could only be applied later, after > creation. > For inbound connections, the handler was set on the listener > (pn_reactor_acceptor()) and the reactor set it for the accepted connections. > History has changed. Nobody processes PN_CONNECTION_INIT except the global > handler, so deferred setting of the handler is probably OK, allowing the > handler to be set at the same time as the other non-transport options. > Alternatively, the caller of on_accept() must separately apply the handler > (which might change per connection on a listener) to make the new > listen_handler interface work as intended. -- 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-1226) Handler not set on inbound connection
[ https://issues.apache.org/jira/browse/PROTON-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15314717#comment-15314717 ] Cliff Jansen commented on PROTON-1226: -- sample fix of second option https://github.com/apache/qpid-proton/compare/master...cliffjansen:listenhandler?expand=1#diff-1faa8c5f11e957c69d44d45787689951 > Handler not set on inbound connection > - > > Key: PROTON-1226 > URL: https://issues.apache.org/jira/browse/PROTON-1226 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0, 0.14.0 >Reporter: Cliff Jansen > Assignee: Cliff Jansen > Fix For: 0.14.0 > > > Historically, the handler was always specified before the connection was > created so that the PN_CONNECTION_INIT could go to the correct handler, > whereas the rest of the connection options could only be applied later, after > creation. > For inbound connections, the handler was set on the listener > (pn_reactor_acceptor()) and the reactor set it for the accepted connections. > History has changed. Nobody processes PN_CONNECTION_INIT except the global > handler, so deferred setting of the handler is probably OK, allowing the > handler to be set at the same time as the other non-transport options. > Alternatively, the caller of on_accept() must separately apply the handler > (which might change per connection on a listener) to make the new > listen_handler interface work as intended. -- 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-1194) C++ flow control
[ https://issues.apache.org/jira/browse/PROTON-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15314707#comment-15314707 ] Cliff Jansen commented on PROTON-1194: -- Note that the CI test was disabled in 1b8450d. It should be reinstated (with fixed command line options) as soon as PROTON-1226 is resolved. > C++ flow control > > > Key: PROTON-1194 > URL: https://issues.apache.org/jira/browse/PROTON-1194 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: 0.12.2 >Reporter: Cliff Jansen > Assignee: Cliff Jansen > Fix For: 0.13.0 > > > Provide basic flow control primitives: receiver::add_credit, receiver::drain > and handler event callbacks to note drain begin and completion. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1226) Handler not set on inbound connection
Cliff Jansen created PROTON-1226: Summary: Handler not set on inbound connection Key: PROTON-1226 URL: https://issues.apache.org/jira/browse/PROTON-1226 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: 0.13.0, 0.14.0 Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.14.0 Historically, the handler was always specified before the connection was created so that the PN_CONNECTION_INIT could go to the correct handler, whereas the rest of the connection options could only be applied later, after creation. For inbound connections, the handler was set on the listener (pn_reactor_acceptor()) and the reactor set it for the accepted connections. History has changed. Nobody processes PN_CONNECTION_INIT except the global handler, so deferred setting of the handler is probably OK, allowing the handler to be set at the same time as the other non-transport options. Alternatively, the caller of on_accept() must separately apply the handler (which might change per connection on a listener) to make the new listen_handler interface work as intended. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1223) Windows connection errors are cryptic.
[ https://issues.apache.org/jira/browse/PROTON-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen closed PROTON-1223. Resolution: Fixed > Windows connection errors are cryptic. > -- > > Key: PROTON-1223 > URL: https://issues.apache.org/jira/browse/PROTON-1223 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.14.0 > Environment: Windows. > Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: 0.14.0 > > > If an example program such as helloworld requires a broker and the broker is > not running or it's address is mis-specified, the example fails with a > completely unhelpful assertion error in debug builds and a barely more > comprehensible error message in release builds alluding to a truncated frame. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1223) Windows connection errors are cryptic.
Cliff Jansen created PROTON-1223: Summary: Windows connection errors are cryptic. Key: PROTON-1223 URL: https://issues.apache.org/jira/browse/PROTON-1223 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: 0.14.0 Environment: Windows. Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.14.0 If an example program such as helloworld requires a broker and the broker is not running or it's address is mis-specified, the example fails with a completely unhelpful assertion error in debug builds and a barely more comprehensible error message in release builds alluding to a truncated frame. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1211) C++ binding exception in message::correlation_id()
[ https://issues.apache.org/jira/browse/PROTON-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen closed PROTON-1211. Resolution: Fixed Fix Version/s: 0.14.0 > C++ binding exception in message::correlation_id() > -- > > Key: PROTON-1211 > URL: https://issues.apache.org/jira/browse/PROTON-1211 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0, 0.14.0 >Reporter: Cliff Jansen > Assignee: Cliff Jansen >Priority: Blocker > Fix For: 0.13.0, 0.14.0 > > Attachments: msgid.cpp > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1213) Fix quick_perf_xx targets.
[ https://issues.apache.org/jira/browse/PROTON-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen closed PROTON-1213. Resolution: Fixed > Fix quick_perf_xx targets. > -- > > Key: PROTON-1213 > URL: https://issues.apache.org/jira/browse/PROTON-1213 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c, python-binding >Affects Versions: 0.14.0 >Reporter: Cliff Jansen > Assignee: Cliff Jansen > > The quick_perf targets for performance sanity checks have been broken > for some time. > The launch script for the quick_perf_c etc targets depended on other > test scripts which were re-written over time to fix race conditions > and python version variations. > This fix changes none of the logic, just uses the new conventions from > the other scripts. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1213) Fix quick_perf_xx targets.
Cliff Jansen created PROTON-1213: Summary: Fix quick_perf_xx targets. Key: PROTON-1213 URL: https://issues.apache.org/jira/browse/PROTON-1213 Project: Qpid Proton Issue Type: Bug Components: cpp-binding, proton-c, python-binding Affects Versions: 0.14.0 Reporter: Cliff Jansen Assignee: Cliff Jansen The quick_perf targets for performance sanity checks have been broken for some time. The launch script for the quick_perf_c etc targets depended on other test scripts which were re-written over time to fix race conditions and python version variations. This fix changes none of the logic, just uses the new conventions from the other scripts. -- 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] [Comment Edited] (PROTON-1211) C++ binding exception in message::correlation_id()
[
https://issues.apache.org/jira/browse/PROTON-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298738#comment-15298738
]
Cliff Jansen edited comment on PROTON-1211 at 5/24/16 7:15 PM:
---
Simplest fix is to just clear the pn_data_t before new insertion:
{code}
diff -c message.cpp.cj0 message.cpp
*** 143,148
--- 143,149
void message::correlation_id(const message_id& id) {
codec::encoder e(make_wrapper(pn_message_correlation_id(pn_msg(;
+ e.clear();
e << id;
}
{code}
But perhaps new encoders should clear by default as the more intuative use (and
have a separate constructor for the "and save my current position" case).
was (Author: cliffjansen):
Simplest fix is to just clear the pn_data_t before new insertion:
{quote}
diff -c message.cpp.cj0 message.cpp
*** 143,148
--- 143,149
void message::correlation_id(const message_id& id) {
codec::encoder e(make_wrapper(pn_message_correlation_id(pn_msg(;
+ e.clear();
e << id;
}
{quote}
But perhaps new encoders should clear by default as the more intuative use (and
have a separate constructor for the "and save my current position" case).
> C++ binding exception in message::correlation_id()
> --
>
> Key: PROTON-1211
> URL: https://issues.apache.org/jira/browse/PROTON-1211
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.13.0, 0.14.0
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
>Priority: Blocker
> Fix For: 0.13.0
>
> Attachments: msgid.cpp
>
>
--
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] [Comment Edited] (PROTON-1211) C++ binding exception in message::correlation_id()
[
https://issues.apache.org/jira/browse/PROTON-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298738#comment-15298738
]
Cliff Jansen edited comment on PROTON-1211 at 5/24/16 7:14 PM:
---
Simplest fix is to just clear the pn_data_t before new insertion:
{quote}
diff -c message.cpp.cj0 message.cpp
*** 143,148
--- 143,149
void message::correlation_id(const message_id& id) {
codec::encoder e(make_wrapper(pn_message_correlation_id(pn_msg(;
+ e.clear();
e << id;
}
{quote}
But perhaps new encoders should clear by default as the more intuative use (and
have a separate constructor for the "and save my current position" case).
was (Author: cliffjansen):
Simplest fix is to just clear the pn_data_t before new insertion:
diff -c message.cpp.cj0 message.cpp
*** 143,148
--- 143,149
void message::correlation_id(const message_id& id) {
codec::encoder e(make_wrapper(pn_message_correlation_id(pn_msg(;
+ e.clear();
e << id;
}
But perhaps new encoders should clear by default as the more intuative use (and
have a separate constructor for the "and save my current position" case).
> C++ binding exception in message::correlation_id()
> --
>
> Key: PROTON-1211
> URL: https://issues.apache.org/jira/browse/PROTON-1211
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.13.0, 0.14.0
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
>Priority: Blocker
> Fix For: 0.13.0
>
> Attachments: msgid.cpp
>
>
--
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-1211) C++ binding exception in message::correlation_id()
[
https://issues.apache.org/jira/browse/PROTON-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298738#comment-15298738
]
Cliff Jansen commented on PROTON-1211:
--
Simplest fix is to just clear the pn_data_t before new insertion:
diff -c message.cpp.cj0 message.cpp
*** 143,148
--- 143,149
void message::correlation_id(const message_id& id) {
codec::encoder e(make_wrapper(pn_message_correlation_id(pn_msg(;
+ e.clear();
e << id;
}
But perhaps new encoders should clear by default as the more intuative use (and
have a separate constructor for the "and save my current position" case).
> C++ binding exception in message::correlation_id()
> --
>
> Key: PROTON-1211
> URL: https://issues.apache.org/jira/browse/PROTON-1211
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.13.0, 0.14.0
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
>Priority: Blocker
> Fix For: 0.13.0
>
> Attachments: msgid.cpp
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1211) C++ binding exception in message::correlation_id()
[ https://issues.apache.org/jira/browse/PROTON-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated PROTON-1211: - Attachment: msgid.cpp Repeated setting of a message's correlation_id needlessly allocates a new pn_node_t struct maxing out at 64K nodes and an encoder exception. see attached reproducer > C++ binding exception in message::correlation_id() > -- > > Key: PROTON-1211 > URL: https://issues.apache.org/jira/browse/PROTON-1211 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0, 0.14.0 >Reporter: Cliff Jansen > Assignee: Cliff Jansen >Priority: Blocker > Fix For: 0.13.0 > > Attachments: msgid.cpp > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1211) C++ binding exception in message::correlation_id()
Cliff Jansen created PROTON-1211: Summary: C++ binding exception in message::correlation_id() Key: PROTON-1211 URL: https://issues.apache.org/jira/browse/PROTON-1211 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: 0.13.0, 0.14.0 Reporter: Cliff Jansen Assignee: Cliff Jansen Priority: Blocker Fix For: 0.13.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1194) C++ flow control
Cliff Jansen created PROTON-1194: Summary: C++ flow control Key: PROTON-1194 URL: https://issues.apache.org/jira/browse/PROTON-1194 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Affects Versions: 0.12.2 Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.13.0 Provide basic flow control primitives: receiver::add_credit, receiver::drain and handler event callbacks to note drain begin and completion. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1187) consistent options for endpoints
Cliff Jansen created PROTON-1187: Summary: consistent options for endpoints Key: PROTON-1187 URL: https://issues.apache.org/jira/browse/PROTON-1187 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Affects Versions: 0.12.2 Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.13.0 Make use of endpoint options consistent by adding session options. Also update connection.open to accept connection_options to configure inbound connections. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1183) C++ binding: make proton::terminus internal
Cliff Jansen created PROTON-1183: Summary: C++ binding: make proton::terminus internal Key: PROTON-1183 URL: https://issues.apache.org/jira/browse/PROTON-1183 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Affects Versions: 0.12.2 Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.13.0 Hide terminus from visible api surface. Add source and target replacement calsses. create source_options and target_options for configuration and move from sender/receiver configuration where appropriate. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1182) C++ binding: make proton::link part of the internal namespace
Cliff Jansen created PROTON-1182: Summary: C++ binding: make proton::link part of the internal namespace Key: PROTON-1182 URL: https://issues.apache.org/jira/browse/PROTON-1182 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Affects Versions: 0.12.2 Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.13.0 As part of ongoing API cleanup, make generic link usage a part of the proton::internal namespace and replace use of link in the user API with proton::sender or proton::receiver as appropriate. Split link_options into sender_options and receiver_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
Review Request 45340: turn off async ANONYMOUS SASL negotiation by default
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/45340/ --- Review request for qpid. Bugs: PROTON-1135 https://issues.apache.org/jira/browse/PROTON-1135 Repository: qpid-proton-git Description --- Add new sasl api methods: pn_sasl_set_async_negotiation pn_sasl_get_async_negotiation Turn async off by default Add python test. Diffs - proton-c/bindings/python/proton/__init__.py 5ffede8 proton-c/include/proton/sasl.h 354982f proton-c/src/sasl/sasl-internal.h b3f4c7f proton-c/src/sasl/sasl.c 29d377e tests/python/proton_tests/engine.py 0a6eb8d tests/python/proton_tests/sasl.py 6adb77d Diff: https://reviews.apache.org/r/45340/diff/ Testing --- linux ctest Thanks, Cliff Jansen
Review Request 44927: C++ api changes: handler options become link or connection options
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/44927/ --- Review request for qpid and Justin Ross. Bugs: PROTON-1138 https://issues.apache.org/jira/browse/PROTON-1138 Repository: qpid-proton-git Description --- handler options -> link/connection options prefetch -> credit_window stop use of pn_flowcontroller (manage credit directly) override -> update (C++ semi-reserved word) and private new link_context to store behaviors have container link_options apply to remote opened links Diffs - proton-c/bindings/cpp/include/proton/connection_options.hpp 71e12f1 proton-c/bindings/cpp/include/proton/container.hpp 0af1963 proton-c/bindings/cpp/include/proton/handler.hpp 3bc0023 proton-c/bindings/cpp/include/proton/link.hpp e626398 proton-c/bindings/cpp/include/proton/link_options.hpp 2eb145d proton-c/bindings/cpp/src/connection_options.cpp a5ee99e proton-c/bindings/cpp/src/container.cpp fc34f39 proton-c/bindings/cpp/src/container_impl.hpp d1b476f proton-c/bindings/cpp/src/container_impl.cpp 55547ca proton-c/bindings/cpp/src/contexts.hpp b4fcdba proton-c/bindings/cpp/src/contexts.cpp c2b76f6 proton-c/bindings/cpp/src/handler.cpp 43febf5 proton-c/bindings/cpp/src/link_options.cpp 534a6b6 proton-c/bindings/cpp/src/messaging_adapter.hpp a5b364a proton-c/bindings/cpp/src/messaging_adapter.cpp 4265644 proton-c/bindings/cpp/src/proton_event.hpp 8dd2f8f tests/tools/apps/cpp/reactor_send.cpp 3ba26e8 Diff: https://reviews.apache.org/r/44927/diff/ Testing --- linux build and ctest Thanks, Cliff Jansen
[jira] [Commented] (QPID-2410) perftest hang in SSL on Windows with large buffers
[ https://issues.apache.org/jira/browse/QPID-2410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15167294#comment-15167294 ] Cliff Jansen commented on QPID-2410: The reserved byte space at the front and end of the QPID buffer is stripped at the other end, so it does not alter the frame size seen by the application code that processes the AMQP frame. The fact of the mater is that the natural and efficient handling of application data streams is very different in NSS versus SChannel (transform via copy versus transform in place). In Proton, small frames are handled as they are in QPID (in place) and for larger frames, only the front portion is transformed in place with the rest getting copied (its actually uglier than that but that's the general idea). For correctness in QPID with large frames on Windows, something along those lines is probably the simplest thing to be done here, where "simple" is a relative term (buffer breakup, perhaps single completions mapped to multiple ones). For best performance with large frames, some deeper thinking is warranted. I seem to recall that some sort of scatter gather fanciness lurks somewhere in SChannel, but as always with Windows, finding the set of APIs that work across the desired versions of Windows is likely a challenge. > perftest hang in SSL on Windows with large buffers > -- > > Key: QPID-2410 > URL: https://issues.apache.org/jira/browse/QPID-2410 > Project: Qpid > Issue Type: Bug > Components: C++ Client >Affects Versions: 0.7 > Environment: Windows client, Linux broker >Reporter: Cliff Jansen >Assignee: Steve Huston > > The following command: > perftest --count 1 --size 102400 -P ssl --port 5671 --broker linuxhost > --username testuser --password secret --mechanism PLAIN > hangs on a Windows client. Reducing the message body size to 1024 bytes > makes the hang go away, as does turning off SSL. -- 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
Review Request 39694: C++ binding connection options and reconnect
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/39694/ --- Review request for qpid, Alan Conway, Andrew Stitcher, and Justin Ross. Bugs: PROTON-865 https://issues.apache.org/jira/browse/PROTON-865 Repository: qpid-proton-git Description --- This provides connection options (broadly similar to link options). As suggested by Alan, the collection connection_options is a subclass of the base connection_option so that they can be grouped and nested. They can also be copied and persisted via respective clone methods. Reconnect and transport options need to live as long as the connection. The handler option is special and needs to be extracted before other options to be available when the connection is created. Incoming (listener) connection options are perhaps missing a feature. You can set global server connection options on a container, and you can set separate ssl_domain creds per listener, but you cannot set other connection options (idle_timeout/max_frame_size etc) per listener. This is reflected in Proton-C's acceptor and the readable events that it intercepts. There is no way to query the C API to find out which listener is the parent of an incoming connection or transfer other listener-specific context to the connection. As suggested in the link options review, I attempted to provide an initializer_list constructor and append, but that requires array elements of identical size. The varying size of the connection option types is unhelpful here. Maybe they should be counted_ptr based pimpl structs of identical size. This patch can also be viewed as the "reconnect" branch of https://github.com/cliffjansen/qpid-proton. Diffs - examples/cpp/CMakeLists.txt 34edb83 examples/cpp/connection_options.cpp PRE-CREATION proton-c/bindings/cpp/CMakeLists.txt 9f423fb proton-c/bindings/cpp/include/proton/connection_options.hpp PRE-CREATION proton-c/bindings/cpp/include/proton/container.hpp 059416f proton-c/bindings/cpp/include/proton/reconnect_timer.hpp PRE-CREATION proton-c/bindings/cpp/include/proton/transport.hpp 3d602b7 proton-c/bindings/cpp/src/blocking_connection_impl.cpp 8abd24b proton-c/bindings/cpp/src/connection.cpp 1b35e03 proton-c/bindings/cpp/src/connection_options.cpp PRE-CREATION proton-c/bindings/cpp/src/connector.hpp b311cc9 proton-c/bindings/cpp/src/connector.cpp 49660ea proton-c/bindings/cpp/src/container.cpp 13f12d9 proton-c/bindings/cpp/src/container_impl.hpp ec356e2 proton-c/bindings/cpp/src/container_impl.cpp fc97a3e proton-c/bindings/cpp/src/reconnect_timer.cpp PRE-CREATION proton-c/bindings/cpp/src/transport.cpp 58114ae Diff: https://reviews.apache.org/r/39694/diff/ Testing --- Linux only Thanks, Cliff Jansen
Re: Review Request 39222: C++ binding link options
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/39222/ --- (Updated Oct. 16, 2015, 5:39 p.m.) Review request for qpid, Alan Conway, Andrew Stitcher, and Justin Ross. Changes --- github reference added Bugs: PROTON-865 https://issues.apache.org/jira/browse/PROTON-865 Repository: qpid-proton-git Description (updated) --- Link options, provided much like the Python client. Includes examples from Python for selector and browser. Additional link and terminus properties were added as required. The source can also be viewed in branch "linkoptions" on https://github.com/cliffjansen/qpid-proton/ Diffs - examples/cpp/CMakeLists.txt 34edb83 examples/cpp/queue_browser.cpp PRE-CREATION examples/cpp/selected_recv.cpp PRE-CREATION proton-c/bindings/cpp/CMakeLists.txt 45e47b2 proton-c/bindings/cpp/include/proton/connection.hpp 08b6ad9 proton-c/bindings/cpp/include/proton/link.hpp 88b5368 proton-c/bindings/cpp/include/proton/link_options.hpp PRE-CREATION proton-c/bindings/cpp/include/proton/terminus.hpp 4bb9651 proton-c/bindings/cpp/src/connection.cpp 84c79a6 proton-c/bindings/cpp/src/link.cpp 12c8790 proton-c/bindings/cpp/src/link_options.cpp PRE-CREATION proton-c/bindings/cpp/src/terminus.cpp 2c960d6 Diff: https://reviews.apache.org/r/39222/diff/ Testing --- Linux. Checked attach frames compared to Python. Thanks, Cliff Jansen
Review Request 39222: C++ binding link options
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/39222/ --- Review request for qpid, Alan Conway, Andrew Stitcher, and Justin Ross. Bugs: PROTON-865 https://issues.apache.org/jira/browse/PROTON-865 Repository: qpid-proton-git Description --- Link options, provided much like the Python client. Includes examples from Python for selector and browser. Additional link and terminus properties were added as required. Diffs - examples/cpp/CMakeLists.txt 34edb83 examples/cpp/queue_browser.cpp PRE-CREATION examples/cpp/selected_recv.cpp PRE-CREATION proton-c/bindings/cpp/CMakeLists.txt 45e47b2 proton-c/bindings/cpp/include/proton/connection.hpp 08b6ad9 proton-c/bindings/cpp/include/proton/link.hpp 88b5368 proton-c/bindings/cpp/include/proton/link_options.hpp PRE-CREATION proton-c/bindings/cpp/include/proton/terminus.hpp 4bb9651 proton-c/bindings/cpp/src/connection.cpp 84c79a6 proton-c/bindings/cpp/src/link.cpp 12c8790 proton-c/bindings/cpp/src/link_options.cpp PRE-CREATION proton-c/bindings/cpp/src/terminus.cpp 2c960d6 Diff: https://reviews.apache.org/r/39222/diff/ Testing --- Linux. Checked attach frames compared to Python. Thanks, Cliff Jansen
Review Request 38859: Application events: C++ binding
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/38859/ --- Review request for qpid, Alan Conway, Andrew Stitcher, Gordon Sim, and Justin Ross. Bugs: PROTON-865 https://issues.apache.org/jira/browse/PROTON-865 Repository: qpid-proton-git Description --- This implementation follows the Python version fairly closely except that on_foo() method names for the call backs cannot be embedded in the C++ version. A single ApplicationEvent can correspond to 0..N outstanding triggered proton C events. An ApplicationEvent will always be dispatched to the main/default handler (same as Python). Even if assigned a "context" for connection/link/etc. Perhaps the event callback should flow to the context's handler as for other events, or a separate handler specifier should be added to push/push_event. Or proton::handler should be ignored completely and an arbitrary std::function callback (or equivalent for pre-c++11) should be considered (already available in derived subclasses). A C++ ApplicationEvent can have a void * data pointer associated with it. It can also be subclassed to include arbitrarily complex additional data or behavior. The application is responsible for keeping the ApplicationEvent alive until the last pending event has been processed by all handlers and child handlers. This is non-trivial in the case of an event that should be discarded right after use. To assist, if the custom event is derived from proton::counted, the counted refcount will be incremented for each push and decremented each time the Proton C reactor finishes dispatching the event everywhere. Bugs: In addition to being restricted to a single handler at the moment, two pushes of the same event in succession result in the second event being lost (also happens in Python, due to pn_collector_put() eliminating a second of two events it sees as identical). This can be worked around by defining and pushing an always-ignored event between the two, or define a new pn_collector_put_but_duplicates_ok proton C function. Diffs - examples/cpp/CMakeLists.txt 1ac1b1e examples/cpp/application_events.cpp PRE-CREATION proton-c/bindings/cpp/CMakeLists.txt 868bbb9 proton-c/bindings/cpp/include/proton/application_event.hpp PRE-CREATION proton-c/bindings/cpp/include/proton/container.hpp 98754cf proton-c/bindings/cpp/include/proton/messaging_handler.hpp af5d78b proton-c/bindings/cpp/src/application_event.cpp PRE-CREATION proton-c/bindings/cpp/src/application_event_impl.hpp PRE-CREATION proton-c/bindings/cpp/src/container.cpp f9dc06e proton-c/bindings/cpp/src/container_impl.hpp 6210b23 proton-c/bindings/cpp/src/container_impl.cpp 3aab33f proton-c/bindings/cpp/src/messaging_handler.cpp d8b0262 Diff: https://reviews.apache.org/r/38859/diff/ Testing --- linux so far. Python binding to verify behavior there too. Thanks, Cliff Jansen
Review Request 37217: Switch from handlefoo to concrete class or reference in C++ client
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/37217/ --- Review request for qpid, Alan Conway and Andrew Stitcher. Bugs: PROTON-865 https://issues.apache.org/jira/browse/PROTON-865 Repository: qpid-proton-git Description --- This is a mini refactor of a single class to see if the chosen direction for generally removing handlefoo is sane. I chose the connection class to try based on medium complexity and interaction with other moving parts (not visible to the user, the connector/override and life cycle issues). The connection is now non copyable. If the connection self-created (i.e. an inbound connection from a listener, arriving via a reactor event, or implicit connection from container.create_receiver), it is not owned, and its life ends when the pn_connection_t dies (dies for good, i.e. when it releases its attachment records). If the user creates the connection explicitly, it is owned and destructs as normal. It is unclear if the Python behavior should be preserved, where the connection lives on un-owned, or destruction means all gone with tear down of the transport and connector. I chose the latter as perhaps least surprise for the user. The Proton C++ code can use either model internally to taste. Perhaps the connection object should have a pin/unpin or incref/decref ability so that the user can hang onto it past the event delivery. As a hack, they can always do pn_incref(connection.pn_connection()) and decref it when done. It is not clear to me that the counted class will ever be used separately from the contextfoo class, so they might get rolled together in the future. The memory management is accomplished by a special proton metaclass that is refcounted, but neither allocates nor frees memory. connection::getZZZcontainer() is an unintended artifact of the refactor. I'm not sure why gcc is fussing over the original signature, but I don't wish to target its resolution in this review. Diffs - examples/cpp/helloworld.cpp 34e5076 examples/cpp/server.cpp 78b78d3 proton-c/bindings/cpp/CMakeLists.txt d1b1ebc proton-c/bindings/cpp/include/proton/connection.hpp af3c585 proton-c/bindings/cpp/include/proton/container.hpp a0ca59a proton-c/bindings/cpp/include/proton/context.hpp PRE-CREATION proton-c/bindings/cpp/include/proton/counted.hpp PRE-CREATION proton-c/bindings/cpp/src/blocking_connection.cpp c0c1477 proton-c/bindings/cpp/src/blocking_connection_impl.hpp 11ff4fd proton-c/bindings/cpp/src/blocking_connection_impl.cpp 0e78541 proton-c/bindings/cpp/src/connection.cpp 2b335a4 proton-c/bindings/cpp/src/connection_impl.hpp 6450ef5 proton-c/bindings/cpp/src/connection_impl.cpp e2f4608 proton-c/bindings/cpp/src/connector.hpp ad373a9 proton-c/bindings/cpp/src/connector.cpp 559a7fd proton-c/bindings/cpp/src/container.cpp a424c0b proton-c/bindings/cpp/src/container_impl.hpp 1ce27ee proton-c/bindings/cpp/src/container_impl.cpp e328251 proton-c/bindings/cpp/src/context.cpp PRE-CREATION proton-c/bindings/cpp/src/contexts.cpp 98c502b proton-c/bindings/cpp/src/counted.cpp PRE-CREATION proton-c/bindings/cpp/src/link.cpp 2cef0a2 proton-c/bindings/cpp/src/proton_event.cpp 46b43ee proton-c/bindings/cpp/src/session.cpp 5742f13 Diff: https://reviews.apache.org/r/37217/diff/ Testing --- passes ctest on rhel7 Thanks, Cliff Jansen
Re: Review Request 37217: Switch from handlefoo to concrete class or reference in C++ client
On Aug. 7, 2015, 2:54 p.m., Alan Conway wrote: I would like to try something simpler (sorry!) There are 2 things I'd like to separate: 1. Clean, simple, no-value-add access to proton types. 2. Separate convenience classes to make proton easier to use. For 1. the existing proton_handle template is perfect. I'd rename it proton_ptr to clarify it has simple pointer semantics. The proton_ptr subclasses just provide C++ method syntax for C calls and do some argument wrapping for strings, wrapping pointers as proton_ptr etc. This is what we already do for most types. We do no extra memory management at this layer, we just document the proton rules: pointers are valid inside event handlers, outside they are valid until the relevant _close events (including close events for containing objects) - if you break the rules, core dump. If you open()/create() it yourself, you must call close() when you are done or leak. Stick to simple C-style rules, IMO we should NOT expose proton's refcounting unless someone threatens to gouge our eyes out. For 2. e.g. proton::container: we can do what we like - a handle is not be unreasonable here if we can't make it simpler than that. My concern with proton::connection is it mixes the two. I would prefer a proton::connection that is nothing but a proton_ptrpn_connection_t, looking at connection_impl.hpp it isn't much more than that - I think we could probably strip the rest away, maybe just by adding a container* as a context or whatever it is called on the pn_connection_t. We do any memory management magic needed in the value-add layer, e.g. proton::container can have handlers to track connection lifecycles and ensure we don't delete the container while there are still connections referencing it. We can do this because we have access to all the events etc. Does this sound feasible? My main point here is to have a clean and complete proton layer with standard C-style follow the rules or core dump/leak, and build ease-of-use and memory safety on top of that. If we mix them we will go insane. Proton's refcounting should be considered an implementation detail of the proton lib, not something we try to pull up into C++. It works for python because it was designed for python, C++ is not the same animal. This is what I did in Go and it works pretty well. My experience there is that if you want something like goroutine-safe access to proton, you really have to build it in terms of your lanugage concurrency rules. Working from simple pointer semantics and adding your own event handlers to manage lifecycle works fine. We could conceivably do a pthreads version of the go messaging API someday but not today :) Alan Conway wrote: I think proton::message is also an exception to the above, there's no useful wrapping of pn_message_t, so this is an ease-of-use class. We could debate whether it should have handle or value semantics but a hidden implementation is a good thing either way. If you are happy to allow core dumps and leaks for breaking the rules, why not just give an actual pointer to the object. What additional benefit is supplied by proton_ptrpn_connection_t compared to *connection? I don't take issue with the motivation, just asking from the point of view of providing the most C++ idiomatic API. I take it from Andrew's comments in https://github.com/apache/qpid-proton/pull/35 that he is not fond of the PIMPL pattern for the C++ binding. There was some talk of performance, but I think it was also due to a preference for a different model from the API cleanliness/idiomatic-maximizing point of view. FWIW, this patch (without a pin/unpin addition) works the way you suggest in terms of safety, i.e. the references are valid for as long as you proposed. I agree that the C++ connection's internal organs are currently light, not requiring more context than already stored or storable in the pn_connection_t object. But in future, if there is some attempt to go parallel for performance, it seems to me that the connection object is likely to be the prime candidate for orchestrating things, so it might need some optimizations away from the pn_connection_t object. That was the main reason I treated it differently than e.g. link. Note that this patch shows what moving away from the PIMPL pattern would look like. I am not personally advocating that it should be dropped. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/37217/#review94542 --- On Aug. 7, 2015, 1:46 p.m., Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/37217
Review Request 32033: C reactor event samples, including external loop (libuv)
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/32033/ --- Review request for qpid, Gordon Sim and Rafael Schloming. Bugs: PROTON-837 https://issues.apache.org/jira/browse/PROTON-837 Repository: qpid-proton-git Description --- simple_send.c provides a simple send/receive example over a single outgoing connection. simple_echo.c provides a simple server that manages multiple incoming connections from simple_send (or msgr-send, or reactor-send). uv_iohandler.c provides an external loop substitute to drive Proton events. It can be combined with simple_echo as written and with arbitrary other programs with minor tweaks. simple_send and simple_echo will benefit from review as to suitability for good tutorial material for using the Proton reactor event model, especially for correctness and clarity. uv_iohandler is more a proof of concept and hopefully demonstrates a decent blueprint for integrating other external loops into Proton. Diffs - examples/engine/c/README PRE-CREATION examples/engine/c/simple_echo.c PRE-CREATION examples/engine/c/simple_send.c PRE-CREATION examples/engine/c/uv_iohandler.c PRE-CREATION Diff: https://reviews.apache.org/r/32033/diff/ Testing --- fedora 20 so far. headwinds expected on Windows Thanks, Cliff Jansen
Re: Review Request 30898: Reactor send and receive soak test programs
On Feb. 12, 2015, 3:11 p.m., Rafael Schloming wrote: tests/tools/apps/c/reactor-recv.c, line 300 https://reviews.apache.org/r/30898/diff/1/?file=861148#file861148line300 Why are you creating a new handler for each incoming connection? Unless the handler holds per connection state there is no need for this. You can avoid holding any per connection state by simply attaching your state to the connection, and it would probably simplify the memory management overall to use a single handler for this purpose. Cliff Jansen wrote: Two reasons. First this seemed a powerful feature to create custom handlers for short or long term purposes... worth exercising in another test program with a bit of valgrind oversight. Secondly, it seemed probable that per connection context would show up in time as the programs get fleshed out with more functionality. Rafael Schloming wrote: Ok, that makes sense from a testing perspective. I probably wouldn't do it that way in an example without something to actually motivate the need for a custom handler per connection since it's a bit more complicated than it needs to be that way. I didn't quite understand your second reason though. reactor-send/recv could be fleshed out to do more msgr-send/recv things in future to plug into the star-topology test or others (batching?). I just assumed that per connection state would be required for fancier features. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30898/#review72105 --- On Feb. 19, 2015, 8:26 p.m., Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30898/ --- (Updated Feb. 19, 2015, 8:26 p.m.) Review request for qpid and Rafael Schloming. Bugs: PROTON-818 https://issues.apache.org/jira/browse/PROTON-818 Repository: qpid-proton-git Description --- These are meant to eventually plug into the python test suite. For now they do a small subset of their counterparts msgr-send and msgr-recv. In their current early state they just send and receive with an optional reply-to capability. These programs could use a review as to how well they serve as a blueprint for some good reactor C examples. Of particular concern are the use of pn_decref/pn_incref for handlers in general or to force the ordering of handler cleanup (i.e. connection_handler cleanup before the global/listener handler) pn_incref for pn_connection_free (else segfaults, but without the pn_connection_free the connection_cleanup is not called until the reactor finishes which could be hours or days later) This could just be more about poor use of the API than anything else, so any suggestions are welcome. I am still working of the python test integration which seems to imply that at least the -X READY and -t 60 args need to be implemented on top of what you see so far. Diffs - tests/python/proton_tests/common.py 42cf7b1 tests/python/proton_tests/soak.py 94ce488 tests/tools/apps/c/CMakeLists.txt deafe24 tests/tools/apps/c/reactor-recv.c PRE-CREATION tests/tools/apps/c/reactor-send.c PRE-CREATION Diff: https://reviews.apache.org/r/30898/diff/ Testing --- The programs have at least been tested with multiple simultaneous connections as follows: server: time ./reactor-recv -c 100 -R shooter: for i in 1 2 3 4 5 6 7 8 9 10 ; do ./reactor-send -a amqp://127.0.0.1/test_$i -c 10 -R echo $i; usleep 20; done Thanks, Cliff Jansen
Re: Review Request 30898: Reactor send and receive soak test programs
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30898/ --- (Updated Feb. 19, 2015, 8:26 p.m.) Review request for qpid and Rafael Schloming. Changes --- This has fixes for changes in reactor api signatures and enough tweaks to allow a couple of tests to be added that work similarly to simpler messenger soak tests. Also fixes to make valgrind happy. The need to sometimes decref (and sometimes not) various handlers remains puzzling (i.e. pn_handshaker in listener_dispatch versus main, or connection_handler in listener_dispatch). Bugs: PROTON-818 https://issues.apache.org/jira/browse/PROTON-818 Repository: qpid-proton-git Description --- These are meant to eventually plug into the python test suite. For now they do a small subset of their counterparts msgr-send and msgr-recv. In their current early state they just send and receive with an optional reply-to capability. These programs could use a review as to how well they serve as a blueprint for some good reactor C examples. Of particular concern are the use of pn_decref/pn_incref for handlers in general or to force the ordering of handler cleanup (i.e. connection_handler cleanup before the global/listener handler) pn_incref for pn_connection_free (else segfaults, but without the pn_connection_free the connection_cleanup is not called until the reactor finishes which could be hours or days later) This could just be more about poor use of the API than anything else, so any suggestions are welcome. I am still working of the python test integration which seems to imply that at least the -X READY and -t 60 args need to be implemented on top of what you see so far. Diffs (updated) - tests/python/proton_tests/common.py 42cf7b1 tests/python/proton_tests/soak.py 94ce488 tests/tools/apps/c/CMakeLists.txt deafe24 tests/tools/apps/c/reactor-recv.c PRE-CREATION tests/tools/apps/c/reactor-send.c PRE-CREATION Diff: https://reviews.apache.org/r/30898/diff/ Testing --- The programs have at least been tested with multiple simultaneous connections as follows: server: time ./reactor-recv -c 100 -R shooter: for i in 1 2 3 4 5 6 7 8 9 10 ; do ./reactor-send -a amqp://127.0.0.1/test_$i -c 10 -R echo $i; usleep 20; done Thanks, Cliff Jansen
Re: Review Request 30898: Reactor send and receive soak test programs
On Feb. 12, 2015, 3:11 p.m., Rafael Schloming wrote: tests/tools/apps/c/reactor-recv.c, line 300 https://reviews.apache.org/r/30898/diff/1/?file=861148#file861148line300 Why are you creating a new handler for each incoming connection? Unless the handler holds per connection state there is no need for this. You can avoid holding any per connection state by simply attaching your state to the connection, and it would probably simplify the memory management overall to use a single handler for this purpose. Two reasons. First this seemed a powerful feature to create custom handlers for short or long term purposes... worth exercising in another test program with a bit of valgrind oversight. Secondly, it seemed probable that per connection context would show up in time as the programs get fleshed out with more functionality. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30898/#review72105 --- On Feb. 19, 2015, 8:26 p.m., Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30898/ --- (Updated Feb. 19, 2015, 8:26 p.m.) Review request for qpid and Rafael Schloming. Bugs: PROTON-818 https://issues.apache.org/jira/browse/PROTON-818 Repository: qpid-proton-git Description --- These are meant to eventually plug into the python test suite. For now they do a small subset of their counterparts msgr-send and msgr-recv. In their current early state they just send and receive with an optional reply-to capability. These programs could use a review as to how well they serve as a blueprint for some good reactor C examples. Of particular concern are the use of pn_decref/pn_incref for handlers in general or to force the ordering of handler cleanup (i.e. connection_handler cleanup before the global/listener handler) pn_incref for pn_connection_free (else segfaults, but without the pn_connection_free the connection_cleanup is not called until the reactor finishes which could be hours or days later) This could just be more about poor use of the API than anything else, so any suggestions are welcome. I am still working of the python test integration which seems to imply that at least the -X READY and -t 60 args need to be implemented on top of what you see so far. Diffs - tests/python/proton_tests/common.py 42cf7b1 tests/python/proton_tests/soak.py 94ce488 tests/tools/apps/c/CMakeLists.txt deafe24 tests/tools/apps/c/reactor-recv.c PRE-CREATION tests/tools/apps/c/reactor-send.c PRE-CREATION Diff: https://reviews.apache.org/r/30898/diff/ Testing --- The programs have at least been tested with multiple simultaneous connections as follows: server: time ./reactor-recv -c 100 -R shooter: for i in 1 2 3 4 5 6 7 8 9 10 ; do ./reactor-send -a amqp://127.0.0.1/test_$i -c 10 -R echo $i; usleep 20; done Thanks, Cliff Jansen
Review Request 30898: Reactor send and receive soak test programs
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30898/ --- Review request for qpid and Rafael Schloming. Bugs: PROTRON-818 https://issues.apache.org/jira/browse/PROTRON-818 Repository: qpid-proton-git Description --- These are meant to eventually plug into the python test suite. For now they do a small subset of their counterparts msgr-send and msgr-recv. In their current early state they just send and receive with an optional reply-to capability. These programs could use a review as to how well they serve as a blueprint for some good reactor C examples. Of particular concern are the use of pn_decref/pn_incref for handlers in general or to force the ordering of handler cleanup (i.e. connection_handler cleanup before the global/listener handler) pn_incref for pn_connection_free (else segfaults, but without the pn_connection_free the connection_cleanup is not called until the reactor finishes which could be hours or days later) This could just be more about poor use of the API than anything else, so any suggestions are welcome. I am still working of the python test integration which seems to imply that at least the -X READY and -t 60 args need to be implemented on top of what you see so far. Diffs - tests/tools/apps/c/reactor-recv.c PRE-CREATION tests/tools/apps/c/reactor-send.c PRE-CREATION Diff: https://reviews.apache.org/r/30898/diff/ Testing --- The programs have at least been tested with multiple simultaneous connections as follows: server: time ./reactor-recv -c 100 -R shooter: for i in 1 2 3 4 5 6 7 8 9 10 ; do ./reactor-send -a amqp://127.0.0.1/test_$i -c 10 -R echo $i; usleep 20; done Thanks, Cliff Jansen
Re: Review Request 30898: Reactor send and receive soak test programs
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30898/ --- (Updated Feb. 12, 2015, 2:58 a.m.) Review request for qpid and Rafael Schloming. Changes --- fix Jira link Bugs: PROTON-818 https://issues.apache.org/jira/browse/PROTON-818 Repository: qpid-proton-git Description --- These are meant to eventually plug into the python test suite. For now they do a small subset of their counterparts msgr-send and msgr-recv. In their current early state they just send and receive with an optional reply-to capability. These programs could use a review as to how well they serve as a blueprint for some good reactor C examples. Of particular concern are the use of pn_decref/pn_incref for handlers in general or to force the ordering of handler cleanup (i.e. connection_handler cleanup before the global/listener handler) pn_incref for pn_connection_free (else segfaults, but without the pn_connection_free the connection_cleanup is not called until the reactor finishes which could be hours or days later) This could just be more about poor use of the API than anything else, so any suggestions are welcome. I am still working of the python test integration which seems to imply that at least the -X READY and -t 60 args need to be implemented on top of what you see so far. Diffs - tests/tools/apps/c/reactor-recv.c PRE-CREATION tests/tools/apps/c/reactor-send.c PRE-CREATION Diff: https://reviews.apache.org/r/30898/diff/ Testing --- The programs have at least been tested with multiple simultaneous connections as follows: server: time ./reactor-recv -c 100 -R shooter: for i in 1 2 3 4 5 6 7 8 9 10 ; do ./reactor-send -a amqp://127.0.0.1/test_$i -c 10 -R echo $i; usleep 20; done Thanks, Cliff Jansen
[jira] [Resolved] (QPID-5842) Allow SSL hostname verification to be disabled on windows
[ https://issues.apache.org/jira/browse/QPID-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved QPID-5842. Resolution: Fixed Fix Version/s: 0.31 A simpler fix was available than in Proton since we are not overriding the default trusted root CA location. One extra flag suffices for this use case: SCH_CRED_NO_SERVERNAME_CHECK. Allow SSL hostname verification to be disabled on windows - Key: QPID-5842 URL: https://issues.apache.org/jira/browse/QPID-5842 Project: Qpid Issue Type: Bug Components: C++ Client Environment: Windows Reporter: Gordon Sim Assignee: Cliff Jansen Fix For: 0.31 sometimes the certficate doesn't match the address used to establish the connection, and it would be convenient to be able to disable the verification for those 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
Re: Request for Proton code review: IO layer refactor.
I say Ship it!. I don't feel strongly about the deprecated bits, but if we don't remove them now, when is the right or at least better time? Cliff On Mon, Nov 17, 2014 at 12:14 PM, Andrew Stitcher astitc...@redhat.com wrote: As we currently don't have reviewboard set up for Qpid Proton (since the git migration). I've posted a pull request against the Github Apache proton mirror to get review feedback for my IO layer refactoring. https://github.com/apache/qpid-proton/pull/1 Please give it some attention, I know that Rafi would like this change to go in quickly as some important changes are queued up behind it. Thanks Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Request for Proton code review: SSL certificate stores (Windows and more)
Following Andrew's lead, I've posted a pull request for review feedback on an extended usage pattern to the Proton API to specify alternate certificate containers, for Windows in this case, but it should also apply to alternate SSL/TLS implementations such as NSS or Java keystores. https://github.com/apache/qpid-proton/pull/2 I expect a wider audience than just Windows users may be interested in the changes in ssl.h and I am especially interested on feedback there. Some may prefer an outright API change or addition. I, of course, also welcome any additional eyes on the Windows-specific code too. Cliff - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-6187) Disable SSL v3 for Windows SChannel
[ https://issues.apache.org/jira/browse/QPID-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved QPID-6187. Resolution: Fixed Disable SSL v3 for Windows SChannel --- Key: QPID-6187 URL: https://issues.apache.org/jira/browse/QPID-6187 Project: Qpid Issue Type: Bug Components: C++ Client Environment: windows Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.31 Using same fix as in https://issues.apache.org/jira/browse/PROTON-719 Windows advisory: https://technet.microsoft.com/en-us/library/security/3009008.aspx See especially part 3: Disable SSL 3.0 in Windows, but note that a similar registry setting exists for CLIENT. Schannel works differently from openssl: SChannel can override default protocols (in registry), but cannot override enabled protocols (also in registry). A user or global administrator can force AMQP 1.0 SChannel connections to succeed during protocol negotiations over SSLv3 despite Proton's best efforts. Possible solutions on Windows: 1. always fail after the fact if an SSLv3 connection has actually been established 2. succeed for SSLV3 if registry allows it, but log a warning 3. succeed for SSLV3 only if registry allows it and env variable PROTON_SSLV3_UNSAFE=override_by_user Since SSLv3 is not considered secure, and there are no known legacy AMQP 1.0 that are unable to provide TLS1.0 or above, #1 seems to provide the greatest security without known inconvenience. -- 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-6187) Disable SSL v3 for Windows SChannel
Cliff Jansen created QPID-6187: -- Summary: Disable SSL v3 for Windows SChannel Key: QPID-6187 URL: https://issues.apache.org/jira/browse/QPID-6187 Project: Qpid Issue Type: Bug Reporter: Cliff Jansen -- 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-6187) Disable SSL v3 for Windows SChannel
[ https://issues.apache.org/jira/browse/QPID-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-6187: --- Description: Using same fix as in https://issues.apache.org/jira/browse/PROTON-719 Windows advisory: https://technet.microsoft.com/en-us/library/security/3009008.aspx See especially part 3: Disable SSL 3.0 in Windows, but note that a similar registry setting exists for CLIENT. Schannel works differently from openssl: SChannel can override default protocols (in registry), but cannot override enabled protocols (also in registry). A user or global administrator can force AMQP 1.0 SChannel connections to succeed during protocol negotiations over SSLv3 despite Proton's best efforts. Possible solutions on Windows: 1. always fail after the fact if an SSLv3 connection has actually been established 2. succeed for SSLV3 if registry allows it, but log a warning 3. succeed for SSLV3 only if registry allows it and env variable PROTON_SSLV3_UNSAFE=override_by_user Since SSLv3 is not considered secure, and there are no known legacy AMQP 1.0 that are unable to provide TLS1.0 or above, #1 seems to provide the greatest security without known inconvenience. Disable SSL v3 for Windows SChannel --- Key: QPID-6187 URL: https://issues.apache.org/jira/browse/QPID-6187 Project: Qpid Issue Type: Bug Reporter: Cliff Jansen Using same fix as in https://issues.apache.org/jira/browse/PROTON-719 Windows advisory: https://technet.microsoft.com/en-us/library/security/3009008.aspx See especially part 3: Disable SSL 3.0 in Windows, but note that a similar registry setting exists for CLIENT. Schannel works differently from openssl: SChannel can override default protocols (in registry), but cannot override enabled protocols (also in registry). A user or global administrator can force AMQP 1.0 SChannel connections to succeed during protocol negotiations over SSLv3 despite Proton's best efforts. Possible solutions on Windows: 1. always fail after the fact if an SSLv3 connection has actually been established 2. succeed for SSLV3 if registry allows it, but log a warning 3. succeed for SSLV3 only if registry allows it and env variable PROTON_SSLV3_UNSAFE=override_by_user Since SSLv3 is not considered secure, and there are no known legacy AMQP 1.0 that are unable to provide TLS1.0 or above, #1 seems to provide the greatest security without known inconvenience. -- 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-6187) Disable SSL v3 for Windows SChannel
[ https://issues.apache.org/jira/browse/QPID-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-6187: --- Component/s: C++ Client Environment: windows Fix Version/s: 0.31 Assignee: Cliff Jansen Disable SSL v3 for Windows SChannel --- Key: QPID-6187 URL: https://issues.apache.org/jira/browse/QPID-6187 Project: Qpid Issue Type: Bug Components: C++ Client Environment: windows Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.31 Using same fix as in https://issues.apache.org/jira/browse/PROTON-719 Windows advisory: https://technet.microsoft.com/en-us/library/security/3009008.aspx See especially part 3: Disable SSL 3.0 in Windows, but note that a similar registry setting exists for CLIENT. Schannel works differently from openssl: SChannel can override default protocols (in registry), but cannot override enabled protocols (also in registry). A user or global administrator can force AMQP 1.0 SChannel connections to succeed during protocol negotiations over SSLv3 despite Proton's best efforts. Possible solutions on Windows: 1. always fail after the fact if an SSLv3 connection has actually been established 2. succeed for SSLV3 if registry allows it, but log a warning 3. succeed for SSLV3 only if registry allows it and env variable PROTON_SSLV3_UNSAFE=override_by_user Since SSLv3 is not considered secure, and there are no known legacy AMQP 1.0 that are unable to provide TLS1.0 or above, #1 seems to provide the greatest security without known inconvenience. -- 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
Review Request 26865: disable SSLV3 for proton-c with Windows SChannel
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/26865/ --- Review request for qpid, Chug Rolke and Kenneth Giusti. Bugs: PROTON-719 https://issues.apache.org/jira/browse/PROTON-719 Repository: qpid Description --- Do not allow ssl v3 Proton connections even if user has set registry entries forcing SChannel to request/accept ssl v3. Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/schannel.c 1632478 Diff: https://reviews.apache.org/r/26865/diff/ Testing --- Windoww XP - Windows 8.1 32/64 bit VS2008-VS2013 VS2008 failed first attempt for fix Thanks, Cliff Jansen
Review Request 26142: Help Windows find getservbyname AMQP services
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/26142/ --- Review request for qpid and Rafael Schloming. Bugs: PROTON-701 https://issues.apache.org/jira/browse/PROTON-701 Repository: qpid Description --- Despite being an official suppporter and Azure user, Windows doesn't yet know about amqp and amqps ports. Pythonic enough? Prefer test restricted to Windows or (existing) same test everywhere? Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/python/proton.py 1628229 Diff: https://reviews.apache.org/r/26142/diff/ Testing --- Windows + RHEL6 Thanks, Cliff Jansen
Review Request 26075: Document Proton-c IO restrictions for 0.8 release
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/26075/ --- Review request for qpid. Bugs: PROTON-668 https://issues.apache.org/jira/browse/PROTON-668 Repository: qpid Description --- This describes my best guess of balancing convenience for the developer versus performance. Ultimately, with the exception of stickiness between completion ports and sockets, which prevents moving a socket between or out of a pn_io_t, any Posix behavior can probably be mimicked in Windows, but at a performance penalty. With these restrictions, third party event loops are supported. Proton event loops can also accommodate external non-sockets if that is useful (if dispensed with, that makes Windows code easier). Multi-threaded IO as currently used in Dispatch is also supported. It is worth noting Bozo's points that the interface doesn't always make sense for multithreaded ops: pn_io_error() and pn_io_wouldblock(). Finally, it should be noted that the Windows code has some way to go to satisfy the above, but understanding the intended supported capabilities needs to come first. Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/io.h 1627716 Diff: https://reviews.apache.org/r/26075/diff/ Testing --- N/A Thanks, Cliff Jansen
Review Request 26013: Basic client SSL/TLS support via SChannel on Windows
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/26013/ --- Review request for qpid and Kenneth Giusti. Bugs: PROTON-581 https://issues.apache.org/jira/browse/PROTON-581 Repository: qpid Description --- This patch does simple client side TLS only. No server support yet, and no client certificates. Full functionality will come in the Proton 0.9 timeframe. This SChannel implementation can be used to communicate with a qpidd broker with AMQP 1.0 support and with the Azure Service Bus. It is based on Proton's openssl.c for basic structure and Qpid's SslAsynchIO.cpp for the SChannel bits. It has minor improvements over the latter with the ability to send and detect shutdown alerts, catch additional continuation record cases, and use DeleteSecurityContext() on teardown. Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1627442 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/schannel.c PRE-CREATION Diff: https://reviews.apache.org/r/26013/diff/ Testing --- Tested against qpidd and Azure Service Bus Thanks, Cliff Jansen
[jira] [Commented] (QPID-5842) Allow SSL hostname verification to be disabled on windows
[ https://issues.apache.org/jira/browse/QPID-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14137308#comment-14137308 ] Cliff Jansen commented on QPID-5842: This is not addressed yet in Qpid or Proton. It's my next objective on Proton after sorting out all other IO related errors in ctest. Cliff Allow SSL hostname verification to be disabled on windows - Key: QPID-5842 URL: https://issues.apache.org/jira/browse/QPID-5842 Project: Qpid Issue Type: Bug Components: C++ Client Environment: Windows Reporter: Gordon Sim Assignee: Cliff Jansen Fix For: 0.29 sometimes the certficate doesn't match the address used to establish the connection, and it would be convenient to be able to disable the verification for those 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] (QPID-5033) [Windows C++ client] An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full
[ https://issues.apache.org/jira/browse/QPID-5033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved QPID-5033. Resolution: Fixed Fix Version/s: 0.31 [Windows C++ client] An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full -- Key: QPID-5033 URL: https://issues.apache.org/jira/browse/QPID-5033 Project: Qpid Issue Type: Bug Components: C++ Client Environment: Windows, different versions Reporter: JAkub Scholz Assignee: Cliff Jansen Fix For: 0.31 Attachments: client-trace.log, client.cpp As discussed on the user mailing list (http://qpid.2158936.n2.nabble.com/Qpid-throwed-WSAENOBUFS-while-receiving-data-from-a-broker-td7592938.html), when receiving a large amounts of messages over SSL using a receiver prefetch, the clients fails with an exception An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. This exception seems to originate from the SslAsynchIO class, method sslDataIn. Decreasing the capacity seems to improve the frequency with which the problem appears. However with 1MB messages, even capacity 1 doesn't seem to work. The problem seems to be quite easy to reproduce using following scenario: 1) Create a large queue on a broker (C++ / Linux) 2) Start feeding messages into the queue using C++/Linux program (in my case I used approximately 1kB messages) 3) Connect with a receiver (C++/Windows) using SSL and prefetch 1000 (no client authentication, I used username password) 4) Wait few seconds to see the error in the receiver The source code of the receiver as well as the full trace+ log are attached. Please let me know should you need some additional information. -- 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
Review Request 25312: driver.c implemented with selectors and selectables
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/25312/ --- Review request for qpid. Bugs: PROTON-658 https://issues.apache.org/jira/browse/PROTON-658 Repository: qpid Description --- This also happens to build and pass ctest on Linux, however it fails to reliably pass the Dispatch test suite. Hence this patch is solely for Windows for now and I propose deferring it for Posix inclusion until a later Proton release. Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/driver.c 1622332 Diff: https://reviews.apache.org/r/25312/diff/ Testing --- see above Thanks, Cliff Jansen
Re: Review Request 24851: Windows SSl: the system lacked sufficient buffer space
On Aug. 21, 2014, 2:20 p.m., Chug Rolke wrote: What was the reproducer to expose this problem? Did it happen rarely or on demand? I'd be happy to try a reproducer and again with the fixed code to verify. Thanks Chuck. See the parent JIRA. There is a client.cpp attachment and I have a qpid-perftest command listed that reproduced the problem for me. The frequency seems to depend on circumstances, like OS version... perhaps because of driver or other differences that may affect the timing of how TCP packets or SSL segments get clumped together or separately. I tried tests with fats and slow networks and also inserting fake delays in the AsynchIO layer. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24851/#review51175 --- On Aug. 19, 2014, 3:01 p.m., Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24851/ --- (Updated Aug. 19, 2014, 3:01 p.m.) Review request for qpid, Andrew Stitcher and Steve Huston. Bugs: QPID-5033 https://issues.apache.org/jira/browse/QPID-5033 Repository: qpid Description --- This patch isolates the logic of using the correct amount of buffers and not hanging onto an unread buffer unless it actually is one. It has been heavily tested on Linux and only been lightly tested on Windows. See patch #2 for the better windows version. Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/AsynchIO.h 1618723 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/posix/AsynchIO.cpp 1618723 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/AsynchIO.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/AsynchIO.cpp 1618723 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/SslAsynchIO.cpp 1618723 Diff: https://reviews.apache.org/r/24851/diff/ Testing --- Thanks, Cliff Jansen
Review Request 24851: Windows SSl: the system lacked sufficient buffer space
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24851/ --- Review request for qpid, Andrew Stitcher and Steve Huston. Bugs: QPID-5033 https://issues.apache.org/jira/browse/QPID-5033 Repository: qpid Description --- This patch isolates the logic of using the correct amount of buffers and not hanging onto an unread buffer unless it actually is one. It has been heavily tested on Linux and only been lightly tested on Windows. See patch #2 for the better windows version. Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/AsynchIO.h 1618723 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/posix/AsynchIO.cpp 1618723 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/AsynchIO.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/AsynchIO.cpp 1618723 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/SslAsynchIO.cpp 1618723 Diff: https://reviews.apache.org/r/24851/diff/ Testing --- Thanks, Cliff Jansen
Re: Review Request 24851: Windows SSl: the system lacked sufficient buffer space
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24851/ --- (Updated Aug. 19, 2014, 3:01 p.m.) Review request for qpid, Andrew Stitcher and Steve Huston. Changes --- This patch is the same as the first but adds logic to share a single extra buffer for leftover plaintext and for extra SSL blocks/segments Bugs: QPID-5033 https://issues.apache.org/jira/browse/QPID-5033 Repository: qpid Description --- This patch isolates the logic of using the correct amount of buffers and not hanging onto an unread buffer unless it actually is one. It has been heavily tested on Linux and only been lightly tested on Windows. See patch #2 for the better windows version. Diffs (updated) - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/AsynchIO.h 1618723 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/posix/AsynchIO.cpp 1618723 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/AsynchIO.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/AsynchIO.cpp 1618723 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/SslAsynchIO.cpp 1618723 Diff: https://reviews.apache.org/r/24851/diff/ Testing --- Thanks, Cliff Jansen
[jira] [Assigned] (QPID-5033) [Windows C++ client] An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full
[ https://issues.apache.org/jira/browse/QPID-5033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen reassigned QPID-5033: -- Assignee: Cliff Jansen [Windows C++ client] An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full -- Key: QPID-5033 URL: https://issues.apache.org/jira/browse/QPID-5033 Project: Qpid Issue Type: Bug Components: C++ Client Environment: Windows, different versions Reporter: JAkub Scholz Assignee: Cliff Jansen Attachments: client-trace.log, client.cpp As discussed on the user mailing list (http://qpid.2158936.n2.nabble.com/Qpid-throwed-WSAENOBUFS-while-receiving-data-from-a-broker-td7592938.html), when receiving a large amounts of messages over SSL using a receiver prefetch, the clients fails with an exception An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. This exception seems to originate from the SslAsynchIO class, method sslDataIn. Decreasing the capacity seems to improve the frequency with which the problem appears. However with 1MB messages, even capacity 1 doesn't seem to work. The problem seems to be quite easy to reproduce using following scenario: 1) Create a large queue on a broker (C++ / Linux) 2) Start feeding messages into the queue using C++/Linux program (in my case I used approximately 1kB messages) 3) Connect with a receiver (C++/Windows) using SSL and prefetch 1000 (no client authentication, I used username password) 4) Wait few seconds to see the error in the receiver The source code of the receiver as well as the full trace+ log are attached. Please let me know should you need some additional information. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5033) [Windows C++ client] An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full
[ https://issues.apache.org/jira/browse/QPID-5033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102297#comment-14102297 ] Cliff Jansen commented on QPID-5033: I managed to reproduce using a simple ./qpid-perftest --count 10 -b somebroker.com -P ssl -p 5671 --subscribe The stack trace showed buffers in use: 1 async write 1 current read buffer 1 leftoverPlaintext buff plus a wanted extraBuff There was a spare buffer in the bufferQueue but getqueuedBuffer() would not give it up, holding it in reserve just in case it might be an unread buffer that had existing data that should not be clobbered. The test did not check if the buffer really was unread (i.e. contained any data). So increasing the buffer count to 5 buffers would allow for the fallow unread buffer, and has been seen to work on some systems. It turns out that the Linux driver (SSL and non-SSL) only needs two buffers. The other two are never used. The Windows AsynchIO driver needs at least three, but not necessarily the four it has reserved (and the fifth it hogs for no purpose). The existing implementation uses a spare buffer for partial plaintext frames waiting for the next SSL block/segment to be decoded, and another for extra SSL segments when there are more than one in a read buffer. However it doesn't need both at once, so I have made the fix work with a single extra buffer. I can't explain reports that increasing the buffer count even beyond 5 only delays the occurrence of this bug. I have manipulated timing in the AIO layer to force even 10 levels of recursion of sslDataIn without problem. I have tried all sorts of tests with varying numbers of IO threads, debug and release mode, 32 bit and 64 bit, recent Windows and older Windows. In case the bug persists, the patch provides some debugging information that will hopefully zero in on it. See https://reviews.apache.org/r/24851 [Windows C++ client] An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full -- Key: QPID-5033 URL: https://issues.apache.org/jira/browse/QPID-5033 Project: Qpid Issue Type: Bug Components: C++ Client Environment: Windows, different versions Reporter: JAkub Scholz Assignee: Cliff Jansen Attachments: client-trace.log, client.cpp As discussed on the user mailing list (http://qpid.2158936.n2.nabble.com/Qpid-throwed-WSAENOBUFS-while-receiving-data-from-a-broker-td7592938.html), when receiving a large amounts of messages over SSL using a receiver prefetch, the clients fails with an exception An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. This exception seems to originate from the SslAsynchIO class, method sslDataIn. Decreasing the capacity seems to improve the frequency with which the problem appears. However with 1MB messages, even capacity 1 doesn't seem to work. The problem seems to be quite easy to reproduce using following scenario: 1) Create a large queue on a broker (C++ / Linux) 2) Start feeding messages into the queue using C++/Linux program (in my case I used approximately 1kB messages) 3) Connect with a receiver (C++/Windows) using SSL and prefetch 1000 (no client authentication, I used username password) 4) Wait few seconds to see the error in the receiver The source code of the receiver as well as the full trace+ log are attached. Please let me know should you need some additional information. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request 24159: Provide a native IO completion port layer similar to the QPID version for Proton.
On Aug. 1, 2014, 8:58 p.m., Andrew Stitcher wrote: http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/iocp.c, line 577 https://reviews.apache.org/r/24159/diff/1/?file=646944#file646944line577 This is a strange name: does it actually read 0 bytes? Yes it does. The accepted way to get an async notification that unread bytes are available for reading on an IOCP registered handle is to perform a normal IOCP-capable read operation with a byte count of zero. complete_read() is where the IOCP completion event from the completion port is handled (just marks the selectable as PN_READABLE). Thanks very much for the review. I will fix the other raised issues as suggested. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24159/#review49376 --- On July 31, 2014, 6 p.m., Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24159/ --- (Updated July 31, 2014, 6 p.m.) Review request for qpid and Rafael Schloming. Bugs: PROTON-640 https://issues.apache.org/jira/browse/PROTON-640 Repository: qpid Description --- This patch follows the QPID AsynchIO.cpp version fairly closely with the following main differences: - addition of async connect - multiple outstanding concurrent writes (a write pipeline) - non-buffered reads - graceful close progressing to hard close (much as proposed in QPID-5668) Careful scrutiny of the selector API change is warranted (constructor). Thread safety is currently assured only by isolating a paired pn_selector_t and pn_io_t from other such pairs. If anticipated use cases suggest either that multiple selectors be used with an io, or with multiple io's, or that a socket should be movable between selectors during it's lifetime, then additional locking semantics will be required. These scenarios come for free in Linux where the OS barrier takes care of concurrency issues. By contrast, the Windows code implements the selector in user space. This API change just forces the pairing of the selector with the io. The user is still expected to free the selector when done. Perhaps this should be handled by the io when it closes, or some alternative API mechanism should be used. In any event, if the supported use cases preclude closely linking one selector with one io, then this is moot. Performance notes. The use of a write pipeline has a significant effect on sending performance, especially with a small number of connections. It would probably be a useful enhancement for the QPID code. On the read side, no async read buffer is used (relying instead on the OS input buffering system). This is because pn_recv() copies out the bytes anyway (rather than passing a buffer as in QPID). Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1614939 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/io.h 1614939 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger/messenger.c 1614939 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/io.c 1614939 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/iocp.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/iocp.c PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/selector.c 1614939 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/write_pipeline.c PRE-CREATION Diff: https://reviews.apache.org/r/24159/diff/ Testing --- 2000 msgr-send simultaneous connections to a msgr-recv -R instance. 32/64 bit. winxp and win7. Thanks, Cliff Jansen
Review Request 24159: Provide a native IO completion port layer similar to the QPID version for Proton.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24159/ --- Review request for qpid and Rafael Schloming. Bugs: PROTON-640 https://issues.apache.org/jira/browse/PROTON-640 Repository: qpid Description --- This patch follows the QPID AsynchIO.cpp version fairly closely with the following main differences: - addition of async connect - multiple outstanding concurrent writes (a write pipeline) - non-buffered reads - graceful close progressing to hard close (much as proposed in QPID-5668) Careful scrutiny of the selector API change is warranted (constructor). Thread safety is currently assured only by isolating a paired pn_selector_t and pn_io_t from other such pairs. If anticipated use cases suggest either that multiple selectors be used with an io, or with multiple io's, or that a socket should be movable between selectors during it's lifetime, then additional locking semantics will be required. These scenarios come for free in Linux where the OS barrier takes care of concurrency issues. By contrast, the Windows code implements the selector in user space. This API change just forces the pairing of the selector with the io. The user is still expected to free the selector when done. Perhaps this should be handled by the io when it closes, or some alternative API mechanism should be used. In any event, if the supported use cases preclude closely linking one selector with one io, then this is moot. Performance notes. The use of a write pipeline has a significant effect on sending performance, especially with a small number of connections. It would probably be a useful enhancement for the QPID code. On the read side, no async read buffer is used (relying instead on the OS input buffering system). This is because pn_recv() copies out the bytes anyway (rather than passing a buffer as in QPID). Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/CMakeLists.txt 1614939 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/include/proton/io.h 1614939 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/messenger/messenger.c 1614939 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/io.c 1614939 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/iocp.h PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/iocp.c PRE-CREATION http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/selector.c 1614939 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/windows/write_pipeline.c PRE-CREATION Diff: https://reviews.apache.org/r/24159/diff/ Testing --- 2000 msgr-send simultaneous connections to a msgr-recv -R instance. 32/64 bit. winxp and win7. Thanks, Cliff Jansen
Re: Review Request 23122: Proton map/hash entries can disappear
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23122/ --- (Updated July 2, 2014, 4:18 p.m.) Review request for qpid and Rafael Schloming. Changes --- The test case I had wasn't generic (it was based on actual data that would unreliably fail, depending on heisenburg's mood), so I did not include it in the regression testing. The first comment gave a clue how to make a generic test in the first place, so that's mostly what this refresh is about. The original code is unchanged except fixing the bogus assert (ick). Bugs: PROTON-617 https://issues.apache.org/jira/browse/PROTON-617 Repository: qpid Description --- The proposed fix tests for the case of being the first link in a multipart chain and copies the second entry over top and makes the old location of the second entry available for reuse. Diffs (updated) - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/object/object.c 1607407 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/tests/object.c 1607407 Diff: https://reviews.apache.org/r/23122/diff/ Testing --- Thanks, Cliff Jansen
Re: Review Request 23122: Proton map/hash entries can disappear
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23122/ --- (Updated July 2, 2014, 7:06 p.m.) Review request for qpid and Rafael Schloming. Changes --- revised to decref last, without reference to the map itself, as suggested Bugs: PROTON-617 https://issues.apache.org/jira/browse/PROTON-617 Repository: qpid Description --- The proposed fix tests for the case of being the first link in a multipart chain and copies the second entry over top and makes the old location of the second entry available for reuse. Diffs (updated) - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/object/object.c 1607407 http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/tests/object.c 1607407 Diff: https://reviews.apache.org/r/23122/diff/ Testing --- Thanks, Cliff Jansen
Review Request 23122: Proton map/hash entries can disappear
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23122/ --- Review request for qpid and Rafael Schloming. Bugs: PROTON-617 https://issues.apache.org/jira/browse/PROTON-617 Repository: qpid Description --- The proposed fix tests for the case of being the first link in a multipart chain and copies the second entry over top and makes the old location of the second entry available for reuse. Diffs - http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/src/object/object.c 1605943 Diff: https://reviews.apache.org/r/23122/diff/ Testing --- Thanks, Cliff Jansen
[jira] [Commented] (QPID-5842) Allow SSL hostname verification to be disabled on windows
[ https://issues.apache.org/jira/browse/QPID-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042387#comment-14042387 ] Cliff Jansen commented on QPID-5842: Yes indeed. This is closely related to Proton work I am currently doing. Allow SSL hostname verification to be disabled on windows - Key: QPID-5842 URL: https://issues.apache.org/jira/browse/QPID-5842 Project: Qpid Issue Type: Bug Components: C++ Client Environment: Windows Reporter: Gordon Sim Assignee: Cliff Jansen Fix For: 0.29 sometimes the certficate doesn't match the address used to establish the connection, and it would be convenient to be able to disable the verification for those cases -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-5669) SSL negotiation failed spurious error on connection close (Windows C++)
[ https://issues.apache.org/jira/browse/QPID-5669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen closed QPID-5669. -- Resolution: Fixed Fix Version/s: 0.28 see https://reviews.apache.org/r/20122/ SSL negotiation failed spurious error on connection close (Windows C++) - Key: QPID-5669 URL: https://issues.apache.org/jira/browse/QPID-5669 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.27 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen Priority: Critical Fix For: 0.28 The AMQP 1.0 protocol transport driver has a different interaction between threads on connection close. This exposes bugs in the existing SslAsynchIO driver that leads to spurious error messages about failed negotiation setup, even though the setup succeeded long ago. The associated reason for the failure varies, because the contents of the error code is unrelated to any SSL processing error. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-5694) Windows C++ broker SSL sends non-existent negotiation token on shutdown
[ https://issues.apache.org/jira/browse/QPID-5694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen closed QPID-5694. -- Resolution: Fixed see https://reviews.apache.org/r/20319/ Windows C++ broker SSL sends non-existent negotiation token on shutdown --- Key: QPID-5694 URL: https://issues.apache.org/jira/browse/QPID-5694 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.27 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.27 The Windows SChannel logic for releasing resources on shutdown of a broker connection, negotiateStep(0);, incorrectly generates a new SSL handshake exchange after queueWriteClose, allowing for thread activity after the ServerSslAsynchIO object's memory has been deleted. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request 20319: Windows C++ broker SSL sends invalid negotiation token on shutdown
On April 14, 2014, 7:57 p.m., Andrew Stitcher wrote: Can't see a problem with this change, but I'm wondering if you might need to check state before sending in the normal data path? The current logic handles that case gracefully except a queueWrite after a queueDelete which doesn't happen from the transport layers. This eliminates that case (and only comes up on server side code in this one instance). The other cases based on (status == SEC_I_CONTINUE_NEEDED) won't occur in a SCHANNEL_SHUTDOWN context. As far as I can tell, the code up to and and including state == Running is pretty robust (aside from a TODO note about renegotiating). All the fireworks seem to happen on shutdown. This fix hopefully remains small and tied to the SSL logic, with more ambitious improvements listed in QPID-5668 deferred for a future release. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20319/#review40305 --- On April 14, 2014, 3:44 p.m., Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20319/ --- (Updated April 14, 2014, 3:44 p.m.) Review request for qpid. Bugs: QPID-5694 https://issues.apache.org/jira/browse/QPID-5694 Repository: qpid Description --- This patch checks if the connection is closing before concluding that it has a handshake packet to send. It appears this bug has existed a long time, but the spurious packet was either dropped before sending or was ignored by the client. The recent other changes for QPID-5669 has changed the timing of the connection cleanup (sometimes sooner, sometimes later), allowing the problem to now cause random broker errors reasonably frequently, whereas they were infrequent or non-existent before. Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/SslAsynchIO.cpp 1587223 Diff: https://reviews.apache.org/r/20319/diff/ Testing --- Thanks, Cliff Jansen
Re: PROTON - amqp 1.0 support
Thanks for asking! But please note that AMQP-1.0 support on Windows is incrementally being added at this point, with the latest bits being SSL capability. A push-button build and full ctest integration is still in the future. You will get the best results working from the latest pending releases: http://people.apache.org/~rhs/qpid-proton-0.7rc2/ https://svn.apache.org/repos/asf/qpid/branches/0.28/ I currently build by hand, loosely as follows: - Choose 64 or 32 bit (or perform steps below twice in separate locations) - Install pre-requisites: boost, python to match bit-ness - Install cmake, ruby and swig (bit-ness doesn't matter) - cmake Proton setting CMAKE_INSTALL_PREFIX=C:\some\path - build INSTALL target for Proton in Visual Studio twice (Debug RelWithDebInfo) - cmake Qpid as for Proton but also set CMAKE_PREFIX_PATH=C:\some\path - confirm cmake says: Qpid proton found, amqp 1.0 support enabled - if not check paths set in C:\some\path\lib\cmake\Proton\ProtonConfig.cmake - build Debug and/or RelWithDebInfo versions Be sure to read the README files. That, plus the above should get you going. You will want to set your PATH to find python and ruby and swig, set BOOST_ROOT and BOOST_VERSION, and be consistent about 32/64 bit-ness when setting environment variables or selecting Visual Studio build options. The magic for Qpid to find Proton has changed very recently, so someone may suggest a better way to instruct cmake than I suggested above. With luck, someone may chime in and point you to a build script if they have one. Cliff On Fri, Apr 4, 2014 at 5:11 AM, DHF fhd_...@163.com wrote: Hi MaryDHinton, could you share the steps how to get the Windows port of the amqp project in QPID compiled? i will very appreciate! Thanks. -- View this message in context: http://qpid.2158936.n2.nabble.com/PROTON-amqp-1-0-support-tp7585425p7606419.html Sent from the Apache Qpid developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5668) Windows C++ AsynchIO layer enhancement
Cliff Jansen created QPID-5668: -- Summary: Windows C++ AsynchIO layer enhancement Key: QPID-5668 URL: https://issues.apache.org/jira/browse/QPID-5668 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Affects Versions: 0.26 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen Priority: Minor The Windows AsynchIO and its SSL counterpart, as originally written by Steve Huston, was lean and clean. A lot of subsequent fixes have made the code less elegant and have merely reduced the amount of errors without completely banishing them. The problems arise from various differences in sockets, pollers, and library teardown semantics between Posix and Windows. A socket close works quite a bit differently on Windows. The optimistic use of completions leaves dangling reads on close. Not all the functions you would like to use (say to cancel a read) are available in all versions of Windows. And then there is the lawlessness surrounding the death of the IO threads on exit versus a DLL unload. After recent wading through the code, I would propose that it could be made cleaner and more robust by the following: back out the existing fixes for the hangs and exit-related catastrophes add the following logic enforcement on a queueWriteClose: no new queued writes a reaper is enlisted to prevent hangs Sunny case: normal IO until last queued write completes after last write, new reads are discarded (even eof notification), winsock graceful shutdown() is called, closedCallback is invoked (even though not yet closed, same as Posix), otherwise behave as for stopWatch() keep monitoring completions until graceful close detected tell reaper all is well self delete as appropriate Rainy case: reaper thinks things are taking too long does a hard/abortive close on the socket and otherwise forces the sunny case activity to conclusion (no further hang possibilities). As posited, this requires a separate thread to initiate reaper activity or some cleverness with timeouts via poller::wait(t) to have the existing thread pool look after regular reaping. If all cleanup code is restricted to IO and reaper thread access (i.e. isolated from the main user thread), then sudden death of these threads on exit has no ill effect of resource leakage, and importantly, everything tidies up properly for the DLL unload case. If done properly, the original efficient and mostly lockless code can work as originally intended, and all the special case code of the shutdown and cleanup can be isolated to a reaper mechanism without hurting overall performance. Of course, the devil is in the details. This is proposed as a future work item. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5669) SSL negotiation failed spurious error on connection close (Windows C++)
Cliff Jansen created QPID-5669: -- Summary: SSL negotiation failed spurious error on connection close (Windows C++) Key: QPID-5669 URL: https://issues.apache.org/jira/browse/QPID-5669 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.27 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen Priority: Critical The AMQP 1.0 protocol transport driver has a different interaction between threads on connection close. This exposes bugs in the existing SslAsynchIO driver that leads to spurious error messages about failed negotiation setup, even though the setup succeeded long ago. The associated reason for the failure varies, because the contents of the error code is unrelated to any SSL processing error. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Review Request 20122: SSL negotiation failed spurious error on connection close (Windows C++)
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20122/ --- Review request for qpid. Bugs: QPID-5669 https://issues.apache.org/jira/browse/QPID-5669 Repository: qpid Description --- This fix does the following: It moves all testing for self-delete to the IO thread by means of a reaper callback. It frees the SChannel encrypt/decrypt resources in the queueForDeletion() method which guarantees that the resources are freed at the last point they can safely be done without the transport layer's own destructor cleaning up associated resources out of order. If forces a single winner between close and disconnect (see QPID-5668). This results in a small performance penalty on connection teardown, while allowing a tiny performance win in ordinary read processing. Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/AsynchIO.cpp 1585645 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/SslAsynchIO.h 1585645 http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/SslAsynchIO.cpp 1585645 Diff: https://reviews.apache.org/r/20122/diff/ Testing --- Windows 7, 32/64 bit clients, amqp1.0 and amqp0-10, C++ and C#, wifi/wired connections. Thanks, Cliff Jansen
