----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30898/#review72105 -----------------------------------------------------------
tests/tools/apps/c/reactor-recv.c <https://reviews.apache.org/r/30898/#comment118048> You should use pn_connection_release here and then you won't need the incref. The connection you are using was constructed inside the reactor, and so the reference you get to it is "borrowed." tests/tools/apps/c/reactor-recv.c <https://reviews.apache.org/r/30898/#comment118170> 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. - Rafael Schloming On Feb. 12, 2015, 2:58 a.m., Cliff Jansen wrote: > > ----------------------------------------------------------- > 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. > > > 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 1000000 -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 100000 -R & echo $i; usleep 200000; done > > > Thanks, > > Cliff Jansen > >
