Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upIncrease throughput for Grizzly and undertow by parallelizing DB access #1439
Conversation
denkab
added some commits
Mar 22, 2015
LadyMozzarella
added this to the Round 11 milestone
Mar 24, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
denkab
Mar 26, 2015
Contributor
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)
|
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) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
LadyMozzarella
Mar 26, 2015
Member
All of the mongodb tests tend to fail in Travis-CI. I ran your branch on the tests you changed through vagrant and it all looks good to me.
|
All of the mongodb tests tend to fail in Travis-CI. I ran your branch on the tests you changed through vagrant and it all looks good to me.
|
LadyMozzarella
added
the
Enhance: Framework
label
Apr 1, 2015
LadyMozzarella
reviewed
Apr 2, 2015
| new Callable<World>() { | ||
| @Override | ||
| public World call() throws Exception { | ||
| return (World) accessor.load(random.nextInt(DB_ROWS) + 1); |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
LadyMozzarella
Apr 2, 2015
Member
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?
LadyMozzarella
Apr 2, 2015
Member
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?
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
denkab
Apr 3, 2015
Contributor
For query cache to work it needs to be enabled. Whomever first introduced this framework upheld the benchmark contract by supplying Hibernate configuration:
<property name="hibernate.cache.use_query_cache">false</property>
|
For query cache to work it needs to be enabled. Whomever first introduced this framework upheld the benchmark contract by supplying Hibernate configuration: |
denkab commentedMar 24, 2015