Re: [infinispan-dev] [hibernate-dev] Hibernate 3.5.0.Beta-1 released
by Galder Zamarreno
Bugger, this was released hours before I committed the Infinispan cache
provider :(
Steve, let's catch up before next 3.5 release in order to figure out
what's needed to make Infinispan the default cache provider. Do you make
such decision based on any performance test or the configuration itself?
My aim is to make Infinispan the best 2nd level cache provider out there.
On 08/21/2009 06:43 PM, Steve Ebersole wrote:
> Hibernate 3.5.0.Beta-1 has been released. Please see
> http://in.relation.to/12153.lace for details.
>
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years
Re: [infinispan-dev] Evaluating Infinispan
by Krzysztof Sobolewski
Dnia piątek 18 wrzesień 2009 o 18:00:03 infinispan-dev-request(a)lists.jboss.org
napisał(a):
> Maybe it is the tree cache compatability layer, but the infinispan
> Cache "new" class seems quite nice, generics wise.
> Perhaps you have identified some JIRA worthy issues specific to the
> tree cache layer? (as it probably doesn't get as much attention at the
> moment?)
Well, my biggest gripe with the tree cache layer is that it doesn't like when
the node does not exist (for example doing a Cache.put(Fqn, key, value) would
create the node in JBCache, but in Infinispan it just throws NPE). That forces
me to get/create the node first, and then perform the operation. It doesn't
look very atomic. Would batches help here?
Regarding generics, there are more types that could be parameterized (e.g. it
is possible to make the coupling between DeltaAware and its Delta
implementation more type-safe). The implementation classes of generic
interfaces usually use raw types. And this TreeCache.getCache() thing :) I'm
not a big fan of AtomicMapCache.getAtomicMap() either...
BTW: How do I actually get a reference to AtomicMapCache? I haven't seen any
API except for casting...
-KS
16 years
Evaluating Infinispan
by Krzysztof Sobolewski
I'm currently evaluating Infinispan for our internal project (porting from
JBoss Cache) and I have some comments/issues - and probably more to come. I
figure I should post them before Infinispan leaves beta stage :) If they're
JIRA-worthy, I can also repost them there.
First, something small: TreeCache.getCache() (I obviously first try to use the
tree compatibility layer) returns Cache<K,V>, which is obviously wrong, as the
TreeCacheImpl returns Cache (raw type) which is in fact
AtomicMapCache<NodeKey,Object> (and really, really in fact it's
AtomicMapCache<NodeKey,AtomicMap<?,?>).
As a side note, I don't really like how the getAtomicMap() overrides the V
type parameter of Cache. The cache is supposed to store and return V's, but
this methods forcibly puts AtomicHashMap as values. I say this will lead to
problems. Maybe it's better to make AtomicMapCache<K> (one type parameter)
extend Cache<K,AtomicMap<?,?>> (maybe even with optional type parameters for
AtomicMap).
As another side note, I can see that you're not big fans of generics :)
Second issue I wanted to mention, which also exists in JBoss Cache but I never
got around to reporting a bug, is that the JDBC cache stores use lock
striping. I've run into *lots* of trouble with lock striping (here and in MVCC
lock manager) so I always turn it off (or reimplement, if there's no option for
that). Increasing the concurrency level is not an option because whatever it
is, it's still not correct (as in: non-zero probability of collision), at
least for my use cases.
So... Can I ask for an option to not do lock striping... anywhere? :)
-KS
16 years
Setting JGroups channel name
by Vladimir Blagojevic
Hi Manik,
These two issue seem to be duplicate, right? I do not understand how is
it possible to set node name from transport element when we have to set
a different name for each channel created in order for this feature to
have any sense?
If you want this feature maybe we need channelNamingSchemaClass
attribute in transport element. Instance of this class will conform to
certain interface and will be consulted to generate the next in sequence
channel name for the created channel. Is this what you meant?
Let me know.
https://jira.jboss.org/jira/browse/ISPN-182
https://jira.jboss.org/jira/browse/ISPN-181
16 years
A tip: Using a random word generator to generate uncommon test data
by Galder Zamarreno
Guys,
Looking at the Infinispan tests, I've seen plenty same keys/values
repeated in loads of tests, i.e. k1, k2, v1, v2....etc, so sometimes,
when you're debugging a specific tests, particularly when running the
whole testsuite, it's hard to pint point the data related to your test
since same key/values are used by several tests.
So, to try to help with finding the data related to my tests, I'm trying
to use random word generator to generate uncommon or obscure words that
I can use in the tests. Doing this allows me to quickly find my data in
the logs, i.e. "key-isoprene"
I don't know whether other people are interesting in using a similar
method but at least for me, it helps.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years
Test cleanup
by Vladimir Blagojevic
Hey guys,
I do not know the details behind the decision to run cleanup after each
test method in all subclasses of MultipleCacheManagersTest but the
consequence is that the testsuite execution is indeed really slow. After
each test method execution we are killing JGroups instances and then
recreating at least two of them who then have to find each other, join,
create a cluster before the next test method can be run again.
There is no reason why we cannot run a check after each test method to
ensure that cache instance are totally pristine and in the case the are
not we can kill them and only then recreate cluster.
Cheers
16 years
Re: [infinispan-dev] Infinispan testsuite sometimes throws: java.lang.OutOfMemoryError: unable to create new native thread
by Manik Surtani
On 14 Sep 2009, at 22:05, Vladimir Blagojevic wrote:
> Hey,
>
> Did you know that test methods annotated with afterMethod and
> afterClass were not run in case of exception being thrown during
> test setup and execution. After you turn on annotation property
> alwaysRun=true then you get the desired effect - cleanup is executed
> no matter what.
>
> I found two relevant places these were used: SingleCacheManagerTest
> MultipleManagersCacheTest.
Very useful to know - cc'ing infinispan-dev with this info as well.
Vlad, have you corrected SingleCacheManagerTest and
MultipleManagersCacheTest to add alwaysRun = true?
You may also want to mention this on
http://www.jboss.org/community/wiki/ParallelTestSuite
>
> Are there any others?
>
> Cheers
>
> On 09-09-14 10:43 AM, Galder Zamarreno wrote:
>>
>>
>> On 09/14/2009 04:40 PM, Vladimir Blagojevic wrote:
>>> </snip>
>>>
>>> I noticed that testsuite runs more than 500 threads at some
>>> points. I
>>> will also try to see what I can dig up today.
>>>
>>
>> If you see it again, try to generate a thread dump. I suspect the
>> thread dumps might be massive to be able to easily copy/paste from
>> command line output, so from now on I'm gonna direct the output to
>> a file and tail it instead.
>>
>
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
16 years
Re: [infinispan-dev] Feedback on Infinispan patch
by Sanne Grinovero
Why not commit the Infinispan tx at lock release, instead of at
indexwriter's commit?
On 9 22, 2009 2:16 AM, "Łukasz Moreń" <lukasz.moren(a)gmail.com> wrote:
Hi,
Thanks for explanation.
Maybe better I will concentrate on the first release and postpone
distributed writing.
There is already LockStrategy that uses Infinispan. With using it I was
wrapping changes made by IndexWriter in Infinispan transaction, because of
performance reasons -
on lock obtaining transaction was started, on lock release transaction was
commited. Hovewer Ispn transaction commit on lock release is not good idea
since IndexWriter calls index commit before lock is released(and ispn
transaction is committed).
I was thinking to override Workspace class and getIndexWriter(start
infinispan tx), commitIndexWriter (commit tx) methods to wrap IndexWrite
lifecycle, but this needs few other changes. Some other ideas?
Cheers,
Lukasz
2009/9/21 Sanne Grinovero <sanne.grinovero(a)gmail.com>
> > Hi Łukasz, > you've rightful concerns, because the way the IndexWriter
tries to > achieve the l...
16 years
