Hi Adam,
ok, good to know. I resolved to create the tuple from scratch in case it
needs to be resend. I don't where else in-place modification could hurt
in a linear process. Am I missing something?
Thanks,
Harald.
On 26.02.2014 15:48, Adam Lewis wrote:
I've already gotten slapped around on the list for doing in place
modifications, so let me pass it on :)
Don't modify tuple objects in place.
You shouldn't rely on serialization happening or not happening for
correctness.
On Mon, Feb 24, 2014 at 11:18 AM, Harald Kirsch
<[email protected] <mailto:[email protected]>> wrote:
Hi all,
my TOPOLOGY_MESSAGE_TIMEOUT_SECS was slightly to low. I got a fail
for a tuple and the spout just resend it.
One bolt normalizes a date in place in a field of the tuple. After
the spout resend the tuple, I got errors from the date parser
because the date was already normalized.
Since I currently have only one node, I know of course what happens.
The tuple was just the very same object that was already partially
processed when the timeout hit.
In a distributed setup I envisage the bolt to be on another machine
with a serialized copy of the spout's tuple such that changes to the
tuple are not reflected in the original. Would that be true?
I reckon from this that all processing in bolts needs to be
idempotent if I want to be able to replay failed tuples.
Is that true or am I doing something wrong?
Harald.
--
Harald Kirsch
Raytion GmbH
Kaiser-Friedrich-Ring 74
40547 Duesseldorf
Fon +49-211-550266-0 <tel:%2B49-211-550266-0>
Fax +49-211-550266-19 <tel:%2B49-211-550266-19>
http://www.raytion.com
--
Harald Kirsch
Raytion GmbH
Kaiser-Friedrich-Ring 74
40547 Duesseldorf
Fon +49-211-550266-0
Fax +49-211-550266-19
http://www.raytion.com
