+1
Maybe we can create a JIRA for this.
On 11/22/16 11:56, Dan Smith wrote:
Seems like fixing that StatisicsMonitor to use a ConcurrentHashSet is a
good fix, there's no reason why it should be a list that I can see.
As other folks mentioned, there is significant overhead involved in
creating
Seems like fixing that StatisicsMonitor to use a ConcurrentHashSet is a
good fix, there's no reason why it should be a list that I can see.
As other folks mentioned, there is significant overhead involved in
creating that many regions in terms of memory, messaging, and disk
metadata. Especially co
@Avinesh,
I's be interested in understanding why you need to create 1500 regions.
Maybe if you could explain the usecase where 1500 regions are required
we could potentially help with another solution.
This reminds me of the Oracle Table limitation of 999 columns Where
the Oracle support
Hi All,
Thanks @Mike. Unfortunately I have situation where-in I need to create
those many number of regions.
I need to understand why in StatisticsMonitor and StatMonitorHandler
List is used to store monitors, listeners and statisticIds , is there any
particular reason for this.
When I replace
