Btw how do we deal with preloading in a cluster?
Eg how do we prevent every node from preloading the same data?
On Aug 14, 2013, at 16:09, Mircea Markus wrote:
>
> On 14 Aug 2013, at 20:53, Sanne Grinovero wrote:
>
>> On 14 August 2013 17:59, Mircea Markus wrote:
>>>
>>> On 14 Aug 2013, at 15
It took me quite some time to figure out about a resource leak in the
Query testsuite.
The Search Engine properly warns about unclosed resources, but the
automated test "cleanup" phase of the Infinispan testing framework
swallows and ignores any exception happening during a
CacheManager#close.
I
I actually did not enjoy writing parsers and config builders etc...
On Aug 14, 2013, at 14:58, Mircea Markus wrote:
>
> On 14 Aug 2013, at 18:48, Dennis Reed wrote:
>
>>> I've written such parser on Friday, basically just copying and rewriting
>>> the SingleFileCacheStore stuff (adding my own p
Precisely, it is simple.
I have 2 nodes in the cluster & I have 1 TRANSACTIONAL cache.
At the very same time (few millisecs apart, both the nodes starts to write
key/value into the cache.
Both the nodes write the exact same Key, but different values in each Node.
I just have 6 keys/values to write
With SyncCommit = true & useSynchronization = true & moving to 5.3.0, I
don't see the problem any more.
I will continue testing it further.
infinispan-config.xml
@@ -25,13 +25,13 @@
Thanks for your help.
-Madhu
On 8/13/13 8:30 AM, "Madhu Venugopal (vmadhu)" wrote:
>Precisely
On 14 Aug 2013, at 20:53, Sanne Grinovero wrote:
> On 14 August 2013 17:59, Mircea Markus wrote:
>>
>> On 14 Aug 2013, at 15:26, Sanne Grinovero wrote:
>>
>>> On 14 August 2013 11:15, Mircea Markus wrote:
Currently the "preload" attribute is configured at *loaders* level and the
On 14 August 2013 17:59, Mircea Markus wrote:
>
> On 14 Aug 2013, at 15:26, Sanne Grinovero wrote:
>
>> On 14 August 2013 11:15, Mircea Markus wrote:
>>> Currently the "preload" attribute is configured at *loaders* level and the
>>> first cache loader in the chain is used for preloading.
>>> A
On 14 Aug 2013, at 19:12, Galder Zamarreño wrote:
>>
>> On 14 Aug 2013, at 08:09, Galder Zamarreño wrote:
>>
>>> IMO, the separate repository per cache store would make sense if each cache
>>> store was maintained by a separate person, and this person would make sure
>>> that it's kept up t
On 14 Aug 2013, at 18:48, Dennis Reed wrote:
>> I've written such parser on Friday, basically just copying and rewriting
>> the SingleFileCacheStore stuff (adding my own properties instead). It
>> took me about an hour and I don't hate anyone from infinispan team :)
>> Maybe I am already advance
On Aug 14, 2013, at 4:34 PM, Manik Surtani wrote:
>
> On 14 Aug 2013, at 08:09, Galder Zamarreño wrote:
>
>> IMO, the separate repository per cache store would make sense if each cache
>> store was maintained by a separate person, and this person would make sure
>> that it's kept up to date
On 08/14/2013 04:21 AM, Radim Vansa wrote:
> On 08/13/2013 04:50 PM, Mircea Markus wrote:
>> On 13 Aug 2013, at 15:30, Galder Zamarreño wrote:
>>
>>> On Aug 13, 2013, at 12:20 PM, Mircea Markus wrote:
>>>
On 13 Aug 2013, at 07:59, Galder Zamarreño wrote:
> My preference is for #1.
On 14 Aug 2013, at 15:26, Sanne Grinovero wrote:
> On 14 August 2013 11:15, Mircea Markus wrote:
>> Currently the "preload" attribute is configured at *loaders* level and the
>> first cache loader in the chain is used for preloading.
>> A better place for preload might be the individual loader
On 14 Aug 2013, at 15:34, Manik Surtani wrote:
>> IMO, the separate repository per cache store would make sense if each cache
>> store was maintained by a separate person, and this person would make sure
>> that it's kept up to date, he/she releases it, they have their community or
>> members
On 14 Aug 2013, at 17:39, Sanne Grinovero wrote:
> On 14 August 2013 15:39, Manik Surtani wrote:
>> I agree with you, Sanne.
>
> +1 always good :P
>
>> But I think from a config perspective, this does need an overhaul.
>
> +1
>
>> I think the correct approach - given some of the newly formi
On 14 Aug 2013, at 15:39, Manik Surtani wrote:
> I agree with you, Sanne. But I think from a config perspective, this does
> need an overhaul. I think the correct approach - given some of the newly
> forming ideas on the CacheLoader/CacheStore SPI we've been having - is to not
> specify whe
On 14 August 2013 15:39, Manik Surtani wrote:
> I agree with you, Sanne.
+1 always good :P
> But I think from a config perspective, this does need an overhaul.
+1
> I think the correct approach - given some of the newly forming ideas on the
> CacheLoader/CacheStore SPI we've been having - is
I agree with you, Sanne. But I think from a config perspective, this does need
an overhaul. I think the correct approach - given some of the newly forming
ideas on the CacheLoader/CacheStore SPI we've been having - is to not specify
whether purging is synchronous or not, and not to specify a n
On 14 Aug 2013, at 08:09, Galder Zamarreño wrote:
> IMO, the separate repository per cache store would make sense if each cache
> store was maintained by a separate person, and this person would make sure
> that it's kept up to date, he/she releases it, they have their community or
> members
On 14 Aug 2013, at 11:07, Mircea Markus wrote:
>
> On 14 Aug 2013, at 10:21, Radim Vansa wrote:
>
>> On 08/13/2013 04:50 PM, Mircea Markus wrote:
>>> On 13 Aug 2013, at 15:30, Galder Zamarreño wrote:
>>>
On Aug 13, 2013, at 12:20 PM, Mircea Markus wrote:
> On 13 Aug 2013, at
On 14 August 2013 11:15, Mircea Markus wrote:
> Currently the "preload" attribute is configured at *loaders* level and the
> first cache loader in the chain is used for preloading.
> A better place for preload might be the individual loader element: would
> indicate clearly which loader is used
On 14 August 2013 12:27, Radim Vansa wrote:
> It seems to me that these attributes may not be common to all cache
> stores. For some stores, the purging can be executed as part of other
> process anyway and it is not desired to purge the store on-demand. Some
> stores may not be able to purge in p
It seems to me that these attributes may not be common to all cache
stores. For some stores, the purging can be executed as part of other
process anyway and it is not desired to purge the store on-demand. Some
stores may not be able to purge in parallel at all (for example some
single-file stor
Hi,
I'm not sure these config attributes are needed.
- *purgeThreads* configures the number of threads that run the storage purging
(removal of expired entries from the storage). The more threads the faster the
purging processes. Is there a reason for putting effort in making the purging
fast
On 14 Aug 2013, at 08:09, Galder Zamarreño wrote:
> On Aug 13, 2013, at 1:39 PM, Sanne Grinovero wrote:
>
>> On 13 August 2013 11:48, Mircea Markus wrote:
>>>
>>> On 13 Aug 2013, at 11:40, Galder Zamarreño wrote:
>>>
We now have 8 separate git repositories for other cache stores in [1
Currently the "preload" attribute is configured at *loaders* level and the
first cache loader in the chain is used for preloading.
A better place for preload might be the individual loader element: would
indicate clearly which loader is used for preloading and also consistent with
the fetchPeris
On 14 Aug 2013, at 10:21, Radim Vansa wrote:
> On 08/13/2013 04:50 PM, Mircea Markus wrote:
>> On 13 Aug 2013, at 15:30, Galder Zamarreño wrote:
>>
>>> On Aug 13, 2013, at 12:20 PM, Mircea Markus wrote:
>>>
On 13 Aug 2013, at 07:59, Galder Zamarreño wrote:
> My preference is
On 08/13/2013 04:50 PM, Mircea Markus wrote:
> On 13 Aug 2013, at 15:30, Galder Zamarreño wrote:
>
>> On Aug 13, 2013, at 12:20 PM, Mircea Markus wrote:
>>
>>> On 13 Aug 2013, at 07:59, Galder Zamarreño wrote:
>>>
My preference is for #1.
The main reason is cos JSR-107 is about to
On Aug 13, 2013, at 1:39 PM, Sanne Grinovero wrote:
> On 13 August 2013 11:48, Mircea Markus wrote:
>>
>> On 13 Aug 2013, at 11:40, Galder Zamarreño wrote:
>>
>>> We now have 8 separate git repositories for other cache stores in [1].
>>> Doesn't this make it a royal PITA if we wanna change
28 matches
Mail list logo
