[JBoss JIRA] (ISPN-3048) Eviction needs to be transactional
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3048?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3048:
------------------------------------
[~pferraro] I agree with Pedro, eviction should not be transactional. If you have a test that fails with size-based eviction, please attach it here. Note that by enabling size-based eviction without passivation, you agree that your data can be lost at any time, and if your isolation level is READ_COMMITTED, even ongoing transactions can see the entry as removed.
[~pruivo] I don't think this is related to ISPN-3694, Paul's problem is with size-based eviction, and the problem Will found is only with manual eviction.
> Eviction needs to be transactional
> ----------------------------------
>
> Key: ISPN-3048
> URL: https://issues.jboss.org/browse/ISPN-3048
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.3.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.1.0.Final
>
>
> Currently, Infinispan eviction is non-transactional. This makes Infinispan's eviction manager virtually unusable, since non-transactional eviction can cause phantom reads and data loss because it violates the isolation of concurrent transactions. This is especially problematic when using a passivation-enabled cache store. In this case, a cache eviction/passivation can cause a concurrently executed cache retrieval to return null - even though the act of passivation does not change the data - it only changes where it is stored.
> We work around this in the AS by performing eviction manually, using pessimistic locking in combination with eager lock acquisition prior to eviction. This is unfortunate, since it prevents me from leveraging Infinispan's build-in eviction strategies.
--
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, 1 month
[JBoss JIRA] (ISPN-3723) REST RollUps from 5.2.4 to 6.0.0 -- migrates 0 entries (probably due to PersistenceException)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3723?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3723:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1031656|https://bugzilla.redhat.com/show_bug.cgi?id=1031656] from NEW to ASSIGNED
> REST RollUps from 5.2.4 to 6.0.0 -- migrates 0 entries (probably due to PersistenceException)
> ---------------------------------------------------------------------------------------------
>
> Key: ISPN-3723
> URL: https://issues.jboss.org/browse/ISPN-3723
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.CR1
> Reporter: Tomas Sykora
> Assignee: Mircea Markus
> Attachments: restRollUpsPersistenceExceptionCantMigrate
>
>
> Trying to process REST rolling upgrades using latest infinispan server 6.0.0 snapshot as a TARGET node and old 5.2.4 server as a source node.
> 20 entries stored on source node successfully,
> recordKnownGlobalKeySet does not nothing (this is ok) REST is able to provide full key set
> but then,
> operation "synchronizeData" using "rest" issued on new node is returning:
> 14:05:23,252 INFO [org.infinispan.upgrade.RollingUpgradeManager] (pool-1-thread-1) ISPN000216: 0 entries migrated to cache default in 30 milliseconds
> however, there is 20 entries stored in the old node.
> Please see attached file for more detailed stack trace.
--
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, 1 month
[JBoss JIRA] (ISPN-3754) Tests for REST security must use cache-container with caches defined
by Martin Gencur (JIRA)
Martin Gencur created ISPN-3754:
-----------------------------------
Summary: Tests for REST security must use cache-container with caches defined
Key: ISPN-3754
URL: https://issues.jboss.org/browse/ISPN-3754
Project: Infinispan
Issue Type: Bug
Affects Versions: 6.0.0.Final
Reporter: Martin Gencur
Assignee: Vitalii Chepeliuk
Currently, the tests fail with this exception:
{code}
10:47:01,208 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.endpoint.websocket.websocket-connector: org.jboss.msc.service.StartException in service jboss.endpoint.websocket.websocket-connector: JDGS010004: Failed to start WebSocketServer
at org.infinispan.server.endpoint.subsystem.ProtocolServerService.start(ProtocolServerService.java:113)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
Caused by: java.lang.NullPointerException
at org.infinispan.commons.equivalence.AnyEquivalence.hashCode(AnyEquivalence.java:35)
at org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8.get(EquivalentConcurrentHashMapV8.java:954)
at org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8.containsKey(EquivalentConcurrentHashMapV8.java:982)
at org.infinispan.manager.DefaultCacheManager.cacheExists(DefaultCacheManager.java:401)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:406)
at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89)
at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80)
at org.infinispan.server.core.AbstractProtocolServer.startDefaultCache(AbstractProtocolServer.scala:120)
at org.infinispan.server.core.AbstractProtocolServer.startInternal(AbstractProtocolServer.scala:37)
at org.infinispan.server.websocket.WebSocketServer.startInternal(WebSocketServer.java:57)
at org.infinispan.server.core.AbstractProtocolServer.start(AbstractProtocolServer.scala:44)
at org.infinispan.server.endpoint.subsystem.ProtocolServerService.startProtocolServer(ProtocolServerService.java:130)
at org.infinispan.server.endpoint.subsystem.ProtocolServerService.start(ProtocolServerService.java:107)
... 5 more
{code}
This is caused by the fact that REST security tests define endpoints which use "security" container. However, this container does not have any caches defined.
--
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, 1 month
[JBoss JIRA] (ISPN-3753) Unable to build ISPN server test suite
by Martin Gencur (JIRA)
Martin Gencur created ISPN-3753:
-----------------------------------
Summary: Unable to build ISPN server test suite
Key: ISPN-3753
URL: https://issues.jboss.org/browse/ISPN-3753
Project: Infinispan
Issue Type: Bug
Affects Versions: 6.0.0.Final
Reporter: Martin Gencur
Assignee: Martin Gencur
I get this exception when trying to build/run the test suite:
[ERROR] Failed to execute goal on project test-suite: Could not resolve dependencies for project org.infinispan.server:test-suite:jar:6.0.1-SNAPSHOT: Failure to find javax.transaction:jta:jar:1.0.1B in https://repository.jboss.org/nexus/content/groups/developer/ was cached in the local repository, resolution will not be reattempted until the update interval of jboss-developer-repository-group has elapsed or updates are forced -> [Help 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
11 years, 1 month