No, Thrift does not supply any threadsafe area. You have to use an object pool or ThreadLocal variable, etc.
On Tue, Sep 20, 2011 at 4:27 PM, Marty Weiner <[email protected]> wrote: > Ah ok. It is multithreaded and concurrent requests are allowed. Is there > a threadsafe area to allocate from? I assumed each handler object was its > own thread. > > On Sep 20, 2011, at 11:38 AM, Bryan Duxbury <[email protected]> wrote: > > > 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? > >>>> > >>> > >> >
