Ah, sorry, I should have been clearer. This is from the server end.
Some other thread can easily serialize my data? So then that means that I
must always
allocate a new List<Long> and return it? Is there a way to avoid the
allocation overhead? I'd
prefer to have my GC activity not scale with frequency of read requests, if
possible.
By "thread local", I was referring to lists I allocated in my handler.java
file (the derivation
of the interfaces made by the thrift generator).
Thanks for the help!
On Tue, Sep 20, 2011 at 9:21 AM, Bryan Duxbury <br...@rapleaf.com> wrote:
> I presume that you're talking about this method from the server side of
> things. The problem is that, depending on the TServer you're using, when
> you
> return the List<Long>, it might not necessarily be getting serialized in
> the
> same thread.
>
> Also, what is your "per thread" reservation mechanism? ThreadLocals?
>
> On Sat, Sep 17, 2011 at 12:02 AM, Marty Weiner <ma...@pinterest.com>
> wrote:
>
> > I'm trying to understand (what I think is) a bug in the generated java
> > code. My thrift schema generates this method:
> > public List<Long> listGet(String key) throws org.apache.thrift.TException
> {
> > ... }
> >
> > To avoid an allocation on every listGet request, I'd like to keep a
> > pre-allocated List<Long> buffer per thread, fill that, and return it.
> When
> > I do this, it doesn't take much for me to get a
> > ConcurrentModificationError,
> > possibly because the wrappers around my listGet method are holding onto
> it?
> > What's the recommended way to avoid the extra allocations?
> >
>
