True, but if you're doing OLAP jobs, it's not crazy to think that such a process could run for a day solid and running for a day solid is indistinguishable to the console from the server just never returning a response. I guess I'd prefer to see the console just working by default without getting an annoying timeout error because you busted your fat olap job and then lose connection to it because you forgot to bump the timeout.
On Wed, Apr 20, 2016 at 9:32 AM, Dylan Millikin < dylan.milli...@brightzone.com> wrote: > What about the event of a server failure? You could wait for a server > response indefinitely in that case. > > On Monday, 18 April 2016, Stephen Mallette <spmalle...@gmail.com> wrote: > > > yeah - it could be good - though based on a separate conversation, i > wonder > > if the console needs this timeout at all. Seems like you could just rely > on > > the server timeout - under what circumstance would you want to timeout > the > > console before the server was done processing? i guess I'd originally > put > > that timeout in there to ensure that the user didn't have to be blocked > > indefinitely awaiting an answer from the server. At that point all they > > could do was ctrl-c to hard exit the console. With the timeout, the > > console would just stop waiting for a response and return control to the > > user. Not sure if that's weird or not. > > > > On Mon, Apr 18, 2016 at 2:25 PM, Dylan Millikin < > dylan.milli...@gmail.com > > <javascript:;>> > > wrote: > > > > > I like this change. Makes sense. > > > > > > On Mon, Apr 18, 2016 at 2:04 PM, Stephen Mallette < > spmalle...@gmail.com > > <javascript:;>> > > > wrote: > > > > > > > I just created this issue about the console and "remote timeouts": > > > > > > > > https://issues.apache.org/jira/browse/TINKERPOP-1267 > > > > > > > > Basically, I'd like to add: > > > > > > > > :remote config timeout none > > > > > > > > as a replacement for > > > > > > > > :remote config timeout max > > > > > > > > "none" seems like a more fitting term than "max" for what a user > would > > > want > > > > to do. I think we can continue to support max for now but > "deprecate" > > it > > > > by only promoting use of "none". We can drop "max" at some point in > the > > > > future. > > > > > > > > > >