[jira] [Commented] (S2GRAPH-36) Provide Blocking API for Edge/Vertex operations.

["DOYUNG YOON (JIRA)" <ji...@apache.org>]

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

DOYUNG YOON commented on S2GRAPH-36:
------------------------------------

I was working on this issue and found out something need to be fixed.

1. add withWait on incrementCounts.

current implementation on AsynchhbaseStorage use client with flushInterval for incrementCounts operation. I think it is better to use client without flushInterval to reduce response time on incrementCounts.

2. deleteAll on isAsync label is not processed properly.

when isAsync is set to be true, there should be no mutations on this label. we need to filter out labels that set to be isAsync for deleteAll request.

3. move processing logic for deleteAll from controller to s2core(mutateEdges).

also it is better to process deleteAll and other operations in seperate futures when there are contentions on request edges.

4. publish into kafka as single deleteAll request.

we are fetching and deleting related edges asynchronously, and current implementation publish delete requests for fetched edges to process deleteAll. This can be wrong since it is built from state when deleteAll request first arrive. 

Tell me what you guys think and I will issue PR that fix original issue and this follow-up issues altogether.

> Provide Blocking API for Edge/Vertex operations.
> ------------------------------------------------
>
>                 Key: S2GRAPH-36
>                 URL: https://issues.apache.org/jira/browse/S2GRAPH-36
>             Project: S2Graph
>          Issue Type: New Feature
>            Reporter: DOYUNG YOON
>            Assignee: DOYUNG YOON
>              Labels: feature
>
> There is no blocking API for edge/vertex operations such as Insert/Delete/Update/Increment/IncrementCount and bulk. 
> When client want to get ack of their operations, it is necessary to provide blocking APIs. currently there is "withWait" parameter to control this behavior and we are not actually providing rest API for this option. 
> I think we must provide blocking API so user can get ack for their operation so they can handle failure on their request.
> Since we have primitive built(we only use these in test cases so far), I think it would be easy to provide blocking API.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)