[JBoss JIRA] (ISPN-3044) Add missing server schema files
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-3044:
-------------------------------------
Summary: Add missing server schema files
Key: ISPN-3044
URL: https://issues.jboss.org/browse/ISPN-3044
Project: Infinispan
Issue Type: Task
Components: Server
Affects Versions: 5.3.0.Alpha1
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 5.3.0.Beta1
The server schema files included in the server distribution are not aligned with the AS7.2 base
--
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
[JBoss JIRA] (ISPN-2903) Manual eviction should not delete entry from cache store
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2903:
-----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549] from MODIFIED to POST
> Manual eviction should not delete entry from cache store
> --------------------------------------------------------
>
> Key: ISPN-2903
> URL: https://issues.jboss.org/browse/ISPN-2903
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.2.3.Final
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 5.2.x, jdg6
> Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log
>
>
> Here's the scenario:
> Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7).
> 1. Create cache entry containing atomic map with 2 map entries on node1.
> 2. Passivate that cache entry on node2 via manual evict.
> 3. Modify 1 of the atomic map entries within the cache entry on node1.
> 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost.
> It's a side effect of ISPN-2384, where some changes were made to tighten the passivation/activation scenarios, but it did not cover manual eviction calls.
--
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
[JBoss JIRA] (ISPN-2903) Manual eviction should not delete entry from cache store
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2903:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> made a comment on [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549]
Finally...
https://github.com/jbossas/jboss-eap/pull/122
> Manual eviction should not delete entry from cache store
> --------------------------------------------------------
>
> Key: ISPN-2903
> URL: https://issues.jboss.org/browse/ISPN-2903
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.2.3.Final
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 5.2.x, jdg6
> Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log
>
>
> Here's the scenario:
> Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7).
> 1. Create cache entry containing atomic map with 2 map entries on node1.
> 2. Passivate that cache entry on node2 via manual evict.
> 3. Modify 1 of the atomic map entries within the cache entry on node1.
> 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost.
> It's a side effect of ISPN-2384, where some changes were made to tighten the passivation/activation scenarios, but it did not cover manual eviction calls.
--
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
[JBoss JIRA] (ISPN-2903) Manual eviction should not delete entry from cache store
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2903:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549] from ASSIGNED to MODIFIED
> Manual eviction should not delete entry from cache store
> --------------------------------------------------------
>
> Key: ISPN-2903
> URL: https://issues.jboss.org/browse/ISPN-2903
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.2.3.Final
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 5.2.x, jdg6
> Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log
>
>
> Here's the scenario:
> Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7).
> 1. Create cache entry containing atomic map with 2 map entries on node1.
> 2. Passivate that cache entry on node2 via manual evict.
> 3. Modify 1 of the atomic map entries within the cache entry on node1.
> 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost.
> It's a side effect of ISPN-2384, where some changes were made to tighten the passivation/activation scenarios, but it did not cover manual eviction calls.
--
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
[JBoss JIRA] (ISPN-2903) Manual eviction should not delete entry from cache store
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2903:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> made a comment on [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549]
Quick status update: I've finally managed to reproduce the issue locally. I'm still isolating the exact cause.
> Manual eviction should not delete entry from cache store
> --------------------------------------------------------
>
> Key: ISPN-2903
> URL: https://issues.jboss.org/browse/ISPN-2903
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.2.3.Final
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 5.2.x, jdg6
> Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log
>
>
> Here's the scenario:
> Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7).
> 1. Create cache entry containing atomic map with 2 map entries on node1.
> 2. Passivate that cache entry on node2 via manual evict.
> 3. Modify 1 of the atomic map entries within the cache entry on node1.
> 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost.
> It's a side effect of ISPN-2384, where some changes were made to tighten the passivation/activation scenarios, but it did not cover manual eviction calls.
--
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
[JBoss JIRA] (ISPN-470) Native Hot Rod client for C++
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-470?page=com.atlassian.jira.plugin.s... ]
Mircea Markus updated ISPN-470:
-------------------------------
Environment:
Minimal: Windows, 64-bit, Visual Studio 2010* RHEL 6, 64-bit
If possible: Windows, 32-bit, Visual Studio 2010* RHEL 5, 64-bit
> Native Hot Rod client for C++
> -----------------------------
>
> Key: ISPN-470
> URL: https://issues.jboss.org/browse/ISPN-470
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote protocols
> Environment: Minimal: Windows, 64-bit, Visual Studio 2010* RHEL 6, 64-bit
> If possible: Windows, 32-bit, Visual Studio 2010* RHEL 5, 64-bit
> Reporter: Manik Surtani
> Fix For: 6.0.0.Final
>
>
> C++ client impl for HotRod. Protocol is documented here:
> http://community.jboss.org/wiki/HotRodProtocol
> Could be based off the Java reference impl client:
> https://github.com/infinispan/infinispan/tree/master/client/hotrod-client
--
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
[JBoss JIRA] (ISPN-470) Native Hot Rod client for C++
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-470?page=com.atlassian.jira.plugin.s... ]
Mircea Markus updated ISPN-470:
-------------------------------
Environment:
Minimal: Windows, 64-bit, Visual Studio 2010* RHEL 6, 64-bit
Optional: Windows, 32-bit, Visual Studio 2010* RHEL 5, 64-bit
was:
Minimal: Windows, 64-bit, Visual Studio 2010* RHEL 6, 64-bit
If possible: Windows, 32-bit, Visual Studio 2010* RHEL 5, 64-bit
> Native Hot Rod client for C++
> -----------------------------
>
> Key: ISPN-470
> URL: https://issues.jboss.org/browse/ISPN-470
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote protocols
> Environment: Minimal: Windows, 64-bit, Visual Studio 2010* RHEL 6, 64-bit
> Optional: Windows, 32-bit, Visual Studio 2010* RHEL 5, 64-bit
> Reporter: Manik Surtani
> Fix For: 6.0.0.Final
>
>
> C++ client impl for HotRod. Protocol is documented here:
> http://community.jboss.org/wiki/HotRodProtocol
> Could be based off the Java reference impl client:
> https://github.com/infinispan/infinispan/tree/master/client/hotrod-client
--
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
[JBoss JIRA] (ISPN-3043) Make the sync RPCs over the bridge use the OOB thread pool
by Mircea Markus (JIRA)
Mircea Markus created ISPN-3043:
-----------------------------------
Summary: Make the sync RPCs over the bridge use the OOB thread pool
Key: ISPN-3043
URL: https://issues.jboss.org/browse/ISPN-3043
Project: Infinispan
Issue Type: Enhancement
Components: Cross-Site Replication
Affects Versions: 5.2.5.Final
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 5.3.0.Beta1, 5.3.0.Final
The sync bridge calls should use the OOB thread pool as in the case of sync internal RPCs. That's because no jgroups ordering is needed for sync RPCs (ordering is induced by the sync nature of the call).
--
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
[JBoss JIRA] (ISPN-2173) NPE when using XA enlistment without recovery
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2173?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-2173:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.3.0.Beta1
Resolution: Done
> NPE when using XA enlistment without recovery
> ---------------------------------------------
>
> Key: ISPN-2173
> URL: https://issues.jboss.org/browse/ISPN-2173
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.1.5.FINAL
> Reporter: Mircea Markus
> Assignee: Adrian Nistor
> Labels: jdg6
> Fix For: 5.3.0.Beta1, 5.3.0.Final
>
>
> When using xa enlistment (transaction/useSynchronization=false, default), and recovery is disabled (transaction/recovery/enabled=false, default) the transaction manager might invoke recovery related methods such as XAResource.forget() in certain situations.
> E.g. the JBossTM invokes "forget", if during, XAResource.commit(xid, true) (second param means 1PC=true) an exception is thrown. (I expect an XAResource.rollback to be invoked in between the failed commit and forget).
> Here is such a stack trace:
> {quote}
> 2012-07-25 14:13:42,821 WARN (testng-CheckRemoteLockAcquiredOnlyOnceDistTest:) [org.infinispan.transaction.xa.TransactionXaAdapter] Exception removing recovery information:java.lang.NullPointerException
> at org.infinispan.transaction.xa.TransactionXaAdapter.forget(TransactionXaAdapter.java:159)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.forget(XAResourceRecord.java:759)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:691)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2285)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1468)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117)
> at org.infinispan.lock.CheckRemoteLockAcquiredOnlyOnceTest.testLockThenOperation(CheckRemoteLockAcquiredOnlyOnceTest.java:157)
> at org.infinispan.lock.CheckRemoteLockAcquiredOnlyOnceTest.testLockThenPutAll(CheckRemoteLockAcquiredOnlyOnceTest.java:100)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:74)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:673)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:1147)
> at org.testng.TestRunner.privateRun(TestRunner.java:749)
> at org.testng.TestRunner.run(TestRunner.java:600)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:317)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)
> at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {quote}
> As we do allow xa enlistment *without* recovery enabled this NPE shouldn't be shown to the user.
> Instead an warning should be logged stating that XA enlistment is configured without recovery, but recovery might be needed in certain situations.
--
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
[JBoss JIRA] (ISPN-2549) Invalidation mode caches with pessimistic transactions results in stale remote locks
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2549?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-2549:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.3.0.Beta1
Resolution: Done
> Invalidation mode caches with pessimistic transactions results in stale remote locks
> ------------------------------------------------------------------------------------
>
> Key: ISPN-2549
> URL: https://issues.jboss.org/browse/ISPN-2549
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.2.0.Beta4
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 5.3.0.Beta1, 5.3.0.Final
>
> Attachments: InvalidationModePessimisticLockingIssueTest.java
>
>
> An invalidation mode cluster with two nodes A and B. Node A is coordinator.
> Putting a key on node B results in a remote lock being acquired on A. But the lock on A is not released when the TX commits. Subsequent attempts to lock the key on A will fail with TimeoutException.
> The key aspects to reproduce this are:
> 1. pessimistic locking
> 2. the transaction starts on a node different than the coordinator
> This scenario does not involve any state transfer, so it should not be related to the already known issues with stale locks caused by state-transfer.
--
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