March 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2813) DummyTransaction do not commit is last resource transaction is read-only

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2813?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-2813: ------------------------------------- as a workaround - use a proper TM such as JBossTM > DummyTransaction do not commit is last resource transaction is read-only > ------------------------------------------------------------------------ > > Key: ISPN-2813 > URL: https://issues.jboss.org/browse/ISPN-2813 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.1.6.FINAL > Reporter: Vitalii Tymchyshyn > Assignee: Mircea Markus > Priority: Minor > Fix For: 6.0.0.Final > > > Currently HEAD DummyTransaction.java has this code: > ... > for (XAResource res : resources) { > try { > int prepareStatus = res.prepare(xid); > transaction.setPrepareStatus(prepareStatus); > ... > This means that transaction gets prepare status of the last resource (cache in case of infinispan) enlisted. > Also it has next code: > ... > if (transaction.getPrepareStatus() == XAResource.XA_RDONLY) { > log.debug("This is a read-only tx"); > } else { > ... Do commit ... > ... > This means that if last resource returned XA_RDONLY (e.g. when on last cache only get was performed) all other resources are not committed. > For me this results in locks held indefinitely and transaction leak. > Correct would be to remember prepare status per-resource and act accordinly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2811) cassandraStore xml configuration gives parser error on attributes "username" and "password"

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2811?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2811: -------------------------------- Fix Version/s: 6.0.0.Final > cassandraStore xml configuration gives parser error on attributes "username" and "password" > ------------------------------------------------------------------------------------------- > > Key: ISPN-2811 > URL: https://issues.jboss.org/browse/ISPN-2811 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.0.Final > Reporter: Giovanni Mels > Assignee: Mircea Markus > Fix For: 6.0.0.Final > > > This is because attributes "username" and "password" are in uppercase in [org.infinispan.loaders.cassandra.configuration.Attribute|https://github.c...], but in lowercase in the [schema|http://docs.jboss.org/infinispan/schemas/infinispan-cachestore-cas...]. > {quote} > org.infinispan.config.ConfigurationException: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[37,142] > Message: Unexpected attribute 'password' encountered > at org.infinispan.configuration.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:76) > at org.infinispan.configuration.parsing.Parser52.parseCommonStoreAttributes(Parser52.java:696) > at org.infinispan.loaders.cassandra.configuration.CassandraCacheStoreConfigurationParser52.parseCassandraStoreAttributes(CassandraCacheStoreConfigurationParser52.java:180) > at org.infinispan.loaders.cassandra.configuration.CassandraCacheStoreConfigurationParser52.parseCassandraStore(CassandraCacheStoreConfigurationParser52.java:77) > at org.infinispan.loaders.cassandra.configuration.CassandraCacheStoreConfigurationParser52.readElement(CassandraCacheStoreConfigurationParser52.java:65) > at org.infinispan.loaders.cassandra.configuration.CassandraCacheStoreConfigurationParser52.readElement(CassandraCacheStoreConfigurationParser52.java:43) > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) > at org.infinispan.configuration.parsing.Parser52.parseLoaders(Parser52.java:588) > at org.infinispan.configuration.parsing.Parser52.parseCache(Parser52.java:180) > at org.infinispan.configuration.parsing.Parser52.parseDefaultCache(Parser52.java:145) > at org.infinispan.configuration.parsing.Parser52.readElement(Parser52.java:98) > at org.infinispan.configuration.parsing.Parser52.readElement(Parser52.java:75) > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) > at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:77) > ... 28 more > {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2813) DummyTransaction do not commit is last resource transaction is read-only

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2813?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2813: -------------------------------- Fix Version/s: 6.0.0.Final > DummyTransaction do not commit is last resource transaction is read-only > ------------------------------------------------------------------------ > > Key: ISPN-2813 > URL: https://issues.jboss.org/browse/ISPN-2813 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.1.6.FINAL > Reporter: Vitalii Tymchyshyn > Assignee: Mircea Markus > Priority: Critical > Fix For: 6.0.0.Final > > > Currently HEAD DummyTransaction.java has this code: > ... > for (XAResource res : resources) { > try { > int prepareStatus = res.prepare(xid); > transaction.setPrepareStatus(prepareStatus); > ... > This means that transaction gets prepare status of the last resource (cache in case of infinispan) enlisted. > Also it has next code: > ... > if (transaction.getPrepareStatus() == XAResource.XA_RDONLY) { > log.debug("This is a read-only tx"); > } else { > ... Do commit ... > ... > This means that if last resource returned XA_RDONLY (e.g. when on last cache only get was performed) all other resources are not committed. > For me this results in locks held indefinitely and transaction leak. > Correct would be to remember prepare status per-resource and act accordinly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2813) DummyTransaction do not commit is last resource transaction is read-only

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2813?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2813: -------------------------------- Priority: Minor (was: Critical) > DummyTransaction do not commit is last resource transaction is read-only > ------------------------------------------------------------------------ > > Key: ISPN-2813 > URL: https://issues.jboss.org/browse/ISPN-2813 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.1.6.FINAL > Reporter: Vitalii Tymchyshyn > Assignee: Mircea Markus > Priority: Minor > Fix For: 6.0.0.Final > > > Currently HEAD DummyTransaction.java has this code: > ... > for (XAResource res : resources) { > try { > int prepareStatus = res.prepare(xid); > transaction.setPrepareStatus(prepareStatus); > ... > This means that transaction gets prepare status of the last resource (cache in case of infinispan) enlisted. > Also it has next code: > ... > if (transaction.getPrepareStatus() == XAResource.XA_RDONLY) { > log.debug("This is a read-only tx"); > } else { > ... Do commit ... > ... > This means that if last resource returned XA_RDONLY (e.g. when on last cache only get was performed) all other resources are not committed. > For me this results in locks held indefinitely and transaction leak. > Correct would be to remember prepare status per-resource and act accordinly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2802) Cache recovery fails due to missing responses

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2802?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2802: -------------------------------- Fix Version/s: 5.3.0.Beta1 5.3.0.Final > Cache recovery fails due to missing responses > --------------------------------------------- > > Key: ISPN-2802 > URL: https://issues.jboss.org/browse/ISPN-2802 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.0.CR3 > Reporter: Radim Vansa > Assignee: Dan Berindei > Fix For: 5.3.0.Beta1, 5.3.0.Final > > > When the cache recovery is started, the new coordinator sends CacheTopologyControlCommand.GET_STATUS to all nodes and waits for responses. However, I have a reproducible test-case where it always times out waiting for the responses. > Here are the logs (TRACE is not doable here, but I added some byteman traces - see topology.btm in the archive): http://dl.dropbox.com/u/103079234/recovery.zip > The problematic spot is on node3 at 05:37:57 receiving cluster view 34. > All nodes (except the one which is killed, in this case node1) respond quickly to the GET_STATUS command (see BYTEMAN Receiving - Received pairs, these are bound to command execution in CommandAwareRpcDispatcher), but some responses are not received on node3 (look for Receiving rsp bound to GroupRequest). > JGroups tracing could be useful here but it is not available (intensive logging often blocks on internal log4j locks and the node becomes unresponsive). > As mentioned above, the case is reproducible, therefore if you can suggest any particular BYTEMAN hook, I can try it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2807) REST server war is missing configuration file config-samples/sample.xml

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2807?page=com.atlassian.jira.plugin.... ] Mircea Markus closed ISPN-2807. ------------------------------- Resolution: Duplicate Issue ISPN-2793 has been opened for the same reason. > REST server war is missing configuration file config-samples/sample.xml > ------------------------------------------------------------------------ > > Key: ISPN-2807 > URL: https://issues.jboss.org/browse/ISPN-2807 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.0.Final > Reporter: Adrian Nistor > Assignee: Tristan Tarrant > Fix For: 5.3.0.Alpha1 > > > config-samples/sample.xml is referenced in web.xml but is not present in classpath. > This file used to be located in older versions of infinispan-core.jar but the enitre config-samples dir was removed from it by ISPN-2560. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2793) REST Server WAR default config

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2793?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2793: -------------------------------- Fix Version/s: 6.0.0.Final > REST Server WAR default config > ------------------------------ > > Key: ISPN-2793 > URL: https://issues.jboss.org/browse/ISPN-2793 > Project: Infinispan > Issue Type: Feature Request > Components: Server > Affects Versions: 5.2.0.Final > Reporter: Michal Linhard > Assignee: Mircea Markus > Priority: Minor > Fix For: 6.0.0.Final > > > REST Server war file comes with this web.xml > {code} >  > <init-param> > <param-name>infinispan.config</param-name> > <param-value>config-samples/sample.xml</param-value> > </init-param> > {code} > that depend's on certain file to exist, otherwise the deployment will throw an exception: > {code} > 09:20:14,148 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/infinispan]] (MSC service thread 1-2) Servlet /infinispan threw load() exception: java.io.FileNotFoundException: config-samples/sample.xml (No such file or directory) > at java.io.FileInputStream.open(Native Method) [rt.jar:1.6.0_37] > at java.io.FileInputStream.<init>(FileInputStream.java:120) [rt.jar:1.6.0_37] > at java.io.FileInputStream.<init>(FileInputStream.java:79) [rt.jar:1.6.0_37] > at org.infinispan.util.AbstractFileLookup.lookupFileStrict(AbstractFileLookup.java:83) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT] > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:326) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT] > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:313) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT] > at org.infinispan.rest.StartupListener.init(StartupListener.scala:59) [classes:] > at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1202) [jbossweb-7.0.17.Final-redhat-1.jar:] > at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1102) [jbossweb-7.0.17.Final-redhat-1.jar:] > at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3655) [jbossweb-7.0.17.Final-redhat-1.jar:] > at org.apache.catalina.core.StandardContext.start(StandardContext.java:3873) [jbossweb-7.0.17.Final-redhat-1.jar:] > at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:89) [jboss-as-web-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37] > {code} > What about commenting this out, so that default config is used. > I'll do the pull if you agree.. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2799) Deprecated OverrideDefault annotation is the only way to prevent construction of the default CacheManager

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2799?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2799: -------------------------------- Fix Version/s: 6.0.0.Final > Deprecated OverrideDefault annotation is the only way to prevent construction of the default CacheManager > --------------------------------------------------------------------------------------------------------- > > Key: ISPN-2799 > URL: https://issues.jboss.org/browse/ISPN-2799 > Project: Infinispan > Issue Type: Bug > Components: CDI integration > Affects Versions: 5.2.0.Final > Reporter: Emond Papegaaij > Assignee: Pete Muir > Fix For: 6.0.0.Final > > > The signature of DefaultEmbeddedCacheManagerProducer.getDefaultEmbeddedCacheManager, with @OverrideDefault, causes the providedDefaultEmbeddedCacheManager to only be satisfied when your producer method is annotated with @OverrideDefault. > For example: > {code} > @Produces > @ApplicationScoped > @Default > @OverrideDefault > public EmbeddedCacheManager defaultEmbeddedCacheManager() { > return new DefaultCacheManager( > new GlobalConfigurationBuilder() > .globalJmxStatistics().allowDuplicateDomains(true) > .cacheManagerName("CDICacheManager").enable().build(), > new ConfigurationBuilder().jmxStatistics().disable() > .eviction().strategy(EvictionStrategy.LRU) > .maxEntries(10000).build()); > } > {code} > If I remove @OverrideDefault, my CacheManager is still used as the default CacheManager, but the CacheManager from DefaultEmbeddedCacheManagerProducer is also instantiated. This happens because DefaultCacheResolver iterates over all EmbeddedCacheManagers to check if one of them contains a specific cache. > The default CacheManager is giving me problems because it conflicts with another CacheManager (probably from JBoss AS) in JMX. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2860) RHQ plugin breaks when monitoring within AS7.1 / EAP6.0

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2860?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2860: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 915789|https://bugzilla.redhat.com/show_bug.cgi?id=915789] from NEW to ON_QA > RHQ plugin breaks when monitoring within AS7.1 / EAP6.0 > ------------------------------------------------------- > > Key: ISPN-2860 > URL: https://issues.jboss.org/browse/ISPN-2860 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 5.2.2.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Critical > Labels: 5.2.x > Fix For: 5.2.3.Final, 5.3.0.Final > > > Because of a bug in AS7.1 / EAP 6.0 (AS7-5794), JMX queries return incompatible objects and cause errors within the RHQ plugin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2846) OperationsDuringStateTransferTest fails if run on non-tx cache

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2846?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-2846: ---------------------------------- Fix Version/s: 5.2.3.Final > OperationsDuringStateTransferTest fails if run on non-tx cache > -------------------------------------------------------------- > > Key: ISPN-2846 > URL: https://issues.jboss.org/browse/ISPN-2846 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache, State transfer > Affects Versions: 5.2.2.Final, 5.3.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 5.2.x > Fix For: 5.2.3.Final, 5.3.0.Final > > > This is a consequence of ISPN-2688 being fixed only for TX case. > The non-tx case is not solved and this test fails if OperationsDuringStateTransferTest.isTransactional is changed to false. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2013