I'll try to get a thread dump over the weekend. I ended up switching to hibernate which works flawlessly... so it's definitely something particular to JDBI.
In the meantime, I know it's not client ports and my test case only has 3 SKU's. The MySql and Oracle connection pools were configured with 8 initial connections, 8 minimum and 64 maximum. The datasource supports 1000's and I was the only person hitting the server at the time. I don't have a copy of the /threads output handy, but I do seem to recall something about a reentrant lock being in the stack and I'm reasonably sure it was hung up somewhere in the driver. Just to be clear, the exact same code works fine as long as I'm using hibernate connections -- I use the session manager for the Oracle datasource to open a new temporary connection on the background task thread before I execute the Oracle query. Otherwise, the JDBI code was identical. On Thursday, October 26, 2017 at 6:02:07 PM UTC-4, Artem Prigoda wrote: > > Hi Brenda! > > Could you post a thread dump when your MySQL query hangs? You can get it > with kill -3 ''<pid>' or via the Dropwizard admin task 'threads'. > > If your Oracle and MySQL clients don't share any resources like a > connection pool, my wild guess would be that you machine runs out of TCP > client ports when you make the MySQL query. > If you have a really big amount of SKU numbers and the Oracle client > doesn't pool connections, it will quickly eat up all open possible ports > and the OS wouldn't be able to allocate a new port for a MySQL connection. > Your executor seems to be fine: it's a fixed executor with 100 threads and > unbounded waiting queue, so unless you memory-limited it should not affect > other executors. > > Artem > -- You received this message because you are subscribed to the Google Groups "dropwizard-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
