Re: [DISCUSS] Automated Tx Retry for Gremlin Server
Looks like we already have an open issue on this topic: https://issues.apache.org/jira/browse/TINKERPOP-1005 So - good - not closing one issue to just open another :) On Mon, Sep 19, 2016 at 9:25 AM, Stephen Mallette wrote: > Ah - yes - the "locking" issue as specific to Titan. More generally, I am > sure there are other graphs that have retry-able errors that would get > consumed by Gremlin Server. I wonder how that would work though. There > would need to be a way for the Graph to tell Gremlin Server what kind of > error code/status to ship back. Graph implementations currently don't know > anything about Gremlin Server - I wonder where we would introduce something > like that. > > > > On Mon, Sep 19, 2016 at 9:17 AM, Dylan Millikin > wrote: > >> Yeah. This should be a client side feature. >> >> I think discussing scenarios where retry is useful to clients and bubbling >> up proper errors would be the correct solution to this problem. A good >> example would be locks, currently clients have no clean way of detecting >> locks and retrying appropriately. >> >> On Mon, Sep 19, 2016 at 1:25 PM, Stephen Mallette >> wrote: >> >> > A long while back I created this issue to support a way for Gremlin >> Server >> > to retry failed transactions automatically. Aside from the difficulties >> > discussed with Dylan in the issue itself, I'm realizing now that the >> > complexity is more that Gremlin Server should probably bear. >> > >> > Barring objection I will assume lazy consensus after 72 hours (Thursday, >> > September 22, 2016, 7am EST) and simply close this one: >> > >> > https://issues.apache.org/jira/browse/TINKERPOP-739 >> > >> > >
Re: [DISCUSS] Automated Tx Retry for Gremlin Server
Ah - yes - the "locking" issue as specific to Titan. More generally, I am sure there are other graphs that have retry-able errors that would get consumed by Gremlin Server. I wonder how that would work though. There would need to be a way for the Graph to tell Gremlin Server what kind of error code/status to ship back. Graph implementations currently don't know anything about Gremlin Server - I wonder where we would introduce something like that. On Mon, Sep 19, 2016 at 9:17 AM, Dylan Millikin wrote: > Yeah. This should be a client side feature. > > I think discussing scenarios where retry is useful to clients and bubbling > up proper errors would be the correct solution to this problem. A good > example would be locks, currently clients have no clean way of detecting > locks and retrying appropriately. > > On Mon, Sep 19, 2016 at 1:25 PM, Stephen Mallette > wrote: > > > A long while back I created this issue to support a way for Gremlin > Server > > to retry failed transactions automatically. Aside from the difficulties > > discussed with Dylan in the issue itself, I'm realizing now that the > > complexity is more that Gremlin Server should probably bear. > > > > Barring objection I will assume lazy consensus after 72 hours (Thursday, > > September 22, 2016, 7am EST) and simply close this one: > > > > https://issues.apache.org/jira/browse/TINKERPOP-739 > > >
Re: [DISCUSS] Automated Tx Retry for Gremlin Server
Yeah. This should be a client side feature. I think discussing scenarios where retry is useful to clients and bubbling up proper errors would be the correct solution to this problem. A good example would be locks, currently clients have no clean way of detecting locks and retrying appropriately. On Mon, Sep 19, 2016 at 1:25 PM, Stephen Mallette wrote: > A long while back I created this issue to support a way for Gremlin Server > to retry failed transactions automatically. Aside from the difficulties > discussed with Dylan in the issue itself, I'm realizing now that the > complexity is more that Gremlin Server should probably bear. > > Barring objection I will assume lazy consensus after 72 hours (Thursday, > September 22, 2016, 7am EST) and simply close this one: > > https://issues.apache.org/jira/browse/TINKERPOP-739 >
