Cancel outstanding request on Thrift client (0.8.0)

[James Paton <jp...@gmail.com>]

Hi,

I was wondering how one would go about canceling an ongoing request to a Thrift client from another thread? That is, suppose thread A makes a request and thread B waits for thread A to signal. Then some event E happens and thread B decides to give up on thread A. How does thread B cancel the request? Or is there a better way to do this? Keep in mind that the event E is not simply the elapsing of a timer.

-- Jim

Re: Cancel outstanding request on Thrift client (0.8.0)

[T Vinod Gupta <tv...@readypulse.com>]

i could find 2 messages in my archive related to this topic.. hope this
helps..
thanks

-------------------------------------------

I've implemented bi-directional event notifications using double-ended
servers (Thrift server on each end). Each end needs a .thrift interface
file or a combined .thrift that covers both ends. For local IPC it works
well and is the most flexible approach IMHO. This approach may be difficult
if the processes are on different machines. For example, each end would
need to punch through the firewall; 2-way NAT traversal would be complex.

Another option for a single-ended server, and an alternative to polling,
would be for the server to pend or block a notification RPC until something
interesting happens. For instance, one thread might call
client->ImmediateWork(), while a second thread calls client->NotifyMe().
ImmediateWork() is a regular RPC that the server processes and returns
immediately. OTOH the server does not complete NotifyMe(), at least not
until an event has occurred, after which the client can inspect the return
value and decide what to do next.

This was all done in C++ and I can't speak to whether Ruby support has
other limitations.

 ------------------------------
*From:* Bryan Duxbury <br...@rapleaf.com>
*To:* user@thrift.apache.org
*Sent:* Thursday, January 12, 2012 11:31 AM
*Subject:* Re: does thrift support async client for ruby?


In rereading your original post, I think that I misread it initially. I
think you're asking for server->client notifications, which we also don't
support. If you don't want the client to wait, the simplest thing you can
do is to have two methods - one to make a request that returns nothing, and
another that gets the result if there is one. Then the client can poll on
whatever appropriate interval.

If you REALLY need notification based updates instead of polling, then the
best thing to do would be to actually have your clients run a Thrift server
as well and make the server know how to contact them with completion
messages. This is complicated, and you're unfortunately on your own.

On Wed, Jan 11, 2012 at 3:17 PM, T Vinod Gupta <tv...@readypulse.com>wrote:

> thanks Bryan.
> Can you elaborate little more on what you meant by using threads to
achieve
> this? did you mean spawning multiple threads in ruby to get the data and
> coalescing them somehow?
>
> thanks
>
> On Wed, Jan 11, 2012 at 3:05 PM, Bryan Duxbury <br...@rapleaf.com> wrote:
>
> > I don't think we've implemented an async client in ruby thrift.
> >
> > The usual pattern is to use threads to achieve this sort of async
behavior.
> >
> > On Thu, Jan 5, 2012 at 6:18 PM, T Vinod Gupta <tv...@readypulse.com>
> > wrote:
> >
> > > does anyone know if thrift (0.6.0 or 0.8.0) support
async/non-blocking ruby
> > > client? if yes, how does the client get the return results?
> > >
> > > in my setup, the client calls the service with a request that can
take some
> > > time for the server to respond to. so how can this be made
non-blocking
> > > wherein the client is gets notified with the results when the call
really
> > > returns?
> > >
> > > thanks
> > >
> >
>

---------- Forwarded message ----------
From: Bryan Duxbury <br...@rapleaf.com>
Date: Wed, Jan 11, 2012 at 3:06 PM
Subject: Re: how can thrift server know that client has timed out?
To: user@thrift.apache.org


The server doesn't really know what's going on from the client perspective,
and even if we could detect a failed client, not all application-level
thrift server implementations could actually be interrupted sanely. If you
really want to achieve this kind of behavior you're going to end up writing
a lot of crazy synchronization code, I think.

On Thu, Jan 5, 2012 at 6:20 PM, T Vinod Gupta <tv...@readypulse.com> wrote:

> hi,
> for a long running request, thrift client can timeout and abort the api
> call to the server. in that case, it doesnt make sense for the server to
> keep working since the client is gone.
>
> are there any best practices/suggestions to deal with this kind of
> scenarios?
>
> thanks
> vinod
>


On Tue, Mar 6, 2012 at 2:55 PM, James Paton <jp...@gmail.com> wrote:

> Could you be a little more specific or perhaps point me to the message you
> saw?
>
> One possiblity that occured to me was to just kill the thread in which the
> RPC was occuring. What would be the effect of this?
>
> -- Jim
>
> On Mar 6, 2012, at 2:44 PM, T Vinod Gupta wrote:
>
> > i asked similar question quite some time back and the answer was not
> > simple.. you can use bidirectional communication to achieve this but the
> > overhead is upon you to handle.
> >
> > thanks
> >
> > On Tue, Mar 6, 2012 at 11:29 AM, James Paton <jp...@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> I was wondering how one would go about canceling an ongoing request to a
> >> Thrift client from another thread? That is, suppose thread A makes a
> >> request and thread B waits for thread A to signal. Then some event E
> >> happens and thread B decides to give up on thread A. How does thread B
> >> cancel the request? Or is there a better way to do this? Keep in mind
> that
> >> the event E is not simply the elapsing of a timer.
> >>
> >> -- Jim
>
>

Re: Cancel outstanding request on Thrift client (0.8.0)

[James Paton <jp...@gmail.com>]

Could you be a little more specific or perhaps point me to the message you saw?

One possiblity that occured to me was to just kill the thread in which the RPC was occuring. What would be the effect of this?

-- Jim

On Mar 6, 2012, at 2:44 PM, T Vinod Gupta wrote:

> i asked similar question quite some time back and the answer was not
> simple.. you can use bidirectional communication to achieve this but the
> overhead is upon you to handle.
> 
> thanks
> 
> On Tue, Mar 6, 2012 at 11:29 AM, James Paton <jp...@gmail.com> wrote:
> 
>> Hi,
>> 
>> I was wondering how one would go about canceling an ongoing request to a
>> Thrift client from another thread? That is, suppose thread A makes a
>> request and thread B waits for thread A to signal. Then some event E
>> happens and thread B decides to give up on thread A. How does thread B
>> cancel the request? Or is there a better way to do this? Keep in mind that
>> the event E is not simply the elapsing of a timer.
>> 
>> -- Jim

Re: Cancel outstanding request on Thrift client (0.8.0)

[T Vinod Gupta <tv...@readypulse.com>]

i asked similar question quite some time back and the answer was not
simple.. you can use bidirectional communication to achieve this but the
overhead is upon you to handle.

thanks

On Tue, Mar 6, 2012 at 11:29 AM, James Paton <jp...@gmail.com> wrote:

> Hi,
>
> I was wondering how one would go about canceling an ongoing request to a
> Thrift client from another thread? That is, suppose thread A makes a
> request and thread B waits for thread A to signal. Then some event E
> happens and thread B decides to give up on thread A. How does thread B
> cancel the request? Or is there a better way to do this? Keep in mind that
> the event E is not simply the elapsing of a timer.
>
> -- Jim