[jira] [Assigned] (GEODE-4459) Remove singleton calls from all tests in org.apache.geode.pdx

2018-03-01 Thread Avinash Dongre (JIRA)

 [ 
https://issues.apache.org/jira/browse/GEODE-4459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avinash Dongre reassigned GEODE-4459:
-

Assignee: Avinash Dongre

> Remove singleton calls from all tests in org.apache.geode.pdx
> -
>
> Key: GEODE-4459
> URL: https://issues.apache.org/jira/browse/GEODE-4459
> Project: Geode
>  Issue Type: Sub-task
>  Components: serialization, tests
>Reporter: Kirk Lund
>Assignee: Avinash Dongre
>Priority: Major
>
> These tests in org.apache.geode.pdx invoke singleton getters.
> CacheFactory.getAnyInstance():
> * JSONFormatterJUnitTest
> GemFireCacheImpl.getInstance():
> * ClientsWithVersioningRetryDUnitTest
> * PdxAttributesJUnitTest
> GemFireCacheImpl.getForPdx(String):
> * PdxInstanceJUnitTest
> InternalDistributedSystem.getAnyInstance():
> * DistributedSystemIdDUnitTest



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-4453) Remove singleton calls from all tests in org.apache.geode.internal.cache.execute

2018-02-27 Thread Avinash Dongre (JIRA)

 [ 
https://issues.apache.org/jira/browse/GEODE-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avinash Dongre reassigned GEODE-4453:
-

Assignee: Avinash Dongre

> Remove singleton calls from all tests in 
> org.apache.geode.internal.cache.execute
> 
>
> Key: GEODE-4453
> URL: https://issues.apache.org/jira/browse/GEODE-4453
> Project: Geode
>  Issue Type: Sub-task
>  Components: functions, querying, tests
>Reporter: Kirk Lund
>Assignee: Avinash Dongre
>Priority: Major
>
> These tests in org.apache.geode.internal.cache.execute invoke singleton 
> getters.
> CacheFactory.getAnyInstance():
> * OnGroupsFunctionExecutionDUnitTest
> * MemberFunctionExecutionDUnitTest
> * FunctionServiceBase
> * QueryDataInconsistencyDUnitTest
> CacheFactory.getExisting(DistributedSystem):
> * OnGroupsFunctionExecutionDUnitTest
> GemFireCacheImpl.getInstance():
> * LocalDataSetIndexingDUnitTest
> * PRFunctionExecutionDUnitTest
> InternalDistributedSystem.getAnyInstance():
> * FunctionServiceClientAccessorPRBase$BucketMovingNonHAFunction
> * FunctionServiceBase
> * FunctionServiceBase$CacheClosingNonHAFunction
> * TestFunction
> InternalDistributedSystem.getConnectedInstance():
> * OnGroupsFunctionExecutionDUnitTest
> * RestAPIsOnGroupsFunctionExecutionDUnitTest



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-4528) Remove singleton calls from product code in org.apache.geode.internal.cache.tier

2018-02-14 Thread Avinash Dongre (JIRA)

 [ 
https://issues.apache.org/jira/browse/GEODE-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avinash Dongre reassigned GEODE-4528:
-

Assignee: Avinash Dongre

> Remove singleton calls from product code in 
> org.apache.geode.internal.cache.tier
> 
>
> Key: GEODE-4528
> URL: https://issues.apache.org/jira/browse/GEODE-4528
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Kirk Lund
>Assignee: Avinash Dongre
>Priority: Major
>
> These product classes in org.apache.geode.internal.cache.tier invoke 
> singleton getters.
> CacheFactory.getAnyInstance():
> * InternalClientMembership



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-4525) Remove singleton calls from product code in org.apache.geode.internal.cache.wan

2018-02-05 Thread Avinash Dongre (JIRA)

 [ 
https://issues.apache.org/jira/browse/GEODE-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avinash Dongre reassigned GEODE-4525:
-

Assignee: Avinash Dongre

> Remove singleton calls from product code in 
> org.apache.geode.internal.cache.wan
> ---
>
> Key: GEODE-4525
> URL: https://issues.apache.org/jira/browse/GEODE-4525
> Project: Geode
>  Issue Type: Sub-task
>  Components: wan
>Reporter: Kirk Lund
>Assignee: Avinash Dongre
>Priority: Major
>
> These product classes in org.apache.geode.internal.cache.wan invoke singleton 
> getters.
> CacheFactory.getAnyInstance():
> * GatewaySenderEventImpl
> * GatewaySenderQueueEntrySynchronizationOperation
> * 
> GatewaySenderQueueEntrySynchronizationOperation$GatewaySenderQueueEntrySynchronizationMessage
> * 
> GatewaySenderQueueEntrySynchronizationOperation$GatewaySenderQueueEntrySynchronizationReplyProcessor
> InternalDistributedSystem.getAnyInstance():
> * GatewayReceiverStats
> * GatewaySenderFactoryImpl



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-2141) StatisticsMonitor and StatMonitorHandler should use ConcurrentHashSet to store monitors, listeners and statisticIds

2016-12-01 Thread Avinash Dongre (JIRA)

 [ 
https://issues.apache.org/jira/browse/GEODE-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avinash Dongre resolved GEODE-2141.
---
Resolution: Fixed

> StatisticsMonitor and StatMonitorHandler should use ConcurrentHashSet to 
> store monitors, listeners and statisticIds
> ---
>
> Key: GEODE-2141
> URL: https://issues.apache.org/jira/browse/GEODE-2141
> Project: Geode
>  Issue Type: Improvement
>Reporter: Avinash Dongre
>Assignee: Avinash Dongre
>
> In StatisticsMonitor and StatMonitorHandler List is used to store monitors, 
> listeners and statisticIds.
> We should be using ConcurrentHashSet for performance Reason.
> In my local testing  When I replace the List to 
> com.gemstone.gemfire.internal.concurrent.
> ConcurrentHashSet
> I see significant improvement in creating large number of region creation.
> ( from ~7hrs to ~26 minutes)
> More details about the same is on dev list.
> Refer : http://markmail.org/message/o7td3fczylx4uaet



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (GEODE-2141) StatisticsMonitor and StatMonitorHandler should use ConcurrentHashSet to store monitors, listeners and statisticIds

2016-11-25 Thread Avinash Dongre (JIRA)

 [ 
https://issues.apache.org/jira/browse/GEODE-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avinash Dongre reassigned GEODE-2141:
-

Assignee: Avinash Dongre

> StatisticsMonitor and StatMonitorHandler should use ConcurrentHashSet to 
> store monitors, listeners and statisticIds
> ---
>
> Key: GEODE-2141
> URL: https://issues.apache.org/jira/browse/GEODE-2141
> Project: Geode
>  Issue Type: Improvement
>Reporter: Avinash Dongre
>Assignee: Avinash Dongre
>
> In StatisticsMonitor and StatMonitorHandler List is used to store monitors, 
> listeners and statisticIds.
> We should be using ConcurrentHashSet for performance Reason.
> In my local testing  When I replace the List to 
> com.gemstone.gemfire.internal.concurrent.
> ConcurrentHashSet
> I see significant improvement in creating large number of region creation.
> ( from ~7hrs to ~26 minutes)
> More details about the same is on dev list.
> Refer : http://markmail.org/message/o7td3fczylx4uaet



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (GEODE-1970) Oplog flush methods no longer need to catch ClosedChannelException

2016-11-19 Thread Avinash Dongre (JIRA)

 [ 
https://issues.apache.org/jira/browse/GEODE-1970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avinash Dongre reassigned GEODE-1970:
-

Assignee: Avinash Dongre

> Oplog flush methods no longer need to catch ClosedChannelException
> --
>
> Key: GEODE-1970
> URL: https://issues.apache.org/jira/browse/GEODE-1970
> Project: Geode
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>
> The flush methods in Oplog.java catch ClosedChannelException and say:
>   // It is possible for a channel to be closed when our code does not
>   // explicitly call channel.close (when we will set RAFclosed).
>   // This can happen when a thread is doing an io op and is interrupted.
>   // That thread will see ClosedByInterruptException but it will also
>   // close the channel and then we will see ClosedChannelException.
> However the channel is now implemented by UninterruptibleFileChannel and that 
> implementation reopens the channel if it is closed do to interrupt so this 
> code no longer needs to catch ClosedChannelException.
> Note that similar code in OverflowOplog.java does still need to catch it 
> because it does not use UninterruptibleFileChannel.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)