# Reconnection does not retry to remote Virtual Graph **URL:** \ **Category:** Support\ **Created:** [January 20, 2022, 12:00am UTC](https://community.stardog.com/t/reconnection-does-not-retry-to-remote-virtual-graph/3459 "2022-01-20T00:00:15Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![johnz](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/johnz/32/749_2.png) [@johnz](https://community.stardog.com/u/johnz)\ **Post date:** [January 20, 2022, 12:00am UTC](https://community.stardog.com/t/reconnection-does-not-retry-to-remote-virtual-graph/3459/1 "2022-01-20T00:00:15Z")
I have a virtual graph to a hive db that is over a haproxy to site 3000 miles away, i.e. high delay, but the internet session has high throughput and low drop rate. The StarDog "connections" are extremely flaky. The connection fails the first time access to the virtual graph with the generic error: Caused by: java.lang.RuntimeException: java.sql.SQLException: Could not establish connection to jdbc:hive2://localhost:10003/default;auth=noSasl: null But if I retry the query several times it finally works. This looks like a connection pool configuration problem. Any recommendations? Is there a way to force a retry from Stardog Studio? Bad connection management seems to be a common problem. I tried the hints from: > [@Can Virtual Graph auto retry after connection reset](https://community.stardog.com/t/can-virtual-graph-auto-retry-after-connection-reset/2630): > > The Virtual Graph connection to my Hive cluster stalls, when left idle for a while. When I query the Virtual Graph, it fails with a broken pipe exception. My workaround is to restart the StarDog Server. Is there a way to start a Virtual Graph Connection without a restart? What I want is for Virtual Graphs to "assure the connection" before using it. Assure could involve tcp ping to the service port and/or sending an application-level status query. If that test fails, the Virtual Graph reest… > [@Dropped connection from Postgres DB requires Stardog Server restart](https://community.stardog.com/t/dropped-connection-from-postgres-db-requires-stardog-server-restart/2483/4): > > To close this out .... We resolved this by setting Postgres' testOnBorrow and testWhileIdle TRUE, and setting timeBetweenEvictionRunsMillis to 2000. Andrea > [@Server stops querying downstream databases (Docker Stardog to Azure MySQL DB)](https://community.stardog.com/t/server-stops-querying-downstream-databases-docker-stardog-to-azure-mysql-db/3188): > > Hi, I am using the latest version of Stardog in a docker container. After it is spun up I am adding an Azure SQL (MySQL) database and mapping it in based on the vkg tutorial however Stardog seems to drop the connection and not reconnect. When executing a SPARQL query like below: SELECT ?member ?name { GRAPH \ { ?band a :Band ; :name "The Beatles" . ?member :member ?band ; :name ?name . } } This query will work a bunch of times and the… > **[Data Source Configuration](https://docs.stardog.com/virtual-graphs/data-sources/data-source-configuration#tomcat-connection-pool-options)** > > This page covers the configuration options for the various types of Data Sources. [https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool.html#Common\_Attributes](https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool.html#Common_Attributes) ---
**Author:** ![PaulJackson](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/pauljackson/32/243_2.png) [@PaulJackson](https://community.stardog.com/u/PaulJackson)\ **Post date:** [January 31, 2022, 10:54pm UTC](https://community.stardog.com/t/reconnection-does-not-retry-to-remote-virtual-graph/3459/2 "2022-01-31T22:54:59Z")
Hi John, Did you get this resolved? Stardog pools its virtual db connections. It's possible they are timing out or in some other way becoming corrupted. You can set datasource connection properties to tune the pool parameters. See: [Data Source Configuration | Stardog Documentation Latest](https://docs.stardog.com/virtual-graphs/data-sources/data-source-configuration#tomcat-connection-pool-options) Some options: ```auto # discard any connection older than 10 minutes: maxAge=600000 # test connections before use using driver-specific validation test testOnBorrow=true # test connections before use using user-provided validation query testOnBorrow=true validationQuery=SELECT 1 ``` Note, these are datasource options, not virtual graph options. -Paul ---
**Author:** ![johnz](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/johnz/32/749_2.png) [@johnz](https://community.stardog.com/u/johnz)\ **Post date:** [February 1, 2022, 1:29am UTC](https://community.stardog.com/t/reconnection-does-not-retry-to-remote-virtual-graph/3459/3 "2022-02-01T01:29:33Z")
The hive connection worked a few times, which is better than before. Your solution looks like: let the old connection timeout and test it before sending the actual query. This should work for our infrequent query use case. Is there a way in the Stardog Studio. Data Source page to force test of the connection? ---
**Author:** ![PaulJackson](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/pauljackson/32/243_2.png) [@PaulJackson](https://community.stardog.com/u/PaulJackson)\ **Post date:** [February 1, 2022, 12:53pm UTC](https://community.stardog.com/t/reconnection-does-not-retry-to-remote-virtual-graph/3459/4 "2022-02-01T12:53:10Z")
It can work for frequent use cases as well as there's a timer in the pool management that skips the test if the connection was used very recently. There are dozens of tunable parameters to choose from to suit an array of use cases including no pooling of connections. There isn't a Test button but that sounds like a good idea. I'll create a ticket for the feature. -Paul ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex030/uploads/stardog/original/2X/e/ed66b48a616f505106a4acde3c9cee7e6da9bc67.svg) [@system](https://community.stardog.com/u/system)\ **Post date:** [February 15, 2022, 12:53pm UTC](https://community.stardog.com/t/reconnection-does-not-retry-to-remote-virtual-graph/3459/5 "2022-02-15T12:53:58Z")
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.