Sequence of exceptions following database connection issue #2310
Comments
|
try without as that setting effectively removes pooling and just creates a connection per request thread. |
|
Hi Steve,
What does this do in terms of the benefits / overhead reduction of pooling?
I am willing to try this setting but like I said, it's hard to make this
happen on demand, so it's hard to test the impact.
Thanks,
Marc
…On Thu, Feb 15, 2018 at 4:32 PM Steve Millidge ***@***.***> wrote:
try without
associate-with-thread="true"
as that setting effectively removes pooling and just creates a connection
per request thread.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2310 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AXUzZgnQw2bPudZlM40IzCZ3S7MrHgqVks5tVLBrgaJpZM4RoSJ6>
.
|
|
@smillidge I apologize for the ping, but can you answer my last question? Thanks, |
|
The connection will be associated with a specific thread and will remain with that thread. It will only be removed from the thread if the thread is idle and another thread requires a connection. It can reduce the overhead of pooling but requires careful tuning of connection pool size to request threadpool size so if web requests the http thread pool. Ideally both would be equal size. The old docs have more information https://docs.oracle.com/cd/E19798-01/821-1752/giydr/index.html |
|
Closing due to inactivity |
|
Hi @smillidge I apologize but I wasn't aware there was a request for more information. We have put in changes to use more of the default connection pool settings, not knowing from history why some were changed from defaults. If this issue persists with the changed settings, I'll re-open the ticket. Thanks! Marc |
Description
We are seeing a situation (possibly an Eclipselink bug?), in which if a JDBC connection pool connection runs into an issue, various uses of JDBC in the future will run into assorted exceptions (PoolingException, NullPointerException, etc.) until the domain is restarted.
Expected Outcome
It's expected that after a transient connection issue, that connection will be marked bad and recycled next time. If that already IS happening, then a bug may just need to be fixed in the area which deals with validation and recycling connections.
Current Outcome
First exception from initial transient connection loss:
Next set of exceptions (several hours in the future):
Steps to reproduce (Only for bug reports)
I haven't found a clear set of ways to reproduce this, I'm hoping the traces provide some ability to dig into the code and see if any logic issues persist.
If this cannot proceed without real steps, I can try to conjure some up but this is an existing stable application otherwise, and nothing new has been introduced to change this aside from the Payara updates.
Context (Optional)
This is an existing enterprise application which was ported from GF 3.1.2 to Payara 4.1.1.171.1, and then most recently to 4.1.2.174. It runs for weeks/months at a time, and there is generally no issue, but if this kind of transient connection issue happens, it's hard to pull out of it without a restart.
I've seen other bugs on related issues (e.g. #769) , but it doesn't seem like they've fixed this problem all the way.
Environment
Using pool settings:
Happy to try settings changes (like turning off statement cache, or using max connection usage, but it's hard to prove this out as it happens infrequently.
The text was updated successfully, but these errors were encountered: