We experienced a desync between the gateway and the database after a network issue on the gateway side.
The gateways are not on the same network as the database and we are using gravitee-repository-gateway-bridge-http-server and gravitee-repository-gateway-bridge-http-client plugins.
Expected Behavior
When there's a network issue, gateway keep its latest configuration and continue to serve requests to the latest state it knows.
When the network link comes back, it refresh its configuration.
Current Behavior
During the network downtime, the gateway properly served API that were deployed before the network issue (GOOD)
When the network link came back, it nevers synced with the database and did not serve new API, that were deployed during/after the network issue (KO)
We have 2 gateway in that scenario and only one gateway had a sync issue.
After restarting the desynced gateway, everything came back to normal.
Steps to Reproduce (for bugs)
I don't have the steps. There have been multiple occurence of network slowness/link issue and most of the time, the gateways managed to resync without problem.
During the same period, out of 2 gateways (with exactly the same config), only one did have this issue.
Context
We are currently implementing the following architecture:
Central network : Postgres + REST API + Elastic + Portal UI + Mgt UI + Gateway http bridge server
Local network : Load balancer + 2 gateways (with http-bridge-client)
Local network should be able to live without link/access to central network for extended period of time.
Your Environment
export GRAVITEE_VERSION=3.0.7
export GRAVITEE_REPOSITORY_JDBC_VERSION=3.0.4
export GRAVITEE_REPOSITORY_GATEWAY_BRIDGE_VERSION=3.0.3
docker images for the gateway
We experienced a desync between the gateway and the database after a network issue on the gateway side. The gateways are not on the same network as the database and we are using
gravitee-repository-gateway-bridge-http-server
andgravitee-repository-gateway-bridge-http-client
plugins.Expected Behavior
When there's a network issue, gateway keep its latest configuration and continue to serve requests to the latest state it knows. When the network link comes back, it refresh its configuration.
Current Behavior
During the network downtime, the gateway properly served API that were deployed before the network issue (GOOD) When the network link came back, it nevers synced with the database and did not serve new API, that were deployed during/after the network issue (KO) We have 2 gateway in that scenario and only one gateway had a sync issue.
After restarting the desynced gateway, everything came back to normal.
Steps to Reproduce (for bugs)
I don't have the steps. There have been multiple occurence of network slowness/link issue and most of the time, the gateways managed to resync without problem. During the same period, out of 2 gateways (with exactly the same config), only one did have this issue.
Context
We are currently implementing the following architecture: Central network : Postgres + REST API + Elastic + Portal UI + Mgt UI + Gateway http bridge server
Local network : Load balancer + 2 gateways (with http-bridge-client) Local network should be able to live without link/access to central network for extended period of time.
Your Environment
export GRAVITEE_VERSION=3.0.7 export GRAVITEE_REPOSITORY_JDBC_VERSION=3.0.4 export GRAVITEE_REPOSITORY_GATEWAY_BRIDGE_VERSION=3.0.3 docker images for the gateway