[
https://issues.jboss.org/browse/ISPN-1818?page=com.atlassian.jira.plugin....
]
Mircea Markus commented on ISPN-1818:
-------------------------------------
I don't think that caching connections in thread locals is needed as the connection
object is fetched from the pull before the first write and returned to the pull on return
being passed through the calling stack explicitly. I do prefer explicit passing to thread
locals as the code is clear and faster.
I don't dislike the idea of having our own pool implementation either, just be aware
that we need to have pool management capabilities: e.g. connection shrinking on a per
server node basis, soft/hard threshold, validation (that would implies a thread running
ping over all the connections in the pool).
Also from a priority perspective, as this is just a redesign of a code that already works,
we should IMO move it to 6+.
Get rid of commons-pool for Hot Rod client
------------------------------------------
Key: ISPN-1818
URL:
https://issues.jboss.org/browse/ISPN-1818
Project: Infinispan
Issue Type: Enhancement
Components: Cache Server
Reporter: Galder ZamarreƱo
Assignee: Galder ZamarreƱo
Fix For: 5.2.0.ALPHA1, 5.2.0.FINAL
Get rid of commons-pool in Hot Rod client. We can implement connection pooling with
thread locals and a ringed array if re-entrant connection request are needed. This has the
benefit of getting rid an unnecessary dependency, and thread locals have been proved
previously (i.e. with marshallers) to provide very good solutions for reusing expensive
resources.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira