No problems based on it. I'm trying to understand what changed in the receive code with the latest release.
Can you point me to where in the newer code the messaging layer is doing the batching? On Mon, Aug 25, 2014 at 2:56 PM, Bobby Evans <[email protected]> wrote: > 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. > > -- Ce n'est pas une signature
