on preload and state integration
by Mircea Markus
Hi,
This is not high prio, but it is something I've come across several time now.
Both the preload and the state transfer code, in order to add a batch of entries into the cache use the following pattern:
for (InternalCacheEntry e : state) {
cache.getAdvancedCache()
.withFlags(CACHE_MODE_LOCAL, SKIP_OWNERSHIP_CHECK, SKIP_CACHE_STORE,SKIP_REMOTE_LOOKUP, SKIP_INDEXING)
.put(...);
}
This has some flaws:
- it is not the fastest way of inserting stuff into the cache. E.g. in the case of preload it would be much simpler to simply drain the data straight into the container. Similar for a cache store.
- it pollutes the rest of the code unnecessarily. E.g. at the moment when we preload data, the topology information might not be available simply because the cache has not started yet. So all the interceptors that handle the put during preload need to somehow guard against using the topology information: e.g. StateTransferInterceptor, EntryWrappingInterceptor, LockingInterceptor etc.
Now this approach is in use mainly because, during state insertion, we need to (re)use some logic which is present in the interceptors.
An different approach to handling state integration would be to move that reusable logic (where's needed) into corresponding managers and invoke methods on the manager directly instead of passing everything through the interceptor stack (users interested in these insertion can register listeners). I'm not sure that this would work with the extending modules?
Wdyt?
Cheers,
Mircea
13 years, 1 month
Fresh blood on Infinispan Query
by Sanne Grinovero
Hi all,
since Marko Lukša is again submitting nice patches to Infinispan
Query, I've changed JIRA permissions to add him to the team.
Thanks Marko for all the help! Now you can send more and assign issues
to yourself :P
Cheers,
Sanne
13 years, 1 month
Syncronize cache entities with Database Tables(rows)
by kalana sandhana
Dear All ,
I'm Very New to Infinispan Framework.I want To Know can Infinispan Use For
Cashed Data Syncronization with Oracle database.Scenario is This .Think I
have Two Main applications one is Highly Concurrent use app and Other is
used as Admin module .Since it is highly concrrent I want To reduse
Database connections (Load the entities into cache (read write enable) and
Use it from There without calling database).But mean Time I want to Update
Database according to The cache Changes Since Admin Module Using Database
directly.Can That Update process (Cache To Database)handle in enitity
level without involving application.Please let me know Infinispan Supports
this scenario or not?If Supports Please share Ideas and some sample code
with me.
Thanks And regards
Kalana Abeywickrama
13 years, 1 month
Re: [infinispan-dev] getting stopped cache
by Ales Justin
OK, let me try this workaround.
But should Cache::stop also remove it or not?
If yes, I might dig deeper into finding the culprit,
if not, then the workaround should do, I guess.
-Ales
> As a workaround, couldn't you check what the status of the cache is before using it? If it's stopped, you could call cache.start() again.
>
> On Aug 25, 2012, at 3:44 PM, Ales Justin wrote:
>
>> When running CapeDwarf tests these days I get this broken behavior:
>> (using: Ispan 5.2.0.Alpha2)
>>
>> On 1st test all works OK:
>> * getting the X cache
>> * passing it to SearchManager (from Ispan Query)
>> * doing queries, etc
>> * stopping the X cache on app (aka Arquillian test) undeploy
>>
>> But when running 2nd app (more Arquillian tests) it breaks.
>>
>> I'm again using X cache, via this lookup:
>> (where toCacheName == X)
>>
>> final Cache<K, V> cache = cacheManager.getCache(toCacheName(config, appId), false);
>> if (cache != null)
>> return cache;
>>
>> And I actually get some cache, where I would expect none.
>>
>> Since this cache is not new, it's never run against Ispan Query's LifecycleManager,
>> hence there is no QueryInterceptor in its component registry.
>>
>> Which is where the app breaks: SearchManager requires QueryInterceptor in cache' component registry.
>>
>> Shouldn't Cache::stop also remove the cache from EmbeddedCacheManager?
>> btw: this used to work, dunno when it broke ...
>>
>> Anyone else seeing something similar?
>>
>> -Ales
>>
>> ----------
>>
>> 15:32:06,810 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (http-/192.168.1.101:8080-3) Exception sending request initialized lifecycle event to listener instance of class org.jboss.capedwarf.appidentity.GAEListener: java.lang.IllegalArgumentException: Indexing was not enabled on this cache. class org.infinispan.query.backend.QueryInterceptor not found in registry
>> at org.infinispan.query.impl.ComponentRegistryUtils.getComponent(ComponentRegistryUtils.java:40)
>> at org.infinispan.query.SearchManagerImpl.<init>(SearchManagerImpl.java:57)
>> at org.infinispan.query.Search.getSearchManager(Search.java:39)
>> at org.jboss.capedwarf.datastore.AbstractDatastoreService.<init>(AbstractDatastoreService.java:61) [capedwarf-datastore-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
>> at org.jboss.capedwarf.datastore.JBossDatastoreService.<init>(JBossDatastoreService.java:56) [capedwarf-datastore-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
>> at com.google.appengine.api.datastore.DatastoreServiceFactory.getDatastoreService(DatastoreServiceFactory.java) [appengine-api-1.0-sdk-1.7.0.jar:]
>> at org.jboss.capedwarf.log.JBossLogService.requestStarted(JBossLogService.java:215) [capedwarf-log-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
13 years, 1 month
getting stopped cache
by Ales Justin
When running CapeDwarf tests these days I get this broken behavior:
(using: Ispan 5.2.0.Alpha2)
On 1st test all works OK:
* getting the X cache
* passing it to SearchManager (from Ispan Query)
* doing queries, etc
* stopping the X cache on app (aka Arquillian test) undeploy
But when running 2nd app (more Arquillian tests) it breaks.
I'm again using X cache, via this lookup:
(where toCacheName == X)
final Cache<K, V> cache = cacheManager.getCache(toCacheName(config, appId), false);
if (cache != null)
return cache;
And I actually get some cache, where I would expect none.
Since this cache is not new, it's never run against Ispan Query's LifecycleManager,
hence there is no QueryInterceptor in its component registry.
Which is where the app breaks: SearchManager requires QueryInterceptor in cache' component registry.
Shouldn't Cache::stop also remove the cache from EmbeddedCacheManager?
btw: this used to work, dunno when it broke ...
Anyone else seeing something similar?
-Ales
----------
15:32:06,810 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (http-/192.168.1.101:8080-3) Exception sending request initialized lifecycle event to listener instance of class org.jboss.capedwarf.appidentity.GAEListener: java.lang.IllegalArgumentException: Indexing was not enabled on this cache. class org.infinispan.query.backend.QueryInterceptor not found in registry
at org.infinispan.query.impl.ComponentRegistryUtils.getComponent(ComponentRegistryUtils.java:40)
at org.infinispan.query.SearchManagerImpl.<init>(SearchManagerImpl.java:57)
at org.infinispan.query.Search.getSearchManager(Search.java:39)
at org.jboss.capedwarf.datastore.AbstractDatastoreService.<init>(AbstractDatastoreService.java:61) [capedwarf-datastore-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
at org.jboss.capedwarf.datastore.JBossDatastoreService.<init>(JBossDatastoreService.java:56) [capedwarf-datastore-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
at com.google.appengine.api.datastore.DatastoreServiceFactory.getDatastoreService(DatastoreServiceFactory.java) [appengine-api-1.0-sdk-1.7.0.jar:]
at org.jboss.capedwarf.log.JBossLogService.requestStarted(JBossLogService.java:215) [capedwarf-log-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
13 years, 1 month
Random XML InternalError
by Galder Zamarreño
Anyone has seen this exception before?
2012-08-27 11:41:08,664 ERROR (testng-MinimalConfigurationParsingTest) [org.infinispan.test.fwk.UnitTestTestNGListener] Method testGlobalAndDefaultSection(org.infinispan.config.parsing.MinimalConfigurationParsingTest) threw an exception
java.lang.InternalError
at com.sun.xml.internal.bind.v2.model.annotation.RuntimeInlineAnnotationReader.getClassValue(RuntimeInlineAnnotationReader.java:128)
Full stactrace in https://gist.github.com/3487453
It happened randomly in Infinispan master.
I've seen some posts via google, but nothing conclusive.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
13 years, 1 month
status meeting on Monday
by Mircea Markus
Hi,
Monday is bank holiday in UK so Manik, Sanne and I won't make it for the status meeting.
So for this time only let's have it on Tue at the same time.
Cheers,
Mircea
13 years, 1 month
timeline for Infinispan 5.2.0 alpha releases
by Mircea Markus
Hi,
Given the complexity of the NBST work submitted by Dan and Adrian, the scheduled 5.2.Alpha3 release date is Fr 24 Aug.
The estimated date for an x-site replication release is Fr 31 Aug.
Cheers,
Mircea
13 years, 1 month
maven-surefire-plugin version
by Adrian Nistor
Hi all,
I'm going to close ISPN-2146 [1], which is maven-surefire-plugin related
(SUREFIRE-879). The issue was temporarily solved on master by switching
to maven-surefire-plugin 2.13-SNAPSHOT but it seems there won't be any
stable 2.13 release soon so I'm going to switch to 2.12.2, which now
also contains the SUREFIRE-879 fix.
I noticed some sub-modules use an older surefire version than the parent
pom and I would like to upgrade those too unless there's a voodoo reason
to use the old version. As an example, parent/pom.xml uses
maven-surefire-plugin version 2.4.3-JBOSS in traceTests profile and
there's a comment that seems to indicate this version is needed "to
avoid external log4j settings not being discovered when passed as
command line arguments". I could not reproduce such an issue with 2.12.2.
Does anyone remember what issue is maven-surefire 2.4.3-JBOSS solving?
Thanks,
Adrian
[1] https://issues.jboss.org/browse/ISPN-2146
13 years, 1 month
Removing AHM.commit() call in ISPN-2212
by Galder Zamarreño
Hi,
Re: https://issues.jboss.org/browse/ISPN-2212
Re: https://github.com/infinispan/infinispan/pull/1255
The problem is that in an asynchronous set up with replication queue, ReadCommittedEntry.commit() will clear the delta before this has been replicated.
My solution has been to remove the commit() call because in a clustered environment, or an environment where there's marshalling to be done (marshalled value, or cache store storage), the delta will already be cleared as part of the delta() call.
So I don't see any risks for clustered environments.
For local caches (no cluster, no mrashalling), atomic hash map do not really make sense.
So, I think this is a safe solution.
The alternative would involve moving the commit() call to a step after which we're sure we've covered all bases, including repl queue and I could not see any such opportunity. Even hacking ReplicationQueueImpl to go through all modifications and check values would be wasteful.
Thoughts?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
13 years, 1 month
