Trident does not use all threads (executor?) for a bolt

Hello We have a Trident topology with about 30 bolts When we monitor the process with visualVM and java monitor in eclipse, we see that only one thread work for a specific bolt and all other threads do nothing all our connections between bolts includes a partitionBy(id), indeed, there is no

RE: worker dies after view minutes

. At basic level your parallelism depends on the number of cpus as you are increasing no.of threads executing the vm. You probably want to increase the JVM memory as well. On Fri, Jul 24, 2015, at 05:58 AM, Eric Ruel wrote: is there a limit of bolts/threads we can have within a single worker

RE: worker dies after few minutes

you are increasing no.of threads executing the vm. You probably want to increase the JVM memory as well. On Fri, Jul 24, 2015, at 05:58 AM, Eric Ruel wrote: is there a limit of bolts/threads we can have within a single worker? our topology has almost 140 bolts including those created by tride

RE: worker dies after view minutes

whole loop, or something like that? is there any values in storm.yaml I should modify to support that number of threads? De : Eric Ruel Envoyé : 23 juillet 2015 13:57 À : user@storm.apache.org Objet : RE: worker dies after view minutes Originally, we had

RE: worker dies after view minutes

bolt's execute method?. It does look like there is a RuntimeException happening " Error when processing event java.lang.RuntimeException: " Its up to the user to catch any exception and log or do something with instead of throwing it back to worker jvm -Harsha On Wed, Jul 22

RE: worker dies after view minutes

ethod?. It does look like there is a RuntimeException happening " Error when processing event java.lang.RuntimeException: " Its up to the user to catch any exception and log or do something with instead of throwing it back to worker jvm -Harsha On Wed, Jul 22, 2015, at 07:43 AM, Eric Rue

RE: worker dies after view minutes

note: I use storm 0.9.4, and tried the trunk for 0.9.6 and still have the problem De : Eric Ruel Envoyé : 22 juillet 2015 10:43 À : user@storm.apache.org Objet : worker dies after view minutes Hello the workers in my topology dies after 1,2 minutes I tried

worker dies after view minutes

Hello the workers in my topology dies after 1,2 minutes I tried to change the config about the heartbeat, cluster or local mode, but they always die any idea? 10:38:38.019 ERROR backtype.storm.daemon.worker - Error when processing event java.lang.RuntimeException: org.apache.storm.zookee

Mixing java/python with trident

hello We have a Trident topology, and some bolts need to execute python code. currently, we call them by WebService but it's harder to scale... Need to modify the parallellism of this bolt Need to add VM of those webservices, Need to modify haproxy to include those new servers... I know it'

RE: High CPU usage

probably caused by https://issues.apache.org/jira/browse/STORM-503 https://issues.apache.org/jira/browse/STORM-350 De : Binh Nguyen Van Envoyé : 22 mai 2015 04:57 À : user@storm.apache.org Objet : High CPU usage Hi all, I am using Storm-0.9.4 to build a Tri

RE: upgrade of disruptor

https://issues.apache.org/jira/browse/STORM-350? De : Benjamin Cuthbert Envoyé : 28 mars 2015 14:23 À : user@storm.apache.org Objet : upgrade of disruptor All, is there any chance of an upgrade to the latest disruptor library? Looking at maven central there is

RE: Short disruptor queue wait time leads to high CPU usage when idle

De : Eric Ruel Envoyé : 16 février 2015 10:12 À : user@storm.apache.org Objet : Short disruptor queue wait time leads to high CPU usage when idle any update on https://issues.apache.org/jira/browse/STORM-503 ? Is there a solution to avoid this problem if it can'

Short disruptor queue wait time leads to high CPU usage when idle

any update on https://issues.apache.org/jira/browse/STORM-503 ? Is there a solution to avoid this problem if it can't be fixed easily..

RE: Trident topology - can we deactivate batch ordering

The spout emit batches of 100 ids to process, some steps are faster to be executed in batches, like fetching data from the database which is done with an aggregator that emit all the same rows with additional values we need Trident because we need joins, merge, aggregator, etc but each batche