[
https://issues.apache.org/jira/browse/GEODE-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16419807#comment-16419807
]
Blake Bender commented on GEODE-3993:
-------------------------------------
So perhaps the most offensive issue here is that, wherever we create a DI/DO
internally, we call createDataInput/Output then _immediately_ call setPoolName.
If we simply add the pool name as a parameter to
CacheImpl::createDataInput/Output, then in Cache::createDataInput/Output we
passed the name of the first pool from the pool manager, the user could call
the cache method and create without a pool name, and we could remove the
setPoolName method from DataInput/DataOutput altogether.
> Re-evaluate the Cache.createDataInput/Output API
> ------------------------------------------------
>
> Key: GEODE-3993
> URL: https://issues.apache.org/jira/browse/GEODE-3993
> Project: Geode
> Issue Type: Task
> Components: native client
> Reporter: Jacob S. Barrett
> Priority: Major
>
> Having the factory on Cache is convenient for end users but produces
> DataInput/Output objects that are not usable for internal use because it
> relies on access to the Pool. If a User's use of the DataInput/Output also
> needs Pool then it will be broken. Internally we turn around and call an
> internal API to add the Pool to the DataInput/Output. This all seems really
> dirty, can we do better?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
