replays (especially in
heavy throughput topologies).
If you can elaborate a little more on the performance cost of tracking tuples
or point to a document reflecting the same, that will be of great help.
Best,
T.I.
On Tue, Sep 13, 2016 at 12:26 PM, Hart, James W.
mailto:jwh...@seic.com>> w
Failures should be very infrequent, if they are not then rethink the code and
architecture. The performance cost of tracking tuples in the way that would be
required to replay at the failure is large, basically that method would slow
everything way down for very infrequent failures.
From: S G
bolt can’t process events without deserializing and
indexing the data in those files, which could take anything up to several
minutes. This can’t easily be farmed out to an external service, due to various
processing and infrastructure limitations
SimonC
From: Hart, James W. [mailto:jwh
Can you elaborate on what kind work is being done at startup?
If you are building some kind of cacheable lookup data, I would build that
elsewhere in a persistent cache, like redis, and then fetch and access it
through redis.
From: Simon Cooper [mailto:simon.coo...@featurespace.co.uk]
Sent: Tue
I have a 5 VM cluster with 16 gig 8 core machines, and 3 of the machines are
worker nodes. Can anyone give input on how many topologies should/can be run
on the cluster? We are currently running 40 topologies in this dev cluster and
having tons of stability and topology startup issues. These
I’m working on a topology that will be similar to this application so I was
thinking about this yesterday.
I’m thinking that if there is any significant work to do on messages in making
them into tuples, shouldn’t the message be emitted and the work be in a bolt?
I don’t think that bolt execut
