Review Request 25590: six percent speedup from inlining one function.

2014-09-12 Thread mick goulish 

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

Review request for qpid, Alan Conway, Andrew Stitcher, Gordon Sim, and Rafael 
Schloming.


Repository: qpid


Description
---

proton:  six percent speedup from inlining pn_data_node()


Diffs
-

  proton/trunk/proton-c/src/codec/codec.c 1624597 
  proton/trunk/proton-c/src/codec/data.h 1624597 

Diff: https://reviews.apache.org/r/25590/diff/


Testing
---

correctness test:did ctest -VV  three times with no fails.


performance test:   ten repetitions, before change and after change, of my 5 
million message test with proton-engine based C clients.


result is a 6.15% speedup, with good standard deviation
T-test says resuts have 1.1% chance of being random.


timing results:

before change:mean 39.15 seconds sigma 2.78
after change: mean 36.74 seconds sigma 2.02

two-tailed T-test:  P= 0.011i.e. 1.1% chance of this happening randomly.


( I think I can get more than this, but this fn is definitely the biggest 
single chunk, so I would like you to review just this one for now.   Any reason 
not to do this?   )


I am using callgrind data from a 100,000 message test to find most-called 
functions, with significant CPU usage, then looking at code to see which of 
those are small enough to (I hope) reasonably inline.


Thanks,

mick goulish

Re: Review Request 23545: [C++ client] Allow consumer flow control based on #bytes

2014-07-16 Thread mick goulish 

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

Ship it!



/trunk/qpid/cpp/src/qpid/client/amqp0_10/ReceiverImpl.cpp
https://reviews.apache.org/r/23545/#comment84102

I don't understand the /2 parts here.  Maybe a comment?


- mick goulish


On July 16, 2014, 9:59 a.m., Pavel Moravec wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/23545/
 ---
 
 (Updated July 16, 2014, 9:59 a.m.)
 
 
 Review request for qpid, Gordon Sim and mick goulish.
 
 
 Bugs: QPID-5895
 https://issues.apache.org/jira/browse/QPID-5895
 
 
 Repository: qpid
 
 
 Description
 ---
 
 AMQP 0-10:
 byteCredit in 0-10 ReceiverImpl renamed to byteWindow.
 
 Both (message and byte) window/capacity operate independently on each other.
 
 I had to add SessionImpl::getMaxPrefetchedBytes to get around pre-declared 
 class Connection.
 
 
 AMQP 1.0:
 If max-prefetched-bytes to be used, I fixed maxFrameForBytePrefetch in 'open' 
 performative to 8k. That should be enough high for most of messages and 
 should provide sufficient granularity of incoming-window.
 
 Note, pn_session_set_incoming_capacity sets session's byte capacity whereas 
 incoming_window is returned by proton method:
 
 size_t pn_session_incoming_window(pn_session_t *ssn)
 {
   uint32_t size = ssn-connection-transport-local_max_frame;
   if (!size) {
 return 2147483647; // biggest legal value
   } else {
 return (ssn-incoming_capacity - ssn-incoming_bytes)/size;
   }
 }
 
 If a user sets max-prefetched-bytes below 8k, the client will automatically 
 increase it to 8k with some warning (otherwise incoming-window would be zero 
 and no consumer would get a single message).
 
 Note, the 1.0 patch does not work due to QPID-5896 I plan to fix first.
 
 
 Diffs
 -
 
   /trunk/qpid/cpp/src/qpid/client/amqp0_10/ConnectionImpl.h 1609704 
   /trunk/qpid/cpp/src/qpid/client/amqp0_10/ConnectionImpl.cpp 1609704 
   /trunk/qpid/cpp/src/qpid/client/amqp0_10/ReceiverImpl.h 1609704 
   /trunk/qpid/cpp/src/qpid/client/amqp0_10/ReceiverImpl.cpp 1609704 
   /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.h 1609704 
   /trunk/qpid/cpp/src/qpid/client/amqp0_10/SessionImpl.cpp 1609704 
   /trunk/qpid/cpp/src/qpid/messaging/ConnectionOptions.h 1609704 
   /trunk/qpid/cpp/src/qpid/messaging/ConnectionOptions.cpp 1609704 
   /trunk/qpid/cpp/src/qpid/messaging/amqp/ConnectionContext.cpp 1609704 
 
 Diff: https://reviews.apache.org/r/23545/diff/
 
 
 Testing
 ---
 
 Automated tests passed (well, TestParseTcpIPv6 failed but that fails on trunk 
 as well - already reported).
 
 Manual tests on 0-10 passed as well. On 1.0, they would work (per tcpdump, 
 both max-frame-size in 'open' performative and incoming-window in 'begin'), 
 but only after QPID-5896 is fixed :-/ .
 
 (I will post the patch only after QPID-5896 is fixed (and after ACKs from 
 this review, of course :) )
 
 
 Thanks,
 
 Pavel Moravec

Review Request 23125: reduction of throughput regression

2014-06-27 Thread mick goulish 

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

Review request for qpid, Alan Conway and Gordon Sim.


Repository: qpid


Description
---

This is the diff for trunk - not previous versions.

This diff is *not* quite the same as the recent diffs I have sent you (Gordon 
and Alan).  It has one additional change.

Code outside of MessageTransfer no longer needs to worry about when to call 
getRequiredCredit or computeRequiredCredit.Outside code always calls 
getRequiredCredit.  That fn calls computeRequiredCredit and caches the result, 
thereafter using only the cached result.  

This eliminates problems where get() was being called before compute() -- but I 
felt that was a problem that code outside of MessageTransfer should not have to 
worry about.

I was not able to remove the const-ness of getRequiredCredit without causing a 
vast cataclysm of deconstification, so I left it const, but made mutable the 
two variables that it needs to change.


Change list for people who have not seen previous versions:

  * replace frame.map_if with purpose-written loop.  This reduced throughput 
regression by about half.

  * small change in SessionState to make sure requiredCredit gets calculated 
before routing is done.

  * all code outside of MessageTransfer now only calls getRequiredCredit.  If 
the number has not
yet been calculated -- that problem is encapsulated within MessageTransfer.


Diffs
-

  trunk/qpid/cpp/src/qpid/broker/MessageBuilder.cpp 1605215 
  trunk/qpid/cpp/src/qpid/broker/SessionState.cpp 1605215 
  trunk/qpid/cpp/src/qpid/broker/amqp_0_10/MessageTransfer.h 1605215 
  trunk/qpid/cpp/src/qpid/broker/amqp_0_10/MessageTransfer.cpp 1605215 
  trunk/qpid/cpp/src/qpid/framing/FrameSet.h 1605215 
  trunk/qpid/cpp/src/qpid/management/ManagementAgent.cpp 1605215 

Diff: https://reviews.apache.org/r/23125/diff/


Testing
---

make check, throughput testing  (see graph)

Hey.  how do I attach things?!?  dang it.  ok -- I will attach pretty graph to 
BZ https://bugzilla.redhat.com/show_bug.cgi?id=1011221


Thanks,

mick goulish

Review Request 23138: Last time, I promise, for throughput regression improvement.

2014-06-27 Thread mick goulish 

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

Review request for qpid, Alan Conway and Gordon Sim.


Repository: qpid


Description
---


Big difference this time is -- I understand now why I can't hide 
MessageTransfer::computeRequiredCredit, so I didn't.
But there is a problem in that code elsewhere sometimes calls getRequiredCredit 
before computeRequiredCredit has been called.
I would like to solve that problem separately, so for now I have just put a 
sternly-worded TODO in get().


Diffs
-

  trunk/qpid/cpp/src/qpid/broker/SessionState.cpp 1605815 
  trunk/qpid/cpp/src/qpid/broker/amqp_0_10/MessageTransfer.cpp 1605815 
  trunk/qpid/cpp/src/qpid/framing/FrameSet.h 1605815 

Diff: https://reviews.apache.org/r/23138/diff/


Testing
---

Re-ran my tests for average latency for message of size 2048, in range from 
1 to 2 messages per second.  Same performance as before.
In trunk code, this patch only helps a little, but it does no harm.   ( It does 
more good in the 0.22 version. )


Thanks,

mick goulish

Re: Review Request 18968: [C++ broker] userId is not passed to ACL when DIGEST-MD5 is used while creating link

2014-03-11 Thread mick goulish 

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

Ship it!


I can't think of any reason why this check should not be moved to this point.   
( And it looks like there is an excellent reason why it *must* be moved here... 
)

- mick goulish


On March 11, 2014, 8:06 a.m., Pavel Moravec wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/18968/
 ---
 
 (Updated March 11, 2014, 8:06 a.m.)
 
 
 Review request for qpid, Gordon Sim and mick goulish.
 
 
 Bugs: QPID-5621
 https://issues.apache.org/jira/browse/QPID-5621
 
 
 Repository: qpid
 
 
 Description
 ---
 
 Root cause of the problem: ACL for links is checked after getting 
 connection.startOk AMQP method. While DIGEST-MD5 (and other auth.methods) 
 provide userId later on - during connection.secureOk AMQP method.
 
 So the ACL check for the SASL mechanisms relying on challenge  response 
 should be postponed until ConnectionHandler::Handler::secureOk method.
 
 I have two issues with the patch:
 
 
 1) How to identify SASL methods relying on challenge  response? I used 
 ((body.getMechanism()==ANONYMOUS)||(body.getMechanism()==PLAIN)) test 
 there but dont like the explicit SASL mechs comparison..
 (And I am not even 100% sure the list of mechanisms is correct - I just 
 *guess* SSL or GSSAPI sends challenge and response as well.
 
 
 2) Can a user have empty username? If so, then in the test:
 
 if ((connection.getUserId()!=)  (connection.isFederationLink()))
 
 the first condition will never match - while the condition is necessary as 
 usually SASL authentication requires several challenge+response exchanges, 
 i.e. several connection.secureOk methods received, while only the latest one 
 has userId finally set.
 
 
 Diffs
 -
 
   /trunk/qpid/cpp/src/qpid/broker/ConnectionHandler.cpp 1576205 
 
 Diff: https://reviews.apache.org/r/18968/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Pavel Moravec

Re: Review Request: PROTON-200: messenger::recv(-1) allows unlimited credit to all receivers.

2013-02-18 Thread mick goulish 

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

Ship it!


Ship It!

- mick goulish


On Feb. 18, 2013, 8:58 p.m., Kenneth Giusti wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/9503/
 ---
 
 (Updated Feb. 18, 2013, 8:58 p.m.)
 
 
 Review request for qpid, mick goulish, Rafael Schloming, and Philip Harvey.
 
 
 Description
 ---
 
 This implements the recv(-1) api change:  passing -1 to messenger::recv() 
 causes messenger to grant one credit to every active receiver link.
 
 Note this does not implement the same behavior for the Java implementation of 
 messenger - not sure even if the same bug is present with that implementation.
 
 
 This addresses bug proton-200.
 https://issues.apache.org/jira/browse/proton-200
 
 
 Diffs
 -
 
   /proton/trunk/proton-c/bindings/python/proton.py 1447222 
   /proton/trunk/proton-c/include/proton/cproton.i 1447222 
   /proton/trunk/proton-c/include/proton/messenger.h 1447222 
   /proton/trunk/proton-c/src/messenger.c 1447222 
   
 /proton/trunk/proton-j/proton/src/main/java/org/apache/qpid/proton/messenger/impl/MessengerImpl.java
  1447222 
   /proton/trunk/tests/python/proton_tests/messenger.py 1447222 
 
 Diff: https://reviews.apache.org/r/9503/diff/
 
 
 Testing
 ---
 
 additional python unit test to exercise this problem.
 
 
 Thanks,
 
 Kenneth Giusti

Re: Review Request: PROTON-200: messenger::recv(-1) allows unlimited credit to all receivers.

2013-02-18 Thread mick goulish 


 On Feb. 19, 2013, 1:17 a.m., mick goulish wrote:
  Ship It!

In my 2-send 1-receiver case, using this patch, I'm now getting interleaved 
messages at the receiver as I expect.
Hooray ! 


- mick


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


On Feb. 18, 2013, 8:58 p.m., Kenneth Giusti wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/9503/
 ---
 
 (Updated Feb. 18, 2013, 8:58 p.m.)
 
 
 Review request for qpid, mick goulish, Rafael Schloming, and Philip Harvey.
 
 
 Description
 ---
 
 This implements the recv(-1) api change:  passing -1 to messenger::recv() 
 causes messenger to grant one credit to every active receiver link.
 
 Note this does not implement the same behavior for the Java implementation of 
 messenger - not sure even if the same bug is present with that implementation.
 
 
 This addresses bug proton-200.
 https://issues.apache.org/jira/browse/proton-200
 
 
 Diffs
 -
 
   /proton/trunk/proton-c/bindings/python/proton.py 1447222 
   /proton/trunk/proton-c/include/proton/cproton.i 1447222 
   /proton/trunk/proton-c/include/proton/messenger.h 1447222 
   /proton/trunk/proton-c/src/messenger.c 1447222 
   
 /proton/trunk/proton-j/proton/src/main/java/org/apache/qpid/proton/messenger/impl/MessengerImpl.java
  1447222 
   /proton/trunk/tests/python/proton_tests/messenger.py 1447222 
 
 Diff: https://reviews.apache.org/r/9503/diff/
 
 
 Testing
 ---
 
 additional python unit test to exercise this problem.
 
 
 Thanks,
 
 Kenneth Giusti

Re: Review Request: Abstraction for SASL server role that is not tied to 0-10

2012-11-02 Thread mick goulish 

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

Ship it!



/trunk/qpid/cpp/src/qpid/NullSaslServer.cpp
https://reviews.apache.org/r/7565/#comment28040

I feel kind of funny about throwing for an error in an input to the system 
-- but definitely should log it.info?  error?


Sorry it took me so long to get to this.
All I can respond to now is overall understandability.
This new code seems hugely more comprehensible / cleaner than what I remember.  
Oh yes, please ship it.

- mick goulish


On Oct. 12, 2012, 4:47 p.m., Gordon Sim wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/7565/
 ---
 
 (Updated Oct. 12, 2012, 4:47 p.m.)
 
 
 Review request for qpid, michael goulish, Ted Ross, and mick goulish.
 
 
 Description
 ---
 
 The current broker::SaslAuthenticator mixes 0-10 protocol handshaking with 
 the sasl interactions. This patch adds a cleaner abstraction of the server 
 role in SASL along side that already in place for the client. This is then 
 used in the 1.0 SASL implementation.
 
 (Note this patch assumes and partially includes 
 https://reviews.apache.org/r/7562/ as I could not find an easy way to 
 separate out commits in git into review-board compatible patches).
 
 
 This addresses bug QPID-4368.
 https://issues.apache.org/jira/browse/QPID-4368
 
 
 Diffs
 -
 
   /trunk/qpid/cpp/src/CMakeLists.txt 1397295 
   /trunk/qpid/cpp/src/Makefile.am 1397295 
   /trunk/qpid/cpp/src/qpid/NullSaslServer.h PRE-CREATION 
   /trunk/qpid/cpp/src/qpid/NullSaslServer.cpp PRE-CREATION 
   /trunk/qpid/cpp/src/qpid/Sasl.h 1397295 
   /trunk/qpid/cpp/src/qpid/SaslFactory.h 1397295 
   /trunk/qpid/cpp/src/qpid/SaslFactory.cpp 1397295 
   /trunk/qpid/cpp/src/qpid/SaslServer.h PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/7565/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Gordon Sim

Review Request: browse-only queues

2012-09-06 Thread mick goulish 

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

Review request for qpid, Alan Conway, Gordon Sim, and Kenneth Giusti.


Description
---

browse-only queues

prevent consumer from acquiring, and prevent queue from dequeing -- no change 
to any class except Queue, and QueueSettings.


yes, questions: 

  1. is it OK to *not* change anything else.  i.e. i don't see that read-credit 
should be affected.

  2. also, i did not want to change anything except Queue -- i.e. no change to 
Consumer cursor.  Let it think that it is consuming -- but Queue keeps 
messages.  This might allow queue to change back and forth from browse-only to 
normal, if we ever care.


Diffs
-

  trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1376905 
  trunk/qpid/cpp/src/qpid/broker/QueueSettings.h 1376905 
  trunk/qpid/cpp/src/qpid/broker/QueueSettings.cpp 1376905 

Diff: https://reviews.apache.org/r/6943/diff/


Testing
---

passed make check except for 1 HA test, on recent trunk
Create queue with browse-only arg, load 10 messages, and then see that 
consumer can 'consume' any number of time, but same messages are always there.


Here are some scripts for testing:

 script: start_broker ---
#! /bin/bash


PORT=5801
TRUNK=/home/mick/redhat/trunk
QPIDD=${TRUNK}/qpid/cpp/src/qpidd
QPID_CONFIG=${TRUNK}/qpid/tools/src/py/qpid-config
SPOUT=${TRUNK}/qpid/cpp/examples/messaging/spout
DRAIN=${TRUNK}/qpid/cpp/examples/messaging/drain
LOG=/tmp/qpidd.log


rm -f ${LOG}


echo Starting broker...
${QPIDD} \
  --auth=no  \
  --log-enable info+ \
  --log-to-file ${LOG} \
  --log-hires-timestamp=yes \
  --log-source=yes \
  -p ${PORT} \
  -d
echo Broker started.
 end script -


 script: load_messages ---
#! /bin/bash


PORT=5801
TRUNK=/home/mick/redhat/trunk
QPIDD=${TRUNK}/qpid/cpp/src/qpidd
QPID_CONFIG=${TRUNK}/qpid/tools/src/py/qpid-config
SPOUT=${TRUNK}/qpid/cpp/examples/messaging/spout
DRAIN=${TRUNK}/qpid/cpp/examples/messaging/drain
LOG=/tmp/qpidd.log


echo    ${LOG}
echo Loading the messages ${LOG}
echo    ${LOG}
echo Loading the messages   

sleep 3
  
  
  # address was: 'q; {create: always, node:{ type: queue }}'
  
COUNT=10
echo Sending $COUNT messages...
${SPOUT} \
  -c 10 \
  --broker localhost:${PORT} \
  --content All Work and No Play Make Mick a Dull Boy \
  'q; {create: always, node:{type:queue , 
x-declare:{arguments:{browse-only:1'

echo  
echo Done sending messages.
echo  
 end script --


 script: consume -
#! /bin/bash


PORT=5801
TRUNK=/home/mick/redhat/trunk
QPIDD=${TRUNK}/qpid/cpp/src/qpidd
QPID_CONFIG=${TRUNK}/qpid/tools/src/py/qpid-config
SPOUT=${TRUNK}/qpid/cpp/examples/messaging/spout
DRAIN=${TRUNK}/qpid/cpp/examples/messaging/drain
LOG=/tmp/qpidd.log


echo    ${LOG}
echo Consuming the messages ${LOG}
echo    ${LOG}
echo Consuming the messages   

sleep 5
  
${DRAIN} \
  --broker 'localhost:5801' \
  'q;'


echo done.
 end script --


 script: browse --
#! /bin/bash


PORT=5801
TRUNK=/home/mick/redhat/trunk
QPIDD=${TRUNK}/qpid/cpp/src/qpidd
QPID_CONFIG=${TRUNK}/qpid/tools/src/py/qpid-config
SPOUT=${TRUNK}/qpid/cpp/examples/messaging/spout
DRAIN=${TRUNK}/qpid/cpp/examples/messaging/drain
LOG=/tmp/qpidd.log

echo    ${LOG}
echo Browsing the messages ${LOG}
echo    ${LOG}
echo Browsing the messages   

sleep 5

${DRAIN} \
  --broker 'localhost:5801' \
  'q; {mode: browse}'
  

echo done.
 end script --


Thanks,

mick goulish

Re: Review Request: browse-only queues

2012-09-06 Thread mick goulish 

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

(Updated Sept. 6, 2012, 1:52 p.m.)


Review request for qpid, Alan Conway, Gordon Sim, and Kenneth Giusti.


Description
---

browse-only queues

prevent consumer from acquiring, and prevent queue from dequeing -- no change 
to any class except Queue, and QueueSettings.


yes, questions: 

  1. is it OK to *not* change anything else.  i.e. i don't see that read-credit 
should be affected.

  2. also, i did not want to change anything except Queue -- i.e. no change to 
Consumer cursor.  Let it think that it is consuming -- but Queue keeps 
messages.  This might allow queue to change back and forth from browse-only to 
normal, if we ever care.


Diffs
-

  trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1376905 
  trunk/qpid/cpp/src/qpid/broker/QueueSettings.h 1376905 
  trunk/qpid/cpp/src/qpid/broker/QueueSettings.cpp 1376905 

Diff: https://reviews.apache.org/r/6943/diff/


Testing
---

passed make check except for 1 HA test, on recent trunk
Create queue with browse-only arg, load 10 messages, and then see that 
consumer can 'consume' any number of time, but same messages are always there.


Here are some scripts for testing:

 script: start_broker ---
#! /bin/bash


PORT=5801
TRUNK=/home/mick/redhat/trunk
QPIDD=${TRUNK}/qpid/cpp/src/qpidd
QPID_CONFIG=${TRUNK}/qpid/tools/src/py/qpid-config
SPOUT=${TRUNK}/qpid/cpp/examples/messaging/spout
DRAIN=${TRUNK}/qpid/cpp/examples/messaging/drain
LOG=/tmp/qpidd.log


rm -f ${LOG}


echo Starting broker...
${QPIDD} \
  --auth=no  \
  --log-enable info+ \
  --log-to-file ${LOG} \
  --log-hires-timestamp=yes \
  --log-source=yes \
  -p ${PORT} \
  -d
echo Broker started.
 end script -


 script: load_messages ---
#! /bin/bash


PORT=5801
TRUNK=/home/mick/redhat/trunk
QPIDD=${TRUNK}/qpid/cpp/src/qpidd
QPID_CONFIG=${TRUNK}/qpid/tools/src/py/qpid-config
SPOUT=${TRUNK}/qpid/cpp/examples/messaging/spout
DRAIN=${TRUNK}/qpid/cpp/examples/messaging/drain
LOG=/tmp/qpidd.log


echo    ${LOG}
echo Loading the messages ${LOG}
echo    ${LOG}
echo Loading the messages   

sleep 3
  
  
  # address was: 'q; {create: always, node:{ type: queue }}'
  
COUNT=10
echo Sending $COUNT messages...
${SPOUT} \
  -c 10 \
  --broker localhost:${PORT} \
  --content All Work and No Play Make Mick a Dull Boy \
  'q; {create: always, node:{type:queue , 
x-declare:{arguments:{browse-only:1'

echo  
echo Done sending messages.
echo  
 end script --


 script: consume -
#! /bin/bash


PORT=5801
TRUNK=/home/mick/redhat/trunk
QPIDD=${TRUNK}/qpid/cpp/src/qpidd
QPID_CONFIG=${TRUNK}/qpid/tools/src/py/qpid-config
SPOUT=${TRUNK}/qpid/cpp/examples/messaging/spout
DRAIN=${TRUNK}/qpid/cpp/examples/messaging/drain
LOG=/tmp/qpidd.log


echo    ${LOG}
echo Consuming the messages ${LOG}
echo    ${LOG}
echo Consuming the messages   

sleep 5
  
${DRAIN} \
  --broker 'localhost:5801' \
  'q;'


echo done.
 end script --


 script: browse --
#! /bin/bash


PORT=5801
TRUNK=/home/mick/redhat/trunk
QPIDD=${TRUNK}/qpid/cpp/src/qpidd
QPID_CONFIG=${TRUNK}/qpid/tools/src/py/qpid-config
SPOUT=${TRUNK}/qpid/cpp/examples/messaging/spout
DRAIN=${TRUNK}/qpid/cpp/examples/messaging/drain
LOG=/tmp/qpidd.log

echo    ${LOG}
echo Browsing the messages ${LOG}
echo    ${LOG}
echo Browsing the messages   

sleep 5

${DRAIN} \
  --broker 'localhost:5801' \
  'q; {mode: browse}'
  

echo done.
 end script --


Thanks,

mick goulish

Re: Review Request: Provides the EventNotifier type, plus example agent and unit test.

2011-08-17 Thread mick goulish 

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



trunk/qpid/cpp/src/qmf/ConsoleSessionImpl.h
https://reviews.apache.org/r/1557/#comment3450

design question -- I was expecting something here like 
void addEventNotifier ( EventNotifierImpl * notifier, int eventMask = 
0x )
so that the user could create notifiers that would only get called for 
certain events.  Is it better to just send them all events and let them sort it 
out?


- mick


On 2011-08-17 14:07:58, Darryl Pierce wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/1557/
 ---
 
 (Updated 2011-08-17 14:07:58)
 
 
 Review request for qpid, Kenneth Giusti, michael goulish, and Ted Ross.
 
 
 Summary
 ---
 
 Provides a new method for providing notification to an interested party when 
 new messages are received.
 
 The EventNotifier class can be associated with either a console or agent 
 session. The object provides a file descriptor which then becomes readable 
 when there are messages to be processed.
 
 This implementation only supports Posix. There is some work necessary to get 
 a Windows implementation in place.
 
 
 Diffs
 -
 
   trunk/qpid/cpp/bindings/qmf2/examples/cpp/Makefile.am 1158370 
   trunk/qpid/cpp/bindings/qmf2/examples/cpp/event_driven_list_agents.cpp 
 PRE-CREATION 
   trunk/qpid/cpp/include/qmf/AgentSession.h 1158370 
   trunk/qpid/cpp/include/qmf/ConsoleSession.h 1158370 
   trunk/qpid/cpp/include/qmf/EventNotifier.h PRE-CREATION 
   trunk/qpid/cpp/src/CMakeLists.txt 1158370 
   trunk/qpid/cpp/src/qmf.mk 1158370 
   trunk/qpid/cpp/src/qmf/AgentSession.cpp 1158370 
   trunk/qpid/cpp/src/qmf/AgentSessionImpl.h PRE-CREATION 
   trunk/qpid/cpp/src/qmf/ConsoleSession.cpp 1158370 
   trunk/qpid/cpp/src/qmf/ConsoleSessionImpl.h 1158370 
   trunk/qpid/cpp/src/qmf/EventNotifier.cpp PRE-CREATION 
   trunk/qpid/cpp/src/qmf/EventNotifierImpl.h PRE-CREATION 
   trunk/qpid/cpp/src/qmf/EventNotifierImpl.cpp PRE-CREATION 
   trunk/qpid/cpp/src/qmf/PosixEventNotifierImpl.cpp PRE-CREATION 
   trunk/qpid/cpp/src/tests/EventNotifierTest.cpp PRE-CREATION 
   trunk/qpid/cpp/src/tests/Makefile.am 1158370 
 
 Diff: https://reviews.apache.org/r/1557/diff
 
 
 Testing
 ---
 
 An example agent takes the existing list_agents and uses an EventNotifier to 
 respond to incoming messages rather than blocking on the 
 ConsoleSession.nextReceiver() API.
 
 A unit test verifies that the file handle provides by the EventNotifier type 
 is properly updating on incoming messgaes.
 
 
 Thanks,
 
 Darryl