[JBoss JIRA] (ISPN-3923) Infinispan bundle resolution fails
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ISPN-3923?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated ISPN-3923:
------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/2549
Added pull request for 5.2.x. Note that ISPN 6 and 7 do *not* need this fix -- all manifests are already corrected there using explicit imports/exports.
> Infinispan bundle resolution fails
> ----------------------------------
>
> Key: ISPN-3923
> URL: https://issues.jboss.org/browse/ISPN-3923
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 5.2.8.Final, 6.0.0.Final
> Environment: Eclipse Virgo
> Reporter: Mathilde Ffrench
> Assignee: Brett Meyer
> Priority: Trivial
> Labels: osgi
>
> In bundle infinispan-commons-6.0.0.Final, the MANIFEST file contains sun.misc import. This package is a system package which is in the boot delegation package list and consequently should not be imported by bundles as it is managed by JVM boot classloader (http://wiki.osgi.org/wiki/Boot_Delegation) ...
> I guess that sun.misc is also a bootdelegated package in many other OSGI container like Apache Felix so the sun.misc package should be remove from import list.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-3923) Infinispan bundle resolution fails
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ISPN-3923?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated ISPN-3923:
------------------------------
Affects Version/s: 5.2.8.Final
> Infinispan bundle resolution fails
> ----------------------------------
>
> Key: ISPN-3923
> URL: https://issues.jboss.org/browse/ISPN-3923
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 5.2.8.Final, 6.0.0.Final
> Environment: Eclipse Virgo
> Reporter: Mathilde Ffrench
> Assignee: Brett Meyer
> Priority: Trivial
> Labels: osgi
>
> In bundle infinispan-commons-6.0.0.Final, the MANIFEST file contains sun.misc import. This package is a system package which is in the boot delegation package list and consequently should not be imported by bundles as it is managed by JVM boot classloader (http://wiki.osgi.org/wiki/Boot_Delegation) ...
> I guess that sun.misc is also a bootdelegated package in many other OSGI container like Apache Felix so the sun.misc package should be remove from import list.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-3923) Infinispan bundle resolution fails
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ISPN-3923?page=com.atlassian.jira.plugin.... ]
Brett Meyer reassigned ISPN-3923:
---------------------------------
Assignee: Brett Meyer (was: Mircea Markus)
> Infinispan bundle resolution fails
> ----------------------------------
>
> Key: ISPN-3923
> URL: https://issues.jboss.org/browse/ISPN-3923
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.0.Final
> Environment: Eclipse Virgo
> Reporter: Mathilde Ffrench
> Assignee: Brett Meyer
> Priority: Trivial
> Labels: osgi
>
> In bundle infinispan-commons-6.0.0.Final, the MANIFEST file contains sun.misc import. This package is a system package which is in the boot delegation package list and consequently should not be imported by bundles as it is managed by JVM boot classloader (http://wiki.osgi.org/wiki/Boot_Delegation) ...
> I guess that sun.misc is also a bootdelegated package in many other OSGI container like Apache Felix so the sun.misc package should be remove from import list.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4131) Lock acquired forever with delayed PrepareCommand
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4131?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4131:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2547
> Lock acquired forever with delayed PrepareCommand
> -------------------------------------------------
>
> Key: ISPN-4131
> URL: https://issues.jboss.org/browse/ISPN-4131
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.2.Final, 7.0.0.Alpha1
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 630betablocker
>
> Distributed transactional cache:
> 1. A sends Prepare to B
> 2. B receives Prepare, but due to ongoing ST it is blocked
> 3. B replication timeout elapses
> 4. B sends Rollback, this does not find the TX as Prepare was not executed yet. The transaction is put into completedTransactions.
> 5. Completed transactions timeout elapses. This is by default 15 seconds, way shorter than ST timeout (due to which the Prepare was blocked)
> 6. Prepare is executed on B, acquiring lock on K
> Nobody will rollback the TX as originator thinks it was already rolled back.
> Result: key K will be locked forever, all attempts to update/remove it will fail.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-3689) Preloading fails with JdbcBinaryCacheStore on DB2
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3689?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3689:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1087209|https://bugzilla.redhat.com/show_bug.cgi?id=1087209] from MODIFIED to ON_QA
> Preloading fails with JdbcBinaryCacheStore on DB2
> --------------------------------------------------
>
> Key: ISPN-3689
> URL: https://issues.jboss.org/browse/ISPN-3689
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.2.7.Final, 6.0.0.CR1
> Environment: DB2 9.7.5
> Reporter: Nicolas Filotto
> Assignee: Mircea Markus
> Fix For: 7.0.0.Alpha4, 5.2.9.Final
>
>
> I use the {{JdbcBinaryCacheStore}} with preloading enabled, when I test it on DB2 I get an exception of type:
> {code}
> 06.11.2013 16:27:51 *ERROR* [main] DataManipulationHelper: ISPN008007: SQL error while fetching all StoredEntries (DataManipulationHelper.java, line 253)
> com.ibm.db2.jcc.am.SqlSyntaxErrorException: DB2 SQL Error: SQLCODE=-104, SQLSTATE=42601, SQLERRMC=?;r_quota" FETCH FIRST;<space>, DRIVER=4.13.80
> at com.ibm.db2.jcc.am.id.a(id.java:677)
> at com.ibm.db2.jcc.am.id.a(id.java:60)
> at com.ibm.db2.jcc.am.id.a(id.java:127)
> at com.ibm.db2.jcc.am.fo.c(fo.java:2653)
> at com.ibm.db2.jcc.am.fo.d(fo.java:2641)
> at com.ibm.db2.jcc.am.fo.a(fo.java:2090)
> at com.ibm.db2.jcc.am.go.a(go.java:7639)
> at com.ibm.db2.jcc.t4.cb.h(cb.java:141)
> at com.ibm.db2.jcc.t4.cb.b(cb.java:41)
> at com.ibm.db2.jcc.t4.q.a(q.java:32)
> at com.ibm.db2.jcc.t4.sb.i(sb.java:135)
> at com.ibm.db2.jcc.am.fo.ib(fo.java:2059)
> at com.ibm.db2.jcc.am.go.sc(go.java:3555)
> at com.ibm.db2.jcc.am.go.b(go.java:4344)
> at com.ibm.db2.jcc.am.go.fc(go.java:741)
> at com.ibm.db2.jcc.am.go.executeQuery(go.java:711)
> at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> at org.infinispan.loaders.jdbc.DataManipulationHelper.loadSome(DataManipulationHelper.java:245)
> at org.infinispan.loaders.jdbc.binary.JdbcBinaryCacheStore.loadLockSafe(JdbcBinaryCacheStore.java:312)
> at org.infinispan.loaders.LockSupportCacheStore.load(LockSupportCacheStore.java:167)
> at org.infinispan.loaders.CacheLoaderManagerImpl.loadState(CacheLoaderManagerImpl.java:285)
> at org.infinispan.loaders.CacheLoaderManagerImpl.preload(CacheLoaderManagerImpl.java:238)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:886)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:657)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:646)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:549)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:217)
> at org.infinispan.CacheImpl.start(CacheImpl.java:582)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:686)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:649)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:545)
> {code}
> I looks like you cannot use a parameter to set your query limit in case of DB2 9.7.5 at least
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-3680) Inconsistent way to use the column id in the JdbcBinaryCacheStore
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3680?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3680:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1087205|https://bugzilla.redhat.com/show_bug.cgi?id=1087205] from MODIFIED to ON_QA
> Inconsistent way to use the column id in the JdbcBinaryCacheStore
> -----------------------------------------------------------------
>
> Key: ISPN-3680
> URL: https://issues.jboss.org/browse/ISPN-3680
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.2.7.Final, 5.3.0.Final, 6.0.0.CR1
> Reporter: Nicolas Filotto
> Assignee: Mircea Markus
> Fix For: 7.0.0.Alpha4, 5.2.9.Final
>
>
> I met some issues with (at least) H2 and JdbcBinaryCacheStore that prevent to modify a value in the cache store which is quite annoying. After a deeper look, I realized that it was due to the method {{JdbcBinaryCacheStore.loadBucket(Integer keyHashCode)}} that uses {{setInt}} instead of {{setString}} like in updateBucket and insertBucket to set the id as parameter to the query. With HSQLDB and MySQL, it works normally but with H2, the result of the query is always empty so it always tries to add a new entry which of course fails because of the integrity constraint on the primary key (aka the id).
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4239) Commands received before the first topology where the local node is a member are not ignored
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4239?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4239:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.0.0.Final
Resolution: Done
> Commands received before the first topology where the local node is a member are not ignored
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-4239
> URL: https://issues.jboss.org/browse/ISPN-4239
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 6.0.2.Final, 7.0.0.Alpha3
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 7.0.0.Alpha4, 7.0.0.Final
>
>
> The ISPN-3731 fix was supposed to prevent a joiner from running commands broadcasted by other members before the joiner became a member in the cache topology.
> However, the fix was incomplete, and commands received before the joiner became a member were still executed. This is causing failures in {{StateTransferReplicationQueueTest}}, which is issuing a put(k, v) and a remove(k) and expecting the key to be removed. It can happen that the put(k, v) command is executed before the joiner becomes a member, but the remove(k) command is rejected because it came from a topology where the joiner was not a member:
> {noformat}
> 12:54:41,412 TRACE (testng-StateTransferReplicationQueueTest:nbst-replqueue) [StateTransferManagerImpl] Installing new cache topology CacheTopology{id=3, currentCH=ReplicatedConsistentHash{members=[StateTransferReplicationQueueTest-NodeA-8686], numSegments=1, primaryOwners=[0]}, pendingCH=null} on cache nbst-replqueue
> 12:54:41,412 TRACE (testng-StateTransferReplicationQueueTest:nbst-replqueue) [StateTransferLockImpl] Signalling topology 3 is installed
> 12:54:41,433 TRACE (Incoming-1,StateTransferReplicationQueueTest-NodeC-12962:) [InboundInvocationHandlerImpl] Calling perform() on MultipleRpcCommand{commands=[..., PrepareCommand {modifications=[PutKeyValueCommand{key=test58, value=org.infinispan.statetransfer.StateTransferReplicationQueueTest$PojoValue@59, flags=null, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}], onePhaseCommit=true, gtx=GlobalTransaction:<StateTransferReplicationQueueTest-NodeA-8686>:6969:local, cacheName='nbst-replqueue', topologyId=3}], cacheName='nbst-replqueue'}
> 12:54:41,439 TRACE (remote-thread-StateTransferReplicationQueueTest-NodeC-p3980-t1:nbst-replqueue) [StateTransferManagerImpl] Installing new cache topology CacheTopology{id=4, currentCH=ReplicatedConsistentHash{members=[StateTransferReplicationQueueTest-NodeA-8686], numSegments=1, primaryOwners=[0]}, pendingCH=ReplicatedConsistentHash{members=[StateTransferReplicationQueueTest-NodeA-8686, StateTransferReplicationQueueTest-NodeC-12962], numSegments=1, primaryOwners=[0]}} on cache nbst-replqueue
> 12:54:41,439 TRACE (remote-thread-StateTransferReplicationQueueTest-NodeC-p3980-t1:nbst-replqueue) [StateTransferManagerImpl] This is the first topology in which the local node is a member
> 12:54:41,462 TRACE (Incoming-1,StateTransferReplicationQueueTest-NodeC-12962:nbst-replqueue) [ReadCommittedEntry] Updating entry (key=test58 removed=false valid=true changed=true created=true loaded=false value=org.infinispan.statetransfer.StateTransferReplicationQueueTest$PojoValue@59 metadata=EmbeddedMetadata{version=null}, providedMetadata=null)
> 12:54:41,491 TRACE (Incoming-1,StateTransferReplicationQueueTest-NodeC-12962:) [CommandAwareRpcDispatcher] Attempting to execute command: MultipleRpcCommand{commands=[PrepareCommand {modifications=[RemoveCommand{key=test58, value=null, flags=null, valueMatcher=MATCH_ALWAYS}], onePhaseCommit=true, gtx=GlobalTransaction:<StateTransferReplicationQueueTest-NodeA-8686>:6970:local, cacheName='nbst-replqueue', topologyId=3}, ...], cacheName='nbst-replqueue'} [sender=StateTransferReplicationQueueTest-NodeA-8686]
> 12:54:41,493 TRACE (Incoming-1,StateTransferReplicationQueueTest-NodeC-12962:) [StateTransferLockImpl] Waiting for transaction data for topology 3, current topology is 3
> 12:54:41,493 TRACE (Incoming-1,StateTransferReplicationQueueTest-NodeC-12962:) [InboundInvocationHandlerImpl] Ignoring command sent before the local node was a member (command topology id is 3)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-3742) StateTransferReplicationQueueTest random failures
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3742?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3742:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.0.0.Alpha4
Resolution: Done
> StateTransferReplicationQueueTest random failures
> -------------------------------------------------
>
> Key: ISPN-3742
> URL: https://issues.jboss.org/browse/ISPN-3742
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 7.0.0.Alpha4
>
>
> The writer thread in StateTransferReplicationQueueTest is too fast, and sometimes it generates so many writes that it takes more than 5 seconds for the second node to apply all of them.
> We should use a much smaller limit for the replication queue, and the test should wait until all the commands have been replicated instead of using an arbitrary timeout.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4218) Increase default maxCollectorSize for MapReduceTask
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4218?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño resolved ISPN-4218.
------------------------------------
Fix Version/s: 7.0.0.Alpha4
7.0.0.Final
Resolution: Done
> Increase default maxCollectorSize for MapReduceTask
> ---------------------------------------------------
>
> Key: ISPN-4218
> URL: https://issues.jboss.org/browse/ISPN-4218
> Project: Infinispan
> Issue Type: Enhancement
> Components: Distributed Execution and Map/Reduce
> Reporter: Vladimir Blagojevic
> Assignee: Vladimir Blagojevic
> Priority: Minor
> Fix For: 7.0.0.Alpha4, 7.0.0.Final
>
>
> During performance testing we have found that the value of around 10K leads to a better performance of large map/reduce tasks containing more than 100K of cache entries. We have concluded that the current default value of 1024 is too small.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-4137) Transaction executed multiple times due to forwarded CommitCommand
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4137?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4137:
-----------------------------------------------
Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1080313|https://bugzilla.redhat.com/show_bug.cgi?id=1080313] from NEW to MODIFIED
> Transaction executed multiple times due to forwarded CommitCommand
> ------------------------------------------------------------------
>
> Key: ISPN-4137
> URL: https://issues.jboss.org/browse/ISPN-4137
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer, Transactions
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 630betablocker
>
> When the {{StateTransferInterceptor}} forwards a CommitCommand for the new topology, multiple CommitCommands may be broadcast across the cluster. If the command (forwarded already from originator) times out, the transaction may be correctly finished by the first one and the application considers TX as succeeded (useSynchronizations=true), although one more Rollback is sent as well.
> Then, again in STI, when the CommitCommand arrives with higher topologyId than the one used for the first TX execution, another artificial Prepare (followed by the commit) is executed - see {{STI.visitCommitCommand}}.
> However, this execution may be delayed a lot and originator may have already executed another TX on the same entries. Then, this forwarded Commit will overwrite the already updated entries, causing inconsistency of data.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months