Are you using a multithreaded TServer with concurrent client requests? If so, then you can't declare just a single list in your handler. Handler access is not threadsafe.
On Tue, Sep 20, 2011 at 11:01 AM, Marty Weiner <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> > > 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? > > > > > >
