Adding excludes for log4j.xml to test-jar target
by Galder Zamarreno
Hi,
While working on the ISPN cache provider, I've realised that the test
jar contains a log4j.xml and this stops you from using a different log4j
settings to the one in the test jar. This is because log4j first and
foremost looks for a 'log4j.xml' and if present, it uses that. This
cannot be overriden with -Dlog4j.configuration.
As a result, I'm adding an excludes to avoid this log4j.xml ending up in
the test jar. The other alternative would be to rename
src/test/resources/log4j.xml to something else, i.e.
log4j-infinispan.xml but doing this would stop the log4j settings from
being picked up by default during Infinispan development, hence, I think
the excludes setting is the best option here.
If anyone has any issues with this, let me know.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years, 1 month
Re: [infinispan-dev] [hibernate-dev] [ISPN-6] COMMITTED tx status handling changed from JBC to ISPN
by Galder Zamarreno
Right, so basically it's time for me to integrate this into HB trunk.
I'll start with that work asap.
On 08/18/2009 08:36 PM, Steve Ebersole wrote:
> To clarify further...
>
> Within txn here there are calls to:
> 1) cacheAccess.lockRegion()
> 2) cacheAccess.removeAll()
>
> In after-completion phase there is a call to:
> 3) cacheAccess.unlockRegion(lock-from-#1)
>
> A transactional cache would not care about #1 nor #3...
>
>
> On Tue, 2009-08-18 at 13:25 -0500, Steve Ebersole wrote:
>> On Tue, 2009-08-18 at 16:50 +0200, Galder Zamarreno wrote:
>>> This change of behaivour is making Infinispan cache provider tests that
>>> do bulk modifications to fail. The reason it fails is because Hibernate
>>> has a javax.transaction.Synchronization implementation called
>>> CacheSynchronization that in it's afterCompletion(), it leads to call
>>> BulkOperationCleanupAction.evictEntityRegions() which clears the cache
>>> for the affected entities. Now, since the tx status is COMMITTED, the
>>> test fails.
>> This is no longer accurate. There was a bug in how
>> BulkOperationCleanupAction worked because it was still using the older
>> Hibrnate cache SPIs. See
>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-4034
>>
>>
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years, 1 month
[ISPN-6] COMMITTED tx status handling changed from JBC to ISPN
by Galder Zamarreno
Hi all,
More stuff related to the infinispan cache provider. The way we deal
with transactions that are not ACTIVE or PREPARING has changed from
JBoss Cache to Infinispan.
In JBoss Cache, TransactionTable.getCurrentTransaction() logged a
message if the transaction's status was committed whereas Infinispan
simply throws an IllegalStateException if the status is neither ACTIVE
nor PREPARING.
This change of behaivour is making Infinispan cache provider tests that
do bulk modifications to fail. The reason it fails is because Hibernate
has a javax.transaction.Synchronization implementation called
CacheSynchronization that in it's afterCompletion(), it leads to call
BulkOperationCleanupAction.evictEntityRegions() which clears the cache
for the affected entities. Now, since the tx status is COMMITTED, the
test fails.
Would there be any problems in maintaining the previous logic?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years, 1 month
Fresh Infinispan package at Maven repository
by Łukasz Moreń
---------- Forwarded message ----------
From: Jeff Ramsdale <jeff.ramsdale(a)gmail.com>
Date: Mon, 17 Aug 2009 13:47:01 -0700
Subject: Re: [infinispan-dev] Fresh Infinispan package at Maven repository
To: Łukasz Moreń <lukasz.moren(a)gmail.com>
+1!
Also, when releases are cut could you ensure source is deployed too?
Thanks!
-jeff
On Mon, Aug 17, 2009 at 1:41 PM, Łukasz Moreń <lukasz.moren(a)gmail.com>wrote:
> Hi,
> The latest snapshot with Infinispan package at maven rep:
> http://snapshots.jboss.org/maven2/org/infinispan/infinispan-core/4.0.0-SN...
>
> is from May. Would it be possible to create fresh one? It would be easier
> to run Lucene Directory based on Infinispan, I was writing, for others.
>
> Cheers,
> Lukasz Moren
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
16 years, 1 month
Re: [infinispan-dev] [JBoss JIRA] Created: (ISPN-157) MarshalledValueInterceptor does not override visitEvictCommand
by Manik Surtani
Thanks for creating and fixing the JIRA above, Galder.
Here's a further thought - we also need to test the eviction thread
with marshalled values. Well, not necessarily the eviction *thread*
per-se, but eviction being invoked via the
EvictionManager.processEviction() API - which is used by the eviction
thread as well as any external management thread that may wish to
schedule eviction.
My reason for concern is that this retrieves keys in order of
evictability by querying the data container (which is ordered)
directly. Now if these keys are marshalled values, what happens when
the EvictionManager calls cache.evict(key)? What *should* happen is
that the MarshalledValueInerceptor detects that the key is a
marshalled value already, and does not bother with further wrapping
and unwrapping.
However I don't think we currently have a unit test for this.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
16 years, 1 month
Replication of ConcurentHashMap object failure
by Łukasz Moreń
Hi,
I've noticed that attempt to replication ConcurentHashMap object causes an
error. With other Map's it works.
Example test:
public void testConcurrentHashMap() {
Cache cache1 = getCache(); //from somewhere, problem appears on many confs
Cache cache2 = getCache();
Map plainMap = new HashMap();
plainMap.put( "plainKey", "plainValue" );
Map concurrentMap = new ConcurrentHashMap();
concurrentMap.put( "concurrentKey", "concurrentValue" );
cache1.put( "plainMap", plainMap );
Map retrPlainMap = ( Map ) cache2.get( "plainMap" );
assertEquals( retrPlainMap, plainMap );
assertEquals( retrPlainMap.get( "plainKey" ), "plainValue" );
cache1.put( "concMap", concurrentMap );
retrPlainMap = ( Map ) cache2.get( "concMap" );
assertEquals( retrPlainMap, concurrentMap );
assertEquals( retrPlainMap.get( "concurrentKey" ), "concurrentValue" );
}
Cheers,
Lukasz Moren
16 years, 1 month
[hibernate-dev] Infinispan cache loaders in Hibernate Search
by Łukasz Moreń
Infinispan offers several persistance stores to persist content of cache,
i.e. based on file system, database, S3 amazon service. Is there some
recommendation which one should be used as a default for Hibernate Search
directory provider based on Infinispan cache?
What about cache loaders configuration strategy: one cache store per node,
one common store for all nodes, only single node allowed to write to
persistance store.
Maybe one common store is the right one.
Cheers
Lukasz Moren
16 years, 1 month
[ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
by Galder Zamarreno
Hi,
Re: https://jira.jboss.org/jira/browse/ISPN-6
Source code for this is currently located in an Infinispan branch in the
Hibernate SVN repo:
https://svn.jboss.org/repos/hibernate/core/branches/INFINISPAN/
http://anonsvn.jboss.org/repos/hibernate/core/branches/INFINISPAN/
I've picked this JIRA from Chris Bredesen. I'm waiting to get an answer
to an email I sent him yesterday but in the mean time, here's a list of
TODOs:
1. Current Infinispan region factory needs to point to a config with
named caches. Suggested property name: hibernate.cache.region.ispn4.configs
2. Need a equivalent version of this region factory where cache manager
is retrieved from JNDI. Suggsted property name:
hibernate.cache.region.ispn4.manager
3. Configuration properties for named cache names. Suggested property names:
hibernate.cache.region.ispn4.cfg.entity
hibernate.cache.region.ispn4.cfg.collection
hibernate.cache.region.ispn4.cfg.query
hibernate.cache.region.ispn4.cfg.timestamps
4. Resolve TransactionalAccess, ReadOnlyAccess and BaseRegion TODOs.
5. Enhance query results region so that query changes are not propagated
if invalidation is used and add query.localonly equivalent property.
Suggested name: hibernate.cache.region.ispn4.query.localonly
6. Add more unit tests!
7. Document in wiki.
Some notes I've made while investigating this:
- Whereas with JBC2/3, we had the possibility of a shared cache for all
types (entities, collections, query,...etc) and a multiplexed version
where each type had a specific cache, in Infinispan, it only makes the
latter. Amongst other reasons because we don't have eviction regions any
more and so we can't exclude the timestamp modification region as we did
in JBC2/3. Overall, having a single option is a good thing from a
configuration and usability perspective! Remember how complex eviction
region definition could get for entities...
Finally, a question to the list, specially for Brian/Steve who worked on
the JBC2/3 integration layer:
- Do we need a similar timestamp region local cache implementation for
an ISPN based cache provider?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years, 1 month
