Bug: Http query request failed #20
Comments
|
Just to clarify, are you saying that the utility isn't working after finding the nodes/edges and you are seeing those error messages, or are you saying that the utility does work but you are asking if you should be concerned about those error messages? |
|
The utility is not working; it starts logging the error and it never finishes running and never puts anything in the output/ folder. |
|
It just starts logging the error endlessly |
danielfinke
added a commit
to danielfinke/amazon-neptune-for-graphql
that referenced
this issue
Jan 23, 2025
Previously, for a graph with `n` nodes or edges, there would be `n` concurrent requests made to Neptune via `queryNeptune`. Depending on your instance class or VPC settings, you could hit errors such as `MemoryLimitExceededException` or connection limits/sockets abruptly closing, with increasing likelihood as the size of the graph increased. Initially observed abrupt socket closing just like aws#20. Now, the concurrent request Promises are resolved in batches using `mapAll`. For now, the batch size is hardcoded to 20. For very small instance classes (e.g. from the "Development and testing" template), `MemoryLimitExceededException`s are still likely. Further improvements could include: - relating the batch size to the instance class - allowing the user to specify the batch size in the process args - exponential/dynamic backoff on transient errors as indicated in https://docs.aws.amazon.com/neptune/latest/userguide/errors-engine-codes.html#errors-query
Cole-Greer
pushed a commit
that referenced
this issue
Jan 24, 2025
Previously, for a graph with `n` nodes or edges, there would be `n` concurrent requests made to Neptune via `queryNeptune`. Depending on your instance class or VPC settings, you could hit errors such as `MemoryLimitExceededException` or connection limits/sockets abruptly closing, with increasing likelihood as the size of the graph increased. Initially observed abrupt socket closing just like #20. Now, the concurrent request Promises are resolved in batches using `mapAll`. For now, the batch size is hardcoded to 20. For very small instance classes (e.g. from the "Development and testing" template), `MemoryLimitExceededException`s are still likely. Further improvements could include: - relating the batch size to the instance class - allowing the user to specify the batch size in the process args - exponential/dynamic backoff on transient errors as indicated in https://docs.aws.amazon.com/neptune/latest/userguide/errors-engine-codes.html#errors-query
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have encountered an issue; I run neptune-for-graphql and I see that after finding all my nodes and edges via the Neptune Summary API, and after discovering the properties of the edges and nodes, I see error messages like the following begin to flow:
Http query request failed: Client network socket disconnected before secure TLS connection was established Trying with the AWS SDKI am running the tool like so:
neptune-for-graphql --input-graphdb-schema-neptune-endpoint xxxx-xxx-xx.us-east-1.neptune.amazonaws.com:xxxx --output-aws-pipeline-cdk-neptune-IAMI am using Neptune engine 1.2.1.0, with sigV4 enabled. My cluster instance is of type 'provisioned', it's of size db.r5.4xlarge.
The text was updated successfully, but these errors were encountered: