[jira] [Commented] (GEODE-7532) PoolManagerImpl.register(:Pool) and PoolManagerImpl.unregister(:Pool) should be declared on the PoolManager interface

["Dan Smith (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GEODE-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16988917#comment-16988917 ] 

Dan Smith commented on GEODE-7532:
----------------------------------

Would it also fix the issue to deprecate the PoolManager singleton and move the Pool creation logic to ClientCache? That would allow frameworks to wrap ClientCache, PoolFactory, and Pool consistently.

If that works, I think that will be a better fix - we're trying to get rid of singletons in the Geode code base anyway.

FYI, the Pool interface is not an interface that allows plugging in different connection pooling implementations. It is the *public* view of an internal object within Geode (much like Region, QueryService, AsyncEventQueue, etc.). 

Injecting a Pool into PoolManagerImpl is not likely to work except for maybe the most trivial cases of PoolManager.find(Pool). Once you actually try to use the pool, like attaching it to region, it's going to fail because it needs a real internal PoolImpl that has all of the actual methods and functionality to send messages to servers, etc. Really, PoolManagerImpl should have lists of PoolImpls, I'm not sure why it has an internal collection of Pool objects that are later cast.

> PoolManagerImpl.register(:Pool) and PoolManagerImpl.unregister(:Pool) should be declared on the PoolManager interface
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: GEODE-7532
>                 URL: https://issues.apache.org/jira/browse/GEODE-7532
>             Project: Geode
>          Issue Type: Improvement
>          Components: client/server
>            Reporter: John Blum
>            Priority: Major
>
> For all general uses, and especially for framework and tooling purposes, both {{register(:Pool)}} and {{unregister(:Pool)}} methods of the {{PoolManagerImpl}} class should be part of the {{PoolManager}} interface given both methods are technically part of the "{{public}}" API despite {{PoolManagerImpl}} being "deemed" part of some "internal" API (which is completely arbitrary and irrelevant since it is not properly enforced by the language constructs of Java).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)