Re: [infinispan-dev] [JBoss JIRA] Resolved: (ISPN-154) DefaultCacheManager should validate XML configurations by default
by Galder Zamarreno
Vladimir,
If validation is turned off, it shouldn't even bother looking up the
xsd. Currently, for some unknown reason, mvn install does not seem to
include the xsd in schema/ folder within infinispan-core.jar and even
disabling validation does not work cos the xsd is still looked up.
Could you have a look to this?
I'm redoing mvn install to verify whether the xsd is included.
Cheers,
On 08/13/2009 01:53 PM, Vladimir Blagojevic (JIRA) wrote:
> [ https://jira.jboss.org/jira/browse/ISPN-154?page=com.atlassian.jira.plugi... ]
>
> Vladimir Blagojevic resolved ISPN-154.
> --------------------------------------
>
> Resolution: Done
>
>
> Resolved. Validation is by default turned on. It can be turned off by passing -D"infinispan.config.validate"=false JVM parameter
>
>> DefaultCacheManager should validate XML configurations by default
>> -----------------------------------------------------------------
>>
>> Key: ISPN-154
>> URL: https://jira.jboss.org/jira/browse/ISPN-154
>> Project: Infinispan
>> Issue Type: Bug
>> Components: Configuration
>> Affects Versions: 4.0.0.ALPHA6
>> Reporter: Galder Zamarreno
>> Assignee: Vladimir Blagojevic
>> Fix For: 4.0.0.BETA1
>>
>>
>> DefaultCacheManager(InputStream configurationStream, boolean start) should by default be creating an infinispan configuration passing an xsd schema so that configuration validation occurrs:
>> public DefaultCacheManager(InputStream configurationStream, boolean start) throws IOException {
>> try {
>> initialize(InfinispanConfiguration.newInfinispanConfiguration(configurationStream));
>
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years, 1 month
test suite status
by Mircea Markus
Hi there,
Here is a how things are with hudson tests:
- hudson user still cannot bind to UDP, so we're using TCP+TCPPING.
There are two tests that check that in the class named:
TcpMPingEnvironmentTest.
- I've found a workaround for the SingleStore test (one in which
coordinators were stopped): I've increased the TCPPING.port_range to 5
and that sorted the problem.
- S3 cache stores failures were fixed - Adrian if you can take a look
would be great
- other intermittent failures were fixed
Besides the 2 failures in TcpMPingEnvironmentTest, there are other 6:
- 3 failures in TableNameUniquenessTest - caused by xsd missing from
the path
- CacheManagerXmlConfigurationTest-
testNamedCacheXMLClashingNamesProgrammatic
- CacheManagerXmlConfigurationTest-testNamedCacheXML
- XmlFileParsingTest-testNamedCacheFileJaxb
All above 5 are failing with the same missing xsd error. Vladimir,
would it be possible for you to take a look at the 6 failure above?
So, on the short, besides the 6 'missing xsd file' errors we have a
stable suite.
Cheers,
Mircea
16 years, 1 month
Unnecessarikly verbose exceptions: DeadlockDetectingInterceptor
by Manik Surtani
Guys,
I see this coming up when I run the test suite quite often, even on
tests that should not be exercising this code:
2009-08-13 15:53:29,188 ERROR [InvocationContextInterceptor]
(PerCacheExecutorThread-1) Execution error:
org.infinispan.util.concurrent.locks.DeadlockDetectedException:
Deadlock request was detected for locally originated tx
DummyTransaction{xid=DummyXid{id=70}, status=1}; it was marked for
rollback
at
org
.infinispan
.interceptors
.DeadlockDetectingInterceptor
.handleDataCommand(DeadlockDetectingInterceptor.java:80)
at
org
.infinispan
.interceptors
.DeadlockDetectingInterceptor
.visitPutKeyValueCommand(DeadlockDetectingInterceptor.java:98)
at
org
.infinispan
.commands
.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
at
org
.infinispan
.interceptors
.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:
118)
at
org
.infinispan
.interceptors
.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
at
org
.infinispan
.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:
57)
at
org
.infinispan
.commands
.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
at
org
.infinispan
.interceptors
.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:
118)
at
org
.infinispan
.interceptors
.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:185)
at
org
.infinispan
.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:
127)
at
org
.infinispan
.commands
.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
at
org
.infinispan
.interceptors
.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:
118)
at
org
.infinispan
.interceptors
.InvocationContextInterceptor
.handleAll(InvocationContextInterceptor.java:48)
at
org
.infinispan
.interceptors
.InvocationContextInterceptor
.handleDefault(InvocationContextInterceptor.java:34)
at
org
.infinispan
.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:
57)
at
org
.infinispan
.commands
.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
at
org
.infinispan
.interceptors
.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:
118)
at org.infinispan.tx.AsyncDeadlockDetectionTest
$
RemoteReplicationInterceptor
.handleDefault(AsyncDeadlockDetectionTest.java:160)
at
org
.infinispan
.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:
57)
at
org
.infinispan
.commands
.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
at
org
.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:
237)
at org.infinispan.CacheDelegate.put(CacheDelegate.java:326)
at org.infinispan.CacheDelegate.put(CacheDelegate.java:544)
at org.infinispan.CacheDelegate.put(CacheDelegate.java:179)
at
org
.infinispan
.test.PerCacheExecutorThread.run(PerCacheExecutorThread.java:98)
[pool-1-thread-6] Test
simpleReplicationTest
(org.infinispan.replication.SyncCacheListenerTest) succeeded.
Is this a little too alarming? It seems to happen on any thread
interrupt (see DeadlockDetectingInterceptor [1], lines 67 - 92).
There are often legitimate reasons for a thread to be interrupted
(e.g., a server being shut down). So throwing this exception every
time can be pretty scary. Perhaps this should be on INFO or DEBUG
level?
Cheers
Manik
[1] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i...
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
16 years, 1 month
XML config validation not happening?
by Galder Zamarreno
Hi Vladimir,
Is there any xsd validation happening in the XML configuration
processing in Infinispan trunk? The reason I'm asking is by mistake, my
sample 2nd level cache definitions where using "invalidation" and "REPL"
as cache modes, and these are not valid cache modes as per
infinispan-config-4.0.xsd.
However Infinispan, rather than barfing something saying that the
configuration is incorrect, it set the incorrect cache modes to null
hence causing other issues.
Any chance of adding/enabling some validation? Or has this been disabled
until you've done some further work?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years, 1 month
configure log for a module
by Mircea Markus
any idea how can I configure logging for an certain module? i.e. I'm
in cachestore/jdbc and running mvn test - > which log4j.xml is used in
this case.
Cheers,
Mircea
16 years, 1 month
Removing old configuration parsers
by Vladimir Blagojevic
I will remove all configuration processing classes (about 14 java files)
unrelated to JAXB parsing tomorrow morning. If you have something
against it - speak up now.
I will still keep our annotation classes until I figure out how to
create config reference by relying only on JAXB annotations and javadoc.
Cheers.
16 years, 1 month
3 XmlConfigurationParser implementations, which one to use?
by Galder Zamarreno
Hi,
There's a bit of a mess now with regards to XmlConfigurationParser
implementations. There're now 3 of them:
AutomatedXmlConfigurationParserImpl
InfinispanConfiguration
XmlConfigurationParserImpl
Which one should we be using to parse XML configuration files from unit
tests?
The reason I'm asking is because parsing via InfinispanConfiguration
returns different results to parsing via previous
XmlConfigurationParserImpl.
For example: If XmlConfigurationParserImpl found a transport element but
transport class, it gave JGroupsTransport as default, hence a cluster
channel would be created. However, parsing via InfinispanConfiguration,
if no transportClass has been defined, no cluster channel is created.
We need to keep one and deprecate the others making sure we note things
like this, i.e. if no transport class is defined, by default we use
JGroupsTransport (something which IMO makes a lot of sense)
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years, 1 month
Configuration.clone
by Mircea Markus
Hi,
Configuration.clone is implemented with object serialization. AFAIK this
is not a good practice for several reasons, one of them is that all the
objects aggregated by Configuration must be serializable. While this
*might* be ok for Configuration elements within our scope (infinispan)
this will unnecessarily enforce the extensions (e.g.
<aCustomCacheStore>Configuration) to be serializable.
Cheers,
Mircea
16 years, 1 month
test suite hanging
by Mircea Markus
Hi there,
org.infinispan.container.FIFODataContainerTest.testMultithreadAccess
is causing the test suite to hang. It happened on my mac and on hudson
as well.
Is this something you can look into?
I've disabled the test.
Cheers,
Mircea
16 years, 1 month
JBoss Marshalling 1.2.0.CR3 released
by David M. Lloyd
JBoss Marshalling 1.2.0.CR3 has been released. It should be showing up in
Maven shortly. I've cleaned up the test suite and made sure that all the
known problems have JIRA issues associated with them. If you guys run
across any more problems (or better yet, run across fixes for them :), be
sure to post a bug at https://jira.jboss.org/jira/browse/JBMAR and I'll
make sure it gets looked at before 1.2.0.GA.
Have fun!
- DML
16 years, 1 month
