[JBoss JIRA] (ISPN-3496) Infinispan library breaks Hibernate 2LC with java.lang.ClassCastException: org.infinispan.remoting.ReplicationQueueImpl cannot be cast to org.infinispan.remoting.ReplicationQueue
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3496?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-3496:
--------------------------------
Labels: 620 (was: jdg62blocker)
> Infinispan library breaks Hibernate 2LC with java.lang.ClassCastException: org.infinispan.remoting.ReplicationQueueImpl cannot be cast to org.infinispan.remoting.ReplicationQueue
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3496
> URL: https://issues.jboss.org/browse/ISPN-3496
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.1.Final
> Environment: EAP 6.1.0 and 6.1.1. This is a regression since EAP 6.0.1
> Reporter: Martin Gencur
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 5.2.8.Final
>
>
> A WAR deployment containing its own infinispan (such as JDG helloworld quickstart) and also having persistence.xml with second level cache enabled fails to deploy on EAP 6.1 HA configuration (standalone-ha.xml or standalone-full-ha.xml)
> Version-Release number of selected component (if applicable):
> EAP 6.1.0, EAP 6.1.1.ER4.
> Note: This does not happen with EAP 6.0.1 so it's a regression.
> Steps to Reproduce:
> 1. Get JDG 6.1 helloworld-jdg quickstart (or see the attachment)
> 2. Add persistence.xml with 2lc, e.g.:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence xmlns="http://java.sun.com/xml/ns/persistence"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
> version="2.0">
> <persistence-unit name="entityManager">
> <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
> <properties>
> <property name="hibernate.hbm2ddl.auto" value="create-drop"/>
> <property name="hibernate.cache.use_second_level_cache" value="true"/>
> <property name="hibernate.cache.use_query_cache" value="true"/>
> </properties>
> </persistence-unit>
> </persistence>
> {code}
> 3. deploy the helloworld-jdg on standalone-ha.xml or standalone-full-ha.xml configuration of EAP 6.1.
> This happens also when standalone.xml file is used to start EAP.
> The resulting error:
> {code}
> 10:26:20,759 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 53) MSC000001: Failed to start service jboss.persistenceunit."jboss-as-helloworld-jdg.war#entityManager": org.jboss.msc.service.StartException in service jboss.persistenceunit."jboss-as-helloworld-jdg.war#entityManager": javax.persistence.PersistenceException: [PersistenceUnit: entityManager] Unable to build EntityManagerFactory
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:103)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
> Caused by: javax.persistence.PersistenceException: [PersistenceUnit: entityManager] Unable to build EntityManagerFactory
> at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:930)
> at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:904)
> at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:92)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:200)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.access$600(PersistenceUnitServiceImpl.java:57)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:99)
> ... 4 more
> Caused by: org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.spi.CacheImplementor]
> at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:186)
> at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:150)
> at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:264)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1762)
> at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:94)
> at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:920)
> ... 9 more
> Caused by: org.hibernate.cache.CacheException: Unable to start region factory
> at org.hibernate.cache.infinispan.InfinispanRegionFactory.start(InfinispanRegionFactory.java:323)
> at org.hibernate.internal.CacheImpl.<init>(CacheImpl.java:70)
> at org.hibernate.engine.spi.CacheInitiator.initiateService(CacheInitiator.java:40)
> at org.hibernate.engine.spi.CacheInitiator.initiateService(CacheInitiator.java:35)
> at org.hibernate.service.internal.SessionFactoryServiceRegistryImpl.initiateService(SessionFactoryServiceRegistryImpl.java:91)
> at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:176)
> ... 15 more
> Caused by: java.lang.ClassCastException: org.infinispan.remoting.ReplicationQueueImpl cannot be cast to org.infinispan.remoting.ReplicationQueue
> at org.infinispan.configuration.cache.LegacyConfigurationAdaptor.adapt(LegacyConfigurationAdaptor.java:306)
> at org.infinispan.manager.DefaultCacheManager.defineConfiguration(DefaultCacheManager.java:468)
> at org.infinispan.manager.DefaultCacheManager.defineConfiguration(DefaultCacheManager.java:443)
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.defineConfiguration(DefaultEmbeddedCacheManager.java:77)
> at org.hibernate.cache.infinispan.InfinispanRegionFactory.defineGenericDataTypeCacheConfigurations(InfinispanRegionFactory.java:492)
> at org.hibernate.cache.infinispan.InfinispanRegionFactory.start(InfinispanRegionFactory.java:318)
> ... 20 more
> 10:26:20,968 ERROR [org.jboss.as.server] (management-handler-thread - 4) JBAS015870: Deploy of deployment "jboss-as-helloworld-jdg.war" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jboss-as-helloworld-jdg.war#entityManager\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jboss-as-helloworld-jdg.war#entityManager\": javax.persistence.PersistenceException: [PersistenceUnit: entityManager] Unable to build EntityManagerFactory
> Caused by: javax.persistence.PersistenceException: [PersistenceUnit: entityManager] Unable to build EntityManagerFactory
> Caused by: org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.spi.CacheImplementor]
> Caused by: org.hibernate.cache.CacheException: Unable to start region factory
> Caused by: java.lang.ClassCastException: org.infinispan.remoting.ReplicationQueueImpl cannot be cast to org.infinispan.remoting.ReplicationQueue"}}
> {code}
--
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
12 years, 5 months
[JBoss JIRA] (ISPN-3497) getCountRowsSql() has wrong SQL syntax
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3497?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-3497:
--------------------------------
Labels: 620 (was: jdg62blocker)
> getCountRowsSql() has wrong SQL syntax
> --------------------------------------
>
> Key: ISPN-3497
> URL: https://issues.jboss.org/browse/ISPN-3497
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Alpha4
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Labels: 620
> Fix For: 6.0.0.Beta2
>
>
> When I run tests with mysql database following exception is thrown
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '*) FROM `mix_str____defaultcache`' at line 1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
> at com.mysql.jdbc.Util.getInstance(Util.java:386)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1053)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4120)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4052)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2503)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2664)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2794)
> at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2155)
> at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2322)
> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:462)
> at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedStore.size(JdbcStringBasedStore.java:358)
> {code:title=TableManipulation.java|borderStyle=solid}
> public String getCountRowsSql() {
> if (countRowsSql == null) {
> countRowsSql = "SELECT COUNT (*) FROM " + getTableName(); <<< here should be COUNT(*) without space
> }
> return countRowsSql;
> }
> {code}
> MySQL is complaining when there is SPACE between COUNT and (*)
> >[Error] Script lines: 5-6 --------------------------
> You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '*) FROM `edg_string____defaultcache`' at line 1
--
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
12 years, 5 months
[JBoss JIRA] (ISPN-3504) LevelDB Cache store in server doesn't keep data between restarts
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3504?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-3504:
--------------------------------
Labels: 620 (was: jdg62blocker)
> LevelDB Cache store in server doesn't keep data between restarts
> ----------------------------------------------------------------
>
> Key: ISPN-3504
> URL: https://issues.jboss.org/browse/ISPN-3504
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Alpha4
> Reporter: Michal Linhard
> Assignee: Tristan Tarrant
> Labels: 620
> Fix For: 6.0.0.Beta2
>
>
> I have config with passivation="false" purge="false"
> and expect data to survive restarts which doesn't happen.
> {code}
> <cache-container name="default" default-cache="default"
> listener-executor="infinispan-listener">
> <local-cache name="default" start="EAGER" batching="false">
> <locking isolation="REPEATABLE_READ" acquire-timeout="20000"
> concurrency-level="500" striping="false" />
> <transaction mode="NONE" />
> <leveldb-store path="temp-leveldb" block-size="1024"
> cache-size="50000" clear-threshold="100000" passivation="false"
> purge="false" >
> <expiration path="temp-leveldb-expired" queue-size="2000" />
> <compression type="SNAPPY" />
> <implementation type="JAVA" />
> </leveldb-store>
> </local-cache>
> <local-cache name="memcachedCache" start="EAGER" batching="false">
> <locking isolation="REPEATABLE_READ" acquire-timeout="20000"
> concurrency-level="500" striping="false" />
> <transaction mode="NONE" />
> </local-cache>
> </cache-container>
> {code}
> failing test:
> https://code.engineering.redhat.com/gerrit/gitweb?p=jdg-functional-tests....;
> hb=8e1b8a10fed5de5bf3bb9ec6fbc46857e1666798
> for JDG 6.2.0.DR4
--
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
12 years, 5 months
[JBoss JIRA] (ISPN-3600) ignorePreviousValue should not be set on non-origin nodes
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3600?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-3600:
--------------------------------
Labels: 620 (was: jdg62blocker)
> ignorePreviousValue should not be set on non-origin nodes
> ---------------------------------------------------------
>
> Key: ISPN-3600
> URL: https://issues.jboss.org/browse/ISPN-3600
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer, Transactions
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> In {{TxDistributionInterceptor.visit(Replace|Remove)Command}} the ignorePreviousValue flag is set to false on nodes which are not executing the transaction. Usually this does not matter, but when some other node requests transactions from this node (during ST), the Remove and Replace commands are sent with this flag set to false, which results in skipping their execution.
> Note: the overall behaviour with ignoring the command when this flag is false and origin is not local seems to me as abusing it - the semantics of the command is far from obvious. When the non-origin node receives the exact command that is executed on the original node (without ignorePreviousValue set to true), it simply ignores 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
12 years, 5 months
[JBoss JIRA] (ISPN-3617) Inconsistent L1 in non-tx distributed cache
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3617?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-3617:
--------------------------------
Labels: 620 (was: jdg62blocker)
> Inconsistent L1 in non-tx distributed cache
> -------------------------------------------
>
> Key: ISPN-3617
> URL: https://issues.jboss.org/browse/ISPN-3617
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.7.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> When the change is replicated to backup owner, it sends the InvalidateL1Command to backup owners before committing the entry in EntryWrappingInterceptor (it performs the WriteCommand in parallel with sending the invalidation commmand, but then it waits until the invalidation request gets acked. If a GET is executed between the invalidation and committing the entry, the response contains outdated result and the L1 will not be invalidated until next write operation.
--
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
12 years, 5 months
[JBoss JIRA] (ISPN-3603) Conditional command is committed on originator when it fails on primary owner
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3603?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-3603:
--------------------------------
Labels: 620 (was: jdg62blocker)
> Conditional command is committed on originator when it fails on primary owner
> -----------------------------------------------------------------------------
>
> Key: ISPN-3603
> URL: https://issues.jboss.org/browse/ISPN-3603
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> In non-tx cache, when conditional command (e.g. ReplaceCommand) fails on primary owner because the old value is not equal to current value, the NonTxDistributionInterceptor.visitReplaceCommand returns false but the entry is committed in EntryWrappingInterceptor anyway.
> Speaking about EntryWrappingInterceptor.invokeNextAndApplyChanges: NonTxDistributionInterceptor does not mark the command as unsuccessful if it fails on the primary owner, therefore, checking for command.isSuccessful() in order to retry the command upon topology change may seem insufficient.
--
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
12 years, 5 months
[JBoss JIRA] (ISPN-3635) Out of data read after write on node losing ownership
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3635?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-3635:
--------------------------------
Labels: 620 (was: jdg62blocker)
> Out of data read after write on node losing ownership
> -----------------------------------------------------
>
> Key: ISPN-3635
> URL: https://issues.jboss.org/browse/ISPN-3635
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, State transfer
> Affects Versions: 5.3.0.Final
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> In a situation where a node is losing ownership of an entry (during a state transfer), when the node does a write (and commits that), the change is propagated only to the new owners, the entry is not written locally. However, when it executes read for this key afterwards, it gets the old value as this is directly retrieved from the data container.
> This bug was observed in transactional mode, but might not be limited to 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
12 years, 5 months
[JBoss JIRA] (ISPN-2342) The x-site implementation needs an inter-site state transfer mechanism
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-2342?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-2342:
------------------------------
Labels: (was: jdg62)
> The x-site implementation needs an inter-site state transfer mechanism
> ----------------------------------------------------------------------
>
> Key: ISPN-2342
> URL: https://issues.jboss.org/browse/ISPN-2342
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cross-Site Replication
> Reporter: Erik Salter
> Assignee: Erik Salter
>
> To bring up a new site or recover a failed site, I need an inter-site state transfer mechanism for synchronizing keys.
> Note that initially, this should a manual process that is invoked on one site to one of its configured backups.
> This should be based on the non-blocking state transfer mechanism for consistency.
> The pseudo-design may look similar to the following:
> - Manually invokable, background thread
> - Since the bridge end is open, there are writes happening to keys. Keep track of the puts/removes on the main data owner.
> - Iterate through the key set.
> - If the key has already been modified since the process started, discard.
> - Else synchronously write the key value in a TX context
--
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
12 years, 5 months