[ 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+. -- 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

[ https://issues.jboss.org/browse/ISPN-1818?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-1818: ---------------------------------------- Fair point Mircea. Besides, the improvements you made to the Hot Rod client have really improved performance. We still need to get to the bottom of the connection pool issues. See ISPN-2108 and other related issues wrt randomly failing tests in this are. -- 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