[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable
[ https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16581684#comment-16581684 ] ASF GitHub Bot commented on TINKERPOP-1906: --- Github user redoz commented on the issue: https://github.com/apache/tinkerpop/pull/915 Is it out of scope to add the attribute collection to the ResponseException as well? It's a very minor change (it requires only adding the property to the exception type, and changing one line of code where the exception is instantiated) and it would be quite useful when dealing with Cosmos DB. It might also close TINKERPOP-1906, or at least offer a decent work-around until it can be resolved properly. > Make ResponseException explorable > - > > Key: TINKERPOP-1906 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1906 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.2.7 >Reporter: Roman Kreisel >Priority: Major > Attachments: message.txt, stacktrace.txt > > > The ResponseException from Gremlin.NET doesn't give you any possibility to > react on the GremlinService's Response. The only content is the exception's > Message, which is just free text. > It would be great, to add some fields to expose at least the HTTP ErrorCode > or anything else that's responded by the service. > > Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a > "Request Rate to Large" response, in case you have high load on your > database. In such a case, you want to be able to detect this "error" and just > retry after a few milliseconds (i'm not sure, but i think even a proposal for > this retry-timeout is given in the response) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable
[ https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381065#comment-16381065 ] Roman Kreisel commented on TINKERPOP-1906: -- [~Florian Hockmann]: Thanks for solving the status code thing... I was so sure it just contains the numerical code, that I just didn't see it. I think i might've also brought some additional confusion into this discussion with the link posted above ([https://docs.microsoft.com/en-us/rest/api/documentdb/http-status-codes-for-documentdb]) - I guess this might be valid only for the Cosmos DB's RESTful interface, but not for the Gremlin/Tinkerpop API. > Make ResponseException explorable > - > > Key: TINKERPOP-1906 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1906 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.2.7 >Reporter: Roman Kreisel >Priority: Major > Attachments: message.txt, stacktrace.txt > > > The ResponseException from Gremlin.NET doesn't give you any possibility to > react on the GremlinService's Response. The only content is the exception's > Message, which is just free text. > It would be great, to add some fields to expose at least the HTTP ErrorCode > or anything else that's responded by the service. > > Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a > "Request Rate to Large" response, in case you have high load on your > database. In such a case, you want to be able to detect this "error" and just > retry after a few milliseconds (i'm not sure, but i think even a proposal for > this retry-timeout is given in the response) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable
[ https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381019#comment-16381019 ] Ashwini Singh commented on TINKERPOP-1906: -- In case of 429, Gremlin Response from Azure Cosmos DB contains ResponseStatusCode.ServerError(500) and exception details as the message, which includes details of 429 exceptions. At the Gremlin.Net driver side, you see the ResponseException because of the error code ResponseStatusCode.ServerError (500). Also, Cosmos DB adds more details in the ResponseStatus.Attributes. You can check that through tools like Fiddler. I agree with Florian, the change mentioned [here|mailto:%20https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E] is to expose these details and client can handle the rate limiting. > Make ResponseException explorable > - > > Key: TINKERPOP-1906 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1906 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.2.7 >Reporter: Roman Kreisel >Priority: Major > Attachments: message.txt, stacktrace.txt > > > The ResponseException from Gremlin.NET doesn't give you any possibility to > react on the GremlinService's Response. The only content is the exception's > Message, which is just free text. > It would be great, to add some fields to expose at least the HTTP ErrorCode > or anything else that's responded by the service. > > Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a > "Request Rate to Large" response, in case you have high load on your > database. In such a case, you want to be able to detect this "error" and just > retry after a few milliseconds (i'm not sure, but i think even a proposal for > this retry-timeout is given in the response) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable
[
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381018#comment-16381018
]
Florian Hockmann commented on TINKERPOP-1906:
-
Yeah, seeing the exception message I can completely understand your confusion.
The thing is that Gremlin.Net just builds the exception message as
{{$"\{status.Code}: \{status.Message}"}} where {{status.Code}} isn't an {{int}}
but a {{ResponseStatusCode enum}}. From your {{message.txt}}, the
{{status.code}} is {{ServerError}} and everything behind that (starting with
the {{ActivityId}}) is the {{status.Message}} returned by Cosmos DB.
This means for Gremlin.Net that all we're seeing here is the {{ServerError}}
(which corresponds to the status code 500) and the rest is just a {{string}}.
So all we could do with that information is to add dedicated exception class
like {{GremlinServerErrorException}} in cases where the server returns a
{{ServerError}} (500), but I don't know how useful that is as the
{{ServerError}} could be basically anything.
> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Priority: Major
> Attachments: message.txt, stacktrace.txt
>
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to
> react on the GremlinService's Response. The only content is the exception's
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode
> or anything else that's responded by the service.
>
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a
> "Request Rate to Large" response, in case you have high load on your
> database. In such a case, you want to be able to detect this "error" and just
> retry after a few milliseconds (i'm not sure, but i think even a proposal for
> this retry-timeout is given in the response)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable
[ https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380930#comment-16380930 ] Roman Kreisel commented on TINKERPOP-1906: -- Hi Florian, please find the exception's [^message.txt] and [^stacktrace.txt] attached to this comment. I just checked the sourcecode of [https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Driver/Messages/ResponseStatusCode.cs] and have to admit, i don't quite understand why this exception has been thrown, but my debugger clearly tells me, it's a Gremlin.Net.Driver.Exceptions.ResponseException. And even in the exception's Text, you can read "BackendStatusCode : 429" I'm using the 3.3.2-rc1 of Gremlin.NET from NuGet > Make ResponseException explorable > - > > Key: TINKERPOP-1906 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1906 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.2.7 >Reporter: Roman Kreisel >Priority: Major > Attachments: message.txt, stacktrace.txt > > > The ResponseException from Gremlin.NET doesn't give you any possibility to > react on the GremlinService's Response. The only content is the exception's > Message, which is just free text. > It would be great, to add some fields to expose at least the HTTP ErrorCode > or anything else that's responded by the service. > > Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a > "Request Rate to Large" response, in case you have high load on your > database. In such a case, you want to be able to detect this "error" and just > retry after a few milliseconds (i'm not sure, but i think even a proposal for > this retry-timeout is given in the response) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable
[
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380840#comment-16380840
]
Florian Hockmann commented on TINKERPOP-1906:
-
Hi Roman,
I was just hoping that you had a stack trace (or were able to produce one) as
that should contain the actual status code in its message. A status code of 429
would be problematic as that's not a status code we're expecting from a Gremlin
Server, but then you shouldn't get a {{ResponseException}} in the first place.
So it has to be another status code since you mentioned in the issue
description that the exception you are seeing is actually a
{{ResponseException}}.
> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Priority: Major
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to
> react on the GremlinService's Response. The only content is the exception's
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode
> or anything else that's responded by the service.
>
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a
> "Request Rate to Large" response, in case you have high load on your
> database. In such a case, you want to be able to detect this "error" and just
> retry after a few milliseconds (i'm not sure, but i think even a proposal for
> this retry-timeout is given in the response)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable
[ https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380820#comment-16380820 ] Roman Kreisel commented on TINKERPOP-1906: -- Hi Florian, i'm not a cosmos db architect, nor have I analyzed the http traffic. But regarding to the documentation from microsoft (*1), i'd expect a 429 (Too Many Requests) *1 https://docs.microsoft.com/en-us/rest/api/documentdb/http-status-codes-for-documentdb > Make ResponseException explorable > - > > Key: TINKERPOP-1906 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1906 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.2.7 >Reporter: Roman Kreisel >Priority: Major > > The ResponseException from Gremlin.NET doesn't give you any possibility to > react on the GremlinService's Response. The only content is the exception's > Message, which is just free text. > It would be great, to add some fields to expose at least the HTTP ErrorCode > or anything else that's responded by the service. > > Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a > "Request Rate to Large" response, in case you have high load on your > database. In such a case, you want to be able to detect this "error" and just > retry after a few milliseconds (i'm not sure, but i think even a proposal for > this retry-timeout is given in the response) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable
[
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380806#comment-16380806
]
Florian Hockmann commented on TINKERPOP-1906:
-
Adding the status code as its own property is definitely a good idea. We could
also introduce dedicated Exception classes for some status codes where a
different error handling makes sense. The {{ServerTimeout}} status might be for
example a good candidate as that's also something where a retry can make sense.
When we keep the {{ResponseException}} as the base class for new exception
classes, then this wouldn't be a breaking change.
[~RomanKreisel]: Could you check which status code you get returned in that
case? It should be the beginning of the {{Message}} of the thrown
{{ResponseException}}.
If you want to look at the implementation of where the exception gets thrown:
* This is where the exception is thrown:
[https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Driver/Messages/ResponseStatus.cs#L47]
* And this method shows the status codes that are treated as errors:
[https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Driver/Messages/ResponseStatusCode.cs#L45]
The status codes themselves are explained here, as they aren't directly the
HTTP status codes:
[http://tinkerpop.apache.org/docs/3.3.1/dev/provider/#_graph_driver_provider_requirements]
Regarding the discussion on the mailing list about adding meta data: It might
be possible that that's also what they had in mind with the meta data, but I
think that we can already improve error handling in the driver just based on
the status codes that we already have.
> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Priority: Major
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to
> react on the GremlinService's Response. The only content is the exception's
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode
> or anything else that's responded by the service.
>
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a
> "Request Rate to Large" response, in case you have high load on your
> database. In such a case, you want to be able to detect this "error" and just
> retry after a few milliseconds (i'm not sure, but i think even a proposal for
> this retry-timeout is given in the response)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable
[ https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380798#comment-16380798 ] Roman Kreisel commented on TINKERPOP-1906: -- Hi Stephen, thank you for your quick response - I wasn't aware there is already a discussion running. Anyway - the discussion even mentions ResponseStatus.Attributes - i think the absolute minimum would be to add the ResponseStatus to the ResponseException. Even right now, this would already help, since it would at least give the developers access to the HTTP Status. (Unless the "techical stuff" like HTTP code should be hidden/encapsulated) > Make ResponseException explorable > - > > Key: TINKERPOP-1906 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1906 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.2.7 >Reporter: Roman Kreisel >Priority: Major > > The ResponseException from Gremlin.NET doesn't give you any possibility to > react on the GremlinService's Response. The only content is the exception's > Message, which is just free text. > It would be great, to add some fields to expose at least the HTTP ErrorCode > or anything else that's responded by the service. > > Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a > "Request Rate to Large" response, in case you have high load on your > database. In such a case, you want to be able to detect this "error" and just > retry after a few milliseconds (i'm not sure, but i think even a proposal for > this retry-timeout is given in the response) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable
[ https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380760#comment-16380760 ] stephen mallette commented on TINKERPOP-1906: - I think this might relate to some of the discussion we're currently having on the dev list about this right now: https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E > Make ResponseException explorable > - > > Key: TINKERPOP-1906 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1906 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.2.7 >Reporter: Roman Kreisel >Priority: Major > > The ResponseException from Gremlin.NET doesn't give you any possibility to > react on the GremlinService's Response. The only content is the exception's > Message, which is just free text. > It would be great, to add some fields to expose at least the HTTP ErrorCode > or anything else that's responded by the service. > > Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a > "Request Rate to Large" response, in case you have high load on your > database. In such a case, you want to be able to detect this "error" and just > retry after a few milliseconds (i'm not sure, but i think even a proposal for > this retry-timeout is given in the response) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
