Every time you send a tuple, it should be a new tuple. Secondly, when you send a tuple within the same process, the data is passed by reference, not serialized and deserialized. That means if you use local cluster, or even a remote cluster you will see that some of your data is sent by reference. So when you send a static variable by reference and then change it, subsequent bolts will see this change.
Note that in remote cluster, localOrShuffleGrouping will send if at all possible within the same process, and thereby avoid network / serialization / deserialization costs. ShuffleGrouping will send in process as well if there are any downstream bolts in the same process, because it uses round robin. FieldsGrouping is the same if your key has reasonable distribution. It's possible that you could avoid passing by reference when using none grouping or direct grouping but I'm not really sure why you would explicitly try to avoid this. Also I would note that passing then changing a static variable can be tricky; hopefully you have protected it against concurrent modification from other bolt tasks within the same process. On Sun, Jan 4, 2015 at 7:18 PM, hjh <[email protected]> wrote: > Hi, I am new to storm and I met a problem with tuple. In the local mode > does tuple between connected bolts share the same object? For example BoltA > emit a tuple to BoltB. If BoltB is processing the tuple (this tuple is > assigned to a private variable, say VAR, in BoltB) and at the same time > BoltA sends another tuple to BoltB, then VAR changed immediately. Does that > mean in local mode BoltA and BoltB share the same tuple instance?? And how > to deal with such situation? > > PS. I use java. > > Any suggestion is warmly welcomed > > > Thank you very much!!! > >
