Re: [infinispan-dev] Configuration reference - final solution
by Vladimir Blagojevic
On 21/08/09 12:18 PM, Manik Surtani wrote:
> I would say this should be on the infinispan-dev list - but the list
> is broken at the moment! :P
>
> On 21 Aug 2009, at 11:14, Vladimir Blagojevic wrote:
>
>> Hey,
>>
>> We have two options for the final HTML configuration reference solution:
>>
>> - keep things as they are and maintain our documentation annotations
>> (CofigurationElement, ConfigurationAttribute etc)
>> - implement a new solution based on XML Schema and javadoc comments
>>
>> Since you are familiar with the first let me explain the second. The
>> new solution loads created XML Schema using XSOM library and creates
>> in-memory tree representation of that schema. Once that is done it is
>> very simple to create exact same reference as it is today, however,
>> the content would be coming from source file javadoc, not annotations
>> as it is today. We would simply document our Java classes that
>> correspond to XML schema elements with special @ tags. All
>> documentation related to attributes, general element description in
>> configuration reference would be coming from our own javadoc @tags.
>>
>> One shortcoming of the new solution is that not all types of loaders
>> would be documented. Recall, how different loaders allow special
>> properties and how these are documented in configuration reference.
>> Proposed new solution would not contain these but as a trade-off we
>> would get rid of all these ConfigurationElement annotations. Hmmm,
>> now that I am writing this email I realize that it would be still
>> possible to do document all these different loaders but it would
>> require a bit more effort - an extra day or two. It is doable.
>
> What does the 2nd solution entail by way of dependencies? I assume we
> already have all of the JSXB deps we need?
There extra two dependencies: xsom.jar and relaxngDatatype.jar
> Perhaps a few more deps for the generation tool, but nothing more for
> the distro/runtime?
Yes, strictly in tools project. These would not go into distro.
>
> Also, is there any impact (performance-wise or anything else) on the
> runtime?
Maybe on tools execution time but infinispan runtime absolutely not.
>
> Finally, what are these extra Javadoc tags going to look like? Could
> you show us a short sample?
/**
*
* @configElementRef locking
* @configElementDoc any documentation here
*/
@XmlAccessorType(XmlAccessType.PROPERTY)
private static class LockingType extends
AbstractNamedCacheConfigurationBean{
/** The serialVersionUID */
private static final long serialVersionUID = 8142143187082119506L;
@Dynamic
private Long lockAcquisitionTimeout = 10000L;
private IsolationLevel isolationLevel =
IsolationLevel.READ_COMMITTED;
private Boolean writeSkewCheck = false;
private Boolean useLockStriping = true;
private Integer concurrencyLevel = 500;
/**
* @configElementDoc reference documentation here
*/
@XmlAttribute
public void setLockAcquisitionTimeout(Long lockAcquisitionTimeout) {
testImmutability("lockAcquisitionTimeout");
this.lockAcquisitionTimeout = lockAcquisitionTimeout;
}
/**
* @configElementDoc reference documentation here
*/
@XmlAttribute
public void setIsolationLevel(IsolationLevel isolationLevel) {
testImmutability("isolationLevel");
this.isolationLevel = isolationLevel;
}
/**
* @configElementDoc reference documentation here
*/
@XmlAttribute
public void setWriteSkewCheck(Boolean writeSkewCheck) {
testImmutability("writeSkewCheck");
this.writeSkewCheck = writeSkewCheck;
}
/**
* @configElementDoc reference documentation here
*/
@XmlAttribute
public void setUseLockStriping(Boolean useLockStriping) {
testImmutability("useLockStriping");
this.useLockStriping = useLockStriping;
}
@XmlAttribute
public void setConcurrencyLevel(Integer concurrencyLevel) {
testImmutability("concurrencyLevel");
this.concurrencyLevel = concurrencyLevel;
}
}
16 years, 1 month
Re: [infinispan-dev] Infinispan tx, config and multithreading
by Emmanuel Bernard
Could it be that you are not using the same transaction between
different threads (ie you physically start different ones or different
"Infinispan contexts")?
Infini guys, do you support transactional operation spanning several
concurrent threads?
On 13 août 09, at 14:04, Łukasz Moreń wrote:
> I've tried with JBoss AS transaction manager and JBossStandaloneTM.
> The result is this same in all cases - error during merge.
>
> 2009/8/12, Emmanuel Bernard <emmanuel(a)hibernate.org>:
>> Ok I understand better now.
>> Do your tests in JBoss AS with it's decent transaction manager
>> (infinispan should have a config for it)
>> For unit testing, force the indexing process in hibernate to use a
>> single thread (I ghnk it's possible ask Sanne of you don't know how).
>>
>> Exposing some configuration to infinispan makes sense. can you
>> start a
>> thread explainig what is configurable and which one you think we
>> should expose to hsearch users. Ideally I would like to offer one or
>> two defaut config scenarios and allow to fallback to a custom config.
>>
>> Emmanuel
>>
>> On 12 août 2009, at 11:58, Łukasz Moreń <lukasz.moren(a)gmail.com>
>> wrote:
>>
>>> Sorry, but my wifi does not work well today. I will try to explain
>>> it more clear.
>>>
>>> I'm using DummyTransactionManager available for Infinispan.
>>> It associates transaction with the calling thread.
>>>
>>> Steps to update index:
>>>
>>> 1. index writer acquires lock - begin of transaction
>>>
>>> 2. if it is necessary, index writer delegates new threads to do
>>> merge work.
>>> Those merge threads do not see changes made so far from begin of
>>> transaction,
>>> and are looking for segments which are not yet in index.
>>> Changes will be visible when AD.3 is completed.
>>> For tests i tried to commit transaction when merge starts and then
>>> everything worked well. But then i need to start it again.
>>>
>>> 3. index writer releases lock - transaction is commited, all changes
>>> made in this transaction are visible for other threads.
>>>
>>> Maybe using some other transaction manager could help?
>>>
>>> What about Infinispan cache configuration? Some configuration
>>> mechanism should be exposed to the user,
>>> or we can hardcoded one in InfinispanDirectoryProvider is enough?
>>>
>>>
>>>
>>>
>>> 2009/8/12 Emmanuel Bernard <emmanuel(a)hibernate.org>
>>> why?
>>> Emmanuel Bernard
>>> Pending
>>> you there?
>>> Emmanuel Bernard
>>> Pending
>>> Ok please describe in details what is going on. From what you are
>>> describing the tx cannot see all segments which looks like an
>>> infinispan bug to me.
>>> Pending
>>>
>>> As a back up you can try wo transaction and see if that works
>>> Emmanuel Bernard
>>> Pending
>>> technically the lucene index should cope with that
>>> Emmanuel Bernard
>>> 11:16
>>> but I like this approach less
>>>
>>>
>>>
>>> Let's try and chat by email IF I'm not online, I need to run on some
>>> errands today.
>>>
>>
16 years, 1 month
Data not replicated across the cluster: JBossStandaloneJTAManagerLookup
by Łukasz Moreń
Hi,
When I set up cluster with a number of caches and
use JBossStandaloneJTAManagerLookup as transaction manager it seems that
data is not replicated across the cluster.
With DummyTransactionManagerLookup everything is ok. I attached example test
which fails with JBossStandaloneJTAManagerLookup but finishes successfully
with DummyTransactionManagerLookup. I don't know if it is intentional
effect.
Cheers,
Lukasz Moren
16 years, 1 month
Updated design wiki for DIST
by Manik Surtani
Guys
I have updated the design wiki with stuff about distribution. This is
still phase 1 of the design docs: I have only used simple textual
bullet points to detail everything. Pictorial representations and
state diagrams coming up later this week. (I just think something as
important and complex as distribution needs to be very thoroughly
documented).
http://www.jboss.org/community/wiki/DIST-distributedcachemode
Let me know what you think!
Cheers
Manik
16 years, 1 month
Reply-to behavior
by Jeff Ramsdale
In the spirit of encouraging public discourse, could the reply-to behavior
of this list be to reply-to all rather than to the individual poster? If
this has been raised in the past I apologize...
-jeff
16 years, 1 month
[ISPN-6] [HHH-4103] Infinispan cache provider now in Hibernate trunk
by Galder Zamarreno
Hi all,
As indicated to Steve and Manik yesterday, I've committed the Infinispan
cache provider to Hibernate trunk and added the new module to the root
pom.xml.
The provider currently depends on a Infinispan snapshot in order to pass
all except the classloader tests which require more work on my side
(Note that I'm away on PTO next week and so I'll carry on with this when
I get back). The dependency on the snapshot is required in order to fix
some issues that we found in Infinispan as tests were ported from the
JBC integration layer.
Manik will be releasing a Beta1 release either today or Monday and that
should contain all the necessary fixes. So, when that release comes out,
could someone that has Hibernate trunk commit access change the
cache-infinispan/pom.xml to point to that version? That way Steve can
carry on with 3.5 releases knowing that Infinispan is tied to a specific
version and not a snapshot.
So, what is it that is left to do?
- Fix the classloader tests. This requires some thought cos we've moved
away from isolated regions to lazy marshalling. I need more time to look
into this.
- Benchmark against other cache providers, we must be faster! I sent an
email previously about this but got no reply, so I assume there's
nothing right now to benchmark cache providers?
- Document (wiki) how the cache provider works and its configuration.
- Blog about it! The next time a Hibernate 3.5 release is put out there,
this would be the ideal time to do so! Hopefully by then the docu/wiki
will be ready.
Note that the work done so far is not set in stone yet and any
suggestion/improvements to how the cache works or about the
configuration is welcomed. InfinispanRegionFactoryTestCase contains a
fair few tests where different configuration settings are tested. That
will give you an idea of the potential of the new configuration.
I've removed the beta1 fix version from
https://jira.jboss.org/jira/browse/ISPN-6 cos there's nothing specific
to the cache provider implemented for beta1 other than fixing the
corresponding issues and there're JIRAs for each of them already.
Finally, I'd like to thank breddy for stepping up and starting the
development of the cache provider.
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years, 1 month
[ISPN-6] Query cache region implementation, getting transaction manager?
by Galder Zamarreno
Hi,
I'm currently working on the query cache region and calling get() on
query cache region should suspend current transaction. With JBC, we used
to call the following to get the transaction manager:
cache.getConfiguration().getRuntimeConfig().getTransactionManager();
However, this API is not available in Infinispan. What should be the
correct way to get the transaction manager?
TestingUtil.geTransactionManager() includes a method to do so but I
don't think such method should be used for anything other than testing.
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years, 1 month
