> Sometimes the edge exist and you can't add, and sometimes the edges doesn't exists and you can't deletete
I assume you mean the "sometimes the vertex exists and sometimes it doesn't" (not "edge"). You're assuming that your responses will process in order. Gremlin Server isn't going to guarantee that for you unless you use a session. Sessionless requests execute in the order they are received but requests that execute quickly will begin to stream results before those that take longer. So if you submit a request that takes 10 seconds to execute and you then fire off 10 requests after that that each only take 1 second, there's a good chance you're going to see some of those 10 requests return before that first request completes. It sounds like you just need to wait for the result of the submit() to complete before sending the next request. > However, I don't find your mechanism for change the log level I just meant that we set log level in this fashion apparently: https://github.com/apache/incubator-tinkerpop/blob/58b699e6b636eb40a6868725c85a245996798fbd/gremlin-console/src/main/bin/gremlin.sh#L54-L57 Seems like we should allow setting this "GREMLIN_LOG_CONF" in the same fashion. On Fri, Jul 31, 2015 at 9:17 AM, huneau romain <[email protected]> wrote: > My co-worker have see a strange behaviour. > > Write this code : > > while(true){ > > client.submit (g.addV(Tid, "vertex") ); > > client.submit ( g.V(T.id,"vertex").next().remove()); > > } > > Sometimes the edge exist and you can't add, and sometimes the edges > doesn't exists and you can't deletete > > However, I don't find your mechanism for change the log level. But, I > think to that : > > if["$2" #is set] > exec $JAVA -Dlog4j.configuration=$2 $JAVA_OPTIONS -cp $CP:$CLASSPATH > org.apache.tinkerpop.gremlin.server.GremlinServer "$@" > fi > > Very simple changes, it's enough for me. > > Romain. > ______________________________________________________________ > > ResultSet might not have been the best name perhaps as it implies the > "result" should be in hand. It's more of a ResultStream or ResultFuture - > maybe still not great names. In the case of submit() the ResultSet is > returned only after there is confirmation that the send of the request hits > the network stack. You then have the option to wait for all() or some() > results from there. I've been thinking about having two separate ResultSet > classes one for a synchronous return and one for asynchronous return, but > thought I'd wait for more user feedback before making changes. I'd say > that appropriate usage to wait for all results would be: > > client.submit("our request").all().get(); > > or > > client.submit("our request").all().join(); > > you might also consider this blocking iterator that will allow you to start > processing results as they arrive: > > Iterator itty = client.submit("our request").iterator() > while(itty.hasNext()) { > .... > } > > > Next, it's about log, we would like to have our own layer/pattern and > log4j conf are hard coded into the gremlin.sh. I think put the log4j conf > file into the line args maybe be a good solution, right ?. > > If you'd like to submit a pull request to alter gremlin.sh to allow for a > user specified log4j.configuration setting, I think that's fine. Looks > like we already have a mechanism for that when setting the log level. I > would think that you would simply follow that pattern. > > > On Fri, Jul 31, 2015 at 4:57 AM, huneau romain <[email protected]> > wrote: > > > Hello, > > > > I have some question, again. > > > > First, maybe is the correct behaviour, but it's weird. In the Driver / > > Client class, you have a submit method : > > /** > > * Submits a Gremlin script and bound parameters to the server and > > returns a {@link ResultSet} once the write of > > * the request is complete. ..... > > */ > > public ResultSet submit(final String gremlin, final Map<String, > Object> > > parameters) { > > try { > > return submitAsync(gremlin, parameters).get(); > > } catch (Exception ex) { > > throw new RuntimeException(ex); > > } > > } > > > > Here for avoid bug in our client we need to "re-wait" just after the > submit > > with : > > client.submit("our request").all().get(); //to be sure than the response > is > > complete > > or : > > while (!client.submit("our request").allItemsAvailable()); > > It's strange to do that in a synchronous method. > > > > Next, it's about log, we would like to have our own layer/pattern and > log4j > > conf are hard coded into the gremlin.sh. I think put the log4j conf file > > into the line args maybe be a good solution, right ?. (If we change the > > gremlin.sh we will have some difficult to merge with yours later). > > And Probably an other suggestion will let the User API to provide the > > LogManager, but more tricky. > > > > Romain. > > >
