Looks like my earlier mail has bounced. Sending it again.
Can you please add some explanation to AURORA-471 explaining where the time
is being spent with some data and some micro benchmarks. As is it is
unclear why thrift.flush should be taking so long. Is the default
implementation of TServlet.do
>
> I feel that we should drop the extra information from the
> getTasksStatus first (if the client is unaffected by the change)
The client would indeed be affected by that (config diffing when performing
job updates). However, there's nothing stopping us from defining a new RPC
and message to d
The new API can be a flagged version of the getTasksStatus API also.
On Fri, May 30, 2014 at 11:27 AM, Bill Farner wrote:
> >
> > I feel that we should drop the extra information from the
> > getTasksStatus first (if the client is unaffected by the change)
>
>
> The client would indeed be affec
On Fri, May 30, 2014 at 11:22 AM, Suman Karumuri wrote:
> Looks like my earlier mail has bounced. Sending it again.
>
> Can you please add some explanation to AURORA-471 explaining where the time
> is being spent with some data and some micro benchmarks. As is it is
> unclear why thrift.flush sho
