thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jens Geyer" <>
Subject Re: Long running task => step by step response
Date Sat, 03 Jan 2015 18:46:21 GMT

I know that polling is evil, but polling seems to me like The Simplest Thing 
That Could Possibly Work™ here. This is what comes to my mind:

enum status {

struct actionresult {
  1 : status  status
  2:  i32 actionID

service Foobar {

    // this call starts the action
    // it returns a actionresult struct indicating the initial status and/or 
an actionID
    actionresult StartSomeTimeConsumingAction( 1: myargs args) throws (1 : 
wtf_error wtf)

    // query status and result of a previously started action
    actionresult  QueryActionStatus( 1: i32 actionID) throws (1: 
invalid_id_error iex)

Have fun,

-----Ursprüngliche Nachricht----- 
From: Wilm Schumacher
Sent: Saturday, January 3, 2015 2:52 PM
Subject: Long running task => step by step response


I have a standard set-up like that:
Node1: applicationserver + thriftserver
Node2: webserver + thriftclient

Now I have a long running task (about 2-3) minutes and I want to let the
user know which "step" is completed, as the task can be divided in
reasonable subtasks. But for that the server have to let the client know
about the completed subtasks.

I thought of 2 ways to realize that:

1.) divide the task into the specific subtasks and do 3-4 calls like
"doSubTask1", "doSubTask2" and so on. But for that I would somehow be
able to track the specific tasks (which of course depends on input data).

Something like
string submitTasks(<data>)"
which gives back the id
and then
"doSubTaks1( string id )"

But for that I need to implement an infrastructure to track a task which
would be a lot of work (delete tasks on "timeout" and some things like
that etc. pp.)

2.) making thrift "bidirectional"  by creating special thrift servers on
the client to, and notifiy it for progress. This on the other hand would
need all the infrastructure to make such a bidirectional connection
possible. As there a multiple clients, which can die and reconnect etc.,
I would need a lot of code to create such an possibility.

However, in this way it would be easier to track a long running task, as
it would be
"string doTasks(<data>)"
which gives the ID

and the wait for calls on the "special client server" for events like
"void doneSubTaks1( string id )"

By now I tend to poassibility 2, as it would give me more flexibilty in
the future (infrastructure has to be build only once). Am I wrong? Is
that a bad plan? Do I miss something? Is there a better plan?

Best wishes


View raw message