[jira] [Comment Edited] (THRIFT-2287) Allow services as parameters

["Wayne Rasmuss (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13865486#comment-13865486 ] 

Wayne Rasmuss edited comment on THRIFT-2287 at 1/8/14 4:00 PM:
---------------------------------------------------------------

Use Case:
Sometimes tasks take a long time. For example doing a mirror of a directory that is gigabytes in size. Waiting until the process is complete to get results is not very friendly. Consider the following thrift code:

NOTE: Jira is displaying this without all the newlines. Apologies. Any hints on how to show them would be great. A Google search was unhelpful.

struct FileAction {
     string path;
     string action;
}

service MirrorService {
     //Returns a list of files and the actions taken on them when the mirror is complete
     list<FileAction> mirror(string source, string destination);
}

If the mirror command runs for a long time, there is no progress returned until it is complete. With a service parameter, it would look like this.

struct FileAction {
     string path;
     string action;
}

service MirrorLog {
     void log(FileAction action);
}

service MirrorService {
     //Returns the total number of bytes copied
     i64 mirror(string source, string destination, MirrorLog log);
}

The service stub for mirror would then be provided with a TClient for a MirrorLog and the client stub would take a TService implementation of it. As the mirror operation happened, the mirror implementation would call the log method of the MirrorLog service with the each file action. We are currently handling this situation using long polling and breaking the method into two methods. For example:

service MirrorService {
     //Returns the mirror job id
     string startMirror(string source, string destination);
     list<FileAction> getMirrorProgress(string jobId);
}

getMirrorProgress returns whatever actions have happened since the last time it was called, waiting until there is at least one action to return. This works okay, but adds some complex work for the implementation and doubles the number of methods in the service. 



was (Author: wayne.rasmuss):
Use Case:
Sometimes tasks take a long time. For example doing a mirror of a directory that is gigabytes in size. Waiting until the process is complete to get results is not very friendly. Consider the following thrift code:

struct FileAction {
     string path;
     string action;
}

service MirrorService {
     //Returns a list of files and the actions taken on them when the mirror is complete
     list<FileAction> mirror(string source, string destination);
}

If the mirror command runs for a long time, there is no progress returned until it is complete. With a service parameter, it would look like this.

struct FileAction {
     string path;
     string action;
}

service MirrorLog {
     void log(FileAction action);
}

service MirrorService {
     //Returns the total number of bytes copied
     i64 mirror(string source, string destination, MirrorLog log);
}

The service stub for mirror would then be provided with a TClient for a MirrorLog and the client stub would take a TService implementation of it. As the mirror operation happened, the mirror implementation would call the log method of the MirrorLog service with the each file action. We are currently handling this situation using long polling and breaking the method into two methods. For example:

service MirrorService {
     //Returns the mirror job id
     string startMirror(string source, string destination);
     list<FileAction> getMirrorProgress(string jobId);
}

getMirrorProgress returns whatever actions have happened since the last time it was called, waiting until there is at least one action to return. This works okay, but adds some complex work for the implementation and doubles the number of methods in the service. 


> Allow services as parameters
> ----------------------------
>
>                 Key: THRIFT-2287
>                 URL: https://issues.apache.org/jira/browse/THRIFT-2287
>             Project: Thrift
>          Issue Type: Brainstorming
>            Reporter: Wayne Rasmuss
>            Priority: Minor
>
> What about allowing services as parameters to thrift methods? This would be useful for returning interim results, logging and probably other use cases.
> At first I thought, nah that can't work, but I thought about it more and it seems maybe it could. Though I know little of Thrift's internals.
> When the service parameter was serialized only its connection information would be sent. Additional data may need to be provided to the service (true host name etc.) That would be fine with me.
> It seems like both sides should have most of the features they need for this. It would probably be a requirement that the service was started, bound etc before being passed a a parameter.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)