> On Oct. 1, 2012, 8:30 p.m., Hari Shreedharan wrote: > > flume-ng-core/src/main/java/org/apache/flume/channel/MemoryChannel.java, > > lines 330-342 > > <https://reviews.apache.org/r/6982/diff/3/?file=155699#file155699line330> > > > > The headers take space in memory. It is not reasonable to assume that > > the headers are "free." Otherwise the estimates are invalid and you could > > easily overrun memory. > > > > HashMaps do have a reasonable memory overhead.
I'm not saying we must calculate exact sizes. That might end up hitting performance. We must assume that the headers take some space - how it is calculated can be discussed - one is to add a fixed size overhead for the headers. The other is to use Instrumentation.getObjectSize() - Hari ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6982/#review12075 ----------------------------------------------------------- On Sept. 16, 2012, 3:54 a.m., Ted Malaska wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/6982/ > ----------------------------------------------------------- > > (Updated Sept. 16, 2012, 3:54 a.m.) > > > Review request for Flume. > > > Description > ------- > > 1. The user will be able to define a byteCapacity and a > byteCapacityBufferPercentage. > 2. Events byte size will be estimated from there body contents > 3. On put bytes are added to current total > 4. On commit any uncommitted takes are removed from the current byte total > 5. On rollover any uncommitted puts are removed from the current byte total > > > This addresses bug FLUME-1535. > https://issues.apache.org/jira/browse/FLUME-1535 > > > Diffs > ----- > > flume-ng-core/src/main/java/org/apache/flume/channel/MemoryChannel.java > c72e97c > flume-ng-core/src/test/java/org/apache/flume/channel/TestMemoryChannel.java > e070864 > > Diff: https://reviews.apache.org/r/6982/diff/ > > > Testing > ------- > > > Thanks, > > Ted Malaska > >
