search

payara / Payara

Payara Server is an open source middleware platform that supports reliable and secure deployments of Java EE (Jakarta EE) and MicroProfile applications in any environment: on premise, in the cloud or hybrid.
http://www.payara.fish
Other
880 stars 302 forks source link

flush JDBC Connection Pool fails /CUSTCOM-66 #1873

Closed bakkc closed 3 years ago

bakkc commented 7 years ago

Description

When using the Flush button to reset jdbc connections error raises in the UI

Expected Outcome

jdbc connections should re-initialize on the targets

Current Outcome

An error has occurred Flush Connection Pool failed for xxxx_jdbc_pool. Flush Connection Pool did not happen as pool - xxxx_jdbc_pool is not initialized. Please check the server.log for more details.

Steps to reproduce (Only for bug reports)

Press Flush button.

Login UI payara--> JDBC -->JDBC Connection Pools --> xxxx_jdbc_pool--> Flush button

Environment

smillidge commented 7 years ago

This is expected behaviour. The connection pool isn't initialised until it is first used. If an application has requested a connection from the pool then Flush Pool works as expected.

lprimak commented 7 years ago

From the users perspective it shouldn't give an error but rather be a no-op. I found this very confusing

bakkc commented 7 years ago

i'd expect that de connections to the oracle database would be dropped and that re-initialized. Or is this only for active sessions that are using the pool?

ggam commented 7 years ago

+1 with an info message saying that it was no-op.

As a side note, I've faced some case where the database was unavailable at deployment time (e.g. stopped database), but then after starting the database process, the application keeps seeing the uninitialized pool. There's no way to fix it but redeploying/restarting the server.

@bakkc is this also your situation? In that case the solution might be to make the flush initialize the pool in case it was already requested but failed?

Btw, WildFly initializes the pool even if the database can't be reached. That way it automatically works when the database problems are solved. I see that as a more relisient solution. Just in case the idea adds some value.

El lun., 21 de agosto de 2017 1:33, lprimak notifications@github.com escribió:

From the users perspective it shouldn't give an error but rather be a no-op. I found this very confusing

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/payara/Payara/issues/1873#issuecomment-323619044, or mute the thread https://github.com/notifications/unsubscribe-auth/ACAucNvsC0I5twxqFSqhscuu8DlCacRWks5saMJQgaJpZM4O55EM .

bakkc commented 7 years ago

In our case the database is still up. We are implementing oracle editions (versioning) in our database , and have de possibility to set new connections from one version to the other. But this is only for new connections, and the database keeps old sessions open. We can manage this by reducing the idle timeout of the oracle session, so they will be dropped after $timeout. I was hoping that the flush button would do the same.

rdebusscher commented 4 years ago

This issue is tracked internally as CUSTCOM-66.

AlanRoth commented 3 years ago

Hi, due to how long ago this issue was raised we have decided to close the issue immediately, and not consider the implementation of the fix/improvement that was requested. Please understand that this decision was taken into consideration with the resources that we have available at the moment. In case of having reported a bug, if the issue is still pressing to you, feel free to verify if it’s applicable in the current release of Payara Community edition, and proceed to raise a new issue with details of the test reproducer. Many thanks for your understanding.

roberto-cisternino commented 1 year ago

This issue is still present even with pools in productions... database is pinging, queries are working, but flush from admin console raises the same error.