Increase throughput for Grizzly and undertow by parallelizing DB access#1439
Increase throughput for Grizzly and undertow by parallelizing DB access#1439LadyMozzarella merged 7 commits intoTechEmpower:masterfrom denkab:master
Conversation
denkab
commented
Mar 24, 2015
- Original configuration of connection for Hibernate in Grizzly-Jersey was highly inadequate. Bumped connection count to match claimed parallelism of test framework (256).
- Parallelized DB operations for Grizzly-Jersey and undertow
…y with resource" fashion
|
Can not reproduce Mongo failure in my set up where I run it in a VirtualBox VM with 4 GB allocated. If I run the service by "./setup.sh" and then hit it with request, it returns just fine. If I run full blown test, the test terminates and the terminal session is "Connection to 127.0.0.1 closed by remote host." Not my fault? :o) |
There was a problem hiding this comment.
It appears that this method (IdentifierLoadAccess.load) could potentially be returning the data from a cache based off of this description from the Hibernate JavaDoc:
If the instance is already associated with the session, return that instance, initializing it if needed.
This sounds like it could be a cache. If this is the case, we would need to ensure that it makes direct database access. Do you mind providing some clarification?
|
For query cache to work it needs to be enabled. Whomever first introduced this framework upheld the benchmark contract by supplying Hibernate configuration: |
Increase throughput for Grizzly and undertow by parallelizing DB access
