[
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 6:33 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.
{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);
}
{code}
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:
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.
> 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)
