Sean, I think it was an oversight leaving the parameter in place still. Previously the code would take the messages and pull them out of the messaging layer putting them in a batch to be processed. In the newer code the messaging layer is already doing the batching. In fact the messages are coming from the client side pre batched. Are you running into performance or other problems with this change? If not please file a JIRA for this. We should probably remove the parameter completely and either remove or at a minimum deprecate Config.TOPOLOGY_RECEIVER_BUFFER_SIZE.
- Bobby On 8/24/14, 10:05 AM, "Sean Allen" <[email protected]> wrote: >It would appear that as of this commit: >https://github.com/apache/incubator-storm/commit/861a92eab8740cfc0f83ac4d7 >ade9a2ab04a8b9b > >That changing topology.receiver.buffer.size has no effect. > >mk-receive-thread is loader.clj still accepts max-buffer-size as an input >but the value isn't used within the function. > >I'm not sure if this was intentional additional code needs to be updated >to >reflect the lack of the option or if it a bug in the mk-receive-thread >code >that it has no effect.
