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