thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Utku Can Topçu <u...@topcu.gen.tr>
Subject Re: Java Server Does Not Close Sockets immediately for oneway methods
Date Thu, 11 Feb 2010 18:18:21 GMT
Thanks for your comments,

I think if a patch is to be submitted to the codebase, I think we should
have a workaround like Joel has encouraged me on developing further. But I'm
not sure if I'll somehow have to patch the code generator written in C.

Best Regards,
Utku

On Thu, Feb 11, 2010 at 8:04 PM, Bryan Duxbury <bryan@rapleaf.com> wrote:

> David is correct, but maybe I can clarify. Even if the client-side is
> completely done with the oneway request, the server may not have come
> anywhere near completing the request. As such, the server side socket stays
> open until the server has completed the request all the way.
>
> In the particular case of oneway methods, you could conceivably close the
> socket as soon as the request is fully read into the server's memory. If
> this were a simple change and you submitted a patch for it, I would
> entertain it.
>
> However, I think a better solution would be to use one of the Thrift
> servers
> like TNonblockingServer that support connection limiting. This way, they
> will only open as many sockets as you allow it to before accepting new
> clients.
>
> On Thu, Feb 11, 2010 at 9:49 AM, Utku Can Topçu <utku@topcu.gen.tr> wrote:
>
> > I'm sorry to post once more again,
> > The connection is apparently useless, and keeping it open causes "too
> many
> > open files" eventually.
> >
> > On Thu, Feb 11, 2010 at 7:46 PM, Utku Can Topçu <utku@topcu.gen.tr>
> wrote:
> >
> > > David, Thank you for the quick response
> > >
> > > Since the method is oneway as defined by Thrift IDL, should we still
> > insist
> > > on keeping the connection alive until the method finishes? Because of
> the
> > > "asynchronous call" paradigm, the assumption is the fact that the
> client
> > > would not care about the execution, result etc... of the related
> method.
> > >
> > > Best,
> > > Utku
> > >
> > >
> > >
> > > On Thu, Feb 11, 2010 at 7:42 PM, David Reiss <dreiss@facebook.com>
> > wrote:
> > >
> > >> That sounds right.  The client closes the socket, the server is still
> > >> processing the method, and it closes its side as soon as it finishes.
> > >>
> > >> Utku Can Topçu wrote:
> > >> > Hello David,
> > >> >
> > >> > I think there's a point missing. Even though the client (PHP in our
> > >> case)
> > >> > issues a "$transport->close()" the socket connection on the Server
> > Side
> > >> is
> > >> > closed just after the execution of the oneway method.
> > >> >
> > >> > Best,
> > >> > Utku
> > >> >
> > >> > On Thu, Feb 11, 2010 at 7:28 PM, David Reiss <dreiss@facebook.com>
> > >> wrote:
> > >> >
> > >> >> We don't close the sockets because you are allowed to send multiple
> > >> >> requests
> > >> >> over the same connection.
> > >> >>
> > >> >> Requests received over the same connection are processed serially,
> in
> > >> >> order.
> > >> >>
> > >> >> Does that answer your question?
> > >> >>
> > >> >> Utku Can Topçu wrote:
> > >> >>> While experimenting with the oneway (asynchronous) service
calls
> to
> > a
> > >> >> Java
> > >> >>> Service, we've faced a serious connection overload.
> > >> >>> Currently we're using TBufferedTransport together with
> > >> TThreadPoolServer
> > >> >> on
> > >> >>> the Server side.
> > >> >>> Diving deep into the Java Thrift Libraries, auto-generated
Java
> > >> classes
> > >> >> and
> > >> >>> debugging the code, we've seen that the oneway void methods
on the
> > >> Java
> > >> >>> Server side does not close the "TSocket"s that are related
to the
> > >> methods
> > >> >> in
> > >> >>> question.
> > >> >>>
> > >> >>> Is this a design decision? Should we treat this as a bug?
> > >> >>>
> > >> >>> Our current solution to this problem is employing a
> > ThreadPoolExecutor
> > >> >> for
> > >> >>> each oneway method, we immediately transform the asynchronous
> > requests
> > >> >> into
> > >> >>> Runnables and place them in the thread pool and return from
the
> > >> method.
> > >> >>>
> > >> >>> I think a similar approach should be implemented in the Thrift
> Java
> > >> >>> libraries.
> > >> >>>
> > >> >>> What do you think on this issue?
> > >> >>>
> > >> >>> Best Regards,
> > >> >>> Utku
> > >>
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message