Vadim, You can use codahale metrics (https://github.com/codahale/metrics) to count your internal queue number tuples Vladi
On Thu, Nov 13, 2014 at 2:06 PM, Kobi Salant <[email protected]> wrote: > Hi Vadim, > > Storm's internal disruptor queues are not accessible or can be monitored, > so you can not know the status of these queues. > > TOPOLOGY_MAX_SPOUT_PENDING is only relevant to the spout and if you are > dropping events, there is no reason you should reach the limit. > > If you are referring to your priority queue then you can create a JMX > access. > > Thanks > Kobi > > > On Thu, Nov 13, 2014 at 1:04 PM, Vadim Smirnov <[email protected]> wrote: > >> I am have topology Spout1->Bolt1->Bolt2. Sometimes Spout1 produce up to >> 1000 tuple/sec, Bolt1 can execute it, but Bolt 2 can only 700 tuple/sec. >> Some tuple very valuable, other not. We upgrade topology to: >> Spout1->Bolt1->BoltPriorityBuffer->Bolt2. BoltPriorityBuffer contains >> PriorityQueue and can drop valueless tuple if queue to Bolt2 bloated. >> >> Here question: How i am can see what queue to Bolt2 bloated ? Queue size >> or may be TOPOLOGY_MAX_SPOUT_PENDING event ? >> >> -- >> Vadim Smirnov >> > > > This message may contain confidential and/or privileged information. > If you are not the addressee or authorized to receive this on behalf of > the addressee you must not use, copy, disclose or take action based on this > message or any information herein. > If you have received this message in error, please advise the sender > immediately by reply email and delete this message. Thank you. >
