[JBoss JIRA] (ISPN-1748) Allow consistency for concurrent updates when syncCommitPhase=false
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-1748?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-1748:
-------------------------------------
Assignee: (was: Mircea Markus)
> Allow consistency for concurrent updates when syncCommitPhase=false
> -------------------------------------------------------------------
>
> Key: ISPN-1748
> URL: https://issues.jboss.org/browse/ISPN-1748
> Project: Infinispan
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 5.1.0.CR4, 5.1.0.FINAL
> Reporter: Mircea Markus
> Priority: Optional
> Labels: experimental, performance
> Attachments: All_PUT.png
>
>
> when syncCommitPhase=false then there is a window of inconsistency in the case multipel tx access the same key at the same time.
> This can be avoided by sending the lock release command after the commit command, in the same thread which is async triggered by the TM.commit.
> This should be a very important performance buster for default configurations.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-3766) "containsKey" and "get" methods are not working properly with "putForExternalRead" during active transaction. WriteSkewException appears.
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3766?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-3766:
-------------------------------------
Assignee: (was: Mircea Markus)
> "containsKey" and "get" methods are not working properly with "putForExternalRead" during active transaction. WriteSkewException appears.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3766
> URL: https://issues.jboss.org/browse/ISPN-3766
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.3.0.Final, 6.0.0.CR1, 6.0.0.Final
> Reporter: V L
> Attachments: InfinispanTest.java
>
>
> I'm not new with Infinispan, we use it from 5.3 version. Now I'm working on adding WriteSkew functional to our project, but unfortunately it's not working as we expected.
> We use infinispan like a cache for mongoDb data source, but this situation doesn't depends on data source vendor.
> The problem is that WriteSkewException is available in specific situation, here are steps for reproducing:
> 1) begin tx -> create an new element -> commit tx.
> 2) wait until cache expires. cache is empty now
> 3) being tx -> try to get element from cache, but it's not found -> load element from data source -> put it to the cache via putForExternalRead for read access outside of current transaction.
> 4) make some modification with element -> put element to cache -> commit tx -> WriteSkewException
> here is my log:
> TX BEGIN tx_status=6 thread=1
> PUT id=key1, tx_status=0, thread=1 cache_size=1, cache_ contains=key:key1, value:value
> TX COMMIT tx_status=0 thread=1
> TX BEGIN. tx_status=6, thread=1
> SIZE id=key1 tx_status=0, thread=1 cache_size=1 contains=key:key1, value:null
> PUT_FOR_EXTERNAL_READ id=key1, tx_status=0 thread=1 cache_size=1 cache_contains=key:key1, value:null
> PUT id=key1 tx_status=0 thread=1 cache_size=1 contains=key:key1, value:value
> TX COMMIT status=0 thread=1
> ISPN000005: Detected write skew on key [1]. Another process has changed the entry since we last read it! Unable to copy entry for update.
> Exception executing call org.infinispan.transaction.WriteSkewException: Detected write skew.
> I think the problem is in "get" method. When you invoke "get" method with key that not available in cache, infinispan create an "null" element in cache. This element won't be updated by putForExternalRead method (look at log above). If you skip "get" method invocation everithing will work fine. By the way, everithing is working fine if you skip "step 2" of the scenario.
> I use workaround for this situation. I check if element exist in the cache not by "containsKey" or "get" method but via cache.keySet().contains(key)
> This works ok
> I'm looking forward for you comments, maybe I'm doing something wrong.
> Thanks
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-3673) JdbcBinaryStore doesn't properly loadBucket from h2 database
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3673?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-3673:
-------------------------------------
Assignee: (was: Mircea Markus)
> JdbcBinaryStore doesn't properly loadBucket from h2 database
> ------------------------------------------------------------
>
> Key: ISPN-3673
> URL: https://issues.jboss.org/browse/ISPN-3673
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Environment: WildFly Beta2-SNAPSHOT from 2013-10-30, h2 1.3.173
> Reporter: Tomas Remes
>
> I test HTTP session persistence to h2 database in clustered enviroment within WildFly testsuite and occassionally I can see following exception:
> {noformat}
> Unique index or primary key violation: "PRIMARY_KEY_A ON PUBLIC.""binarybased_default_host_session_db_cluster""(ID)"; SQL statement:
> INSERT INTO "binarybased_default_host_session_db_cluster" (datum, version, id) VALUES(?,?,?) [23505-159]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
> at org.h2.message.DbException.get(DbException.java:169)
> at org.h2.message.DbException.get(DbException.java:146)
> at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:81)
> at org.h2.index.PageBtree.find(PageBtree.java:121)
> at org.h2.index.PageBtreeLeaf.addRow(PageBtreeLeaf.java:146)
> at org.h2.index.PageBtreeLeaf.addRowTry(PageBtreeLeaf.java:100)
> at org.h2.index.PageBtreeIndex.addRow(PageBtreeIndex.java:105)
> at org.h2.index.PageBtreeIndex.add(PageBtreeIndex.java:96)
> at org.h2.table.RegularTable.addRow(RegularTable.java:130)
> at org.h2.command.dml.Insert.insertRows(Insert.java:124)
> at org.h2.command.dml.Insert.update(Insert.java:84)
> at org.h2.command.CommandContainer.update(CommandContainer.java:71)
> at org.h2.command.Command.executeUpdate(Command.java:212)
> at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:143)
> at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:129)
> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
> at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
> at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
> at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.CacheImpl.endBatch(CacheImpl.java:770) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0.CR1.jar:6.0.0.CR1]
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
> at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
> I've tried to debug this issue and I think the problem is following - the test creates and stores two buckets in org.infinispan.persistence.jdbc.binary.JdbcBinaryStore in storeInBucket(MarshalledEntry me, Integer bucketId). First bucket is stored and loaded always properly, but the second one, although is stored properly (exists in db), it's not loaded properly - resulting in null. This is the reason, why it tries to insert bucket with same id.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-1988) Coalesce updates to a given key to a single operation within a transaction
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-1988?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-1988:
-------------------------------------
Assignee: (was: Mircea Markus)
> Coalesce updates to a given key to a single operation within a transaction
> --------------------------------------------------------------------------
>
> Key: ISPN-1988
> URL: https://issues.jboss.org/browse/ISPN-1988
> Project: Infinispan
> Issue Type: Feature Request
> Components: Transactions
> Affects Versions: 5.1.4.FINAL
> Reporter: Mircea Markus
> Labels: optimisation, transaction
>
> Following code run with optimistic caches:
> start tx
> put k, v1
> put k, v2
> put k, v3
> commit
> Would cause the PrepareCommand that is sent around to contain 3 PutKeyvalueCommands which is sub-optimal. What we can do is to only send the last written value (i.e. k v3) and ignore the previous two (reuse the code in AsyncCacheStore). Besides reducing the payload, from this would benefit the AtomicHashMaps which uses this code quite a lot and also the OptimisticLockingInterceptor which would not attempt to order the keys.
> I guess this should be a feature that is disabled by default, as I don't think it is required in general. Might as well be not configurable, enabled by default feature. Comments?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-3509) postgresplus database not auto-detected
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3509?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-3509:
-------------------------------------
Assignee: (was: Mircea Markus)
> postgresplus database not auto-detected
> ----------------------------------------
>
> Key: ISPN-3509
> URL: https://issues.jboss.org/browse/ISPN-3509
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Alpha3, 6.0.0.Alpha4
> Reporter: Vitalii Chepeliuk
> Priority: Minor
> Attachments: server.log
>
>
> When I run our functional tests inside EAP server against postgresplus database following error occured
> 17:19:12,893 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (pool-1-thread-1) ISPN000136: Execution error: org.infinispan.commons.CacheConfigurationException: Unable to detect database type from JDBC driver name or connection metadata. Please provide this manually using the 'databaseType' property in your configuration. Supported database type strings are [MYSQL, POSTGRES, DERBY, HSQL, H2, SQLITE, DB2, DB2_390, INFORMIX, INTERBASE, FIREBIRD, SQL_SERVER, ACCESS, ORACLE, SYBASE]
> at org.infinispan.loaders.jdbc.TableManipulation.getDatabaseType(TableManipulation.java:412) [infinispan-cachestore-jdbc.jar:6.0.0.Alpha4-redhat-1]
> Jenkins job https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-2489) infinispan-core stores resources in default package, preventing OSGI export
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2489?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-2489:
-------------------------------------
Assignee: (was: Mircea Markus)
> infinispan-core stores resources in default package, preventing OSGI export
> ---------------------------------------------------------------------------
>
> Key: ISPN-2489
> URL: https://issues.jboss.org/browse/ISPN-2489
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 5.1.6.FINAL, 5.2.0.Beta3
> Reporter: Vitalii Tymchyshyn
>
> Currently infinispan stores resources (e.g. infinispan-core-component-metadata.dat) in the default package. This makes this resources private to infinispan-core OSGI bundle as default package can't be exported
> So, first of all it does not start by default when cache manager is created from another bundle. If configuration is created explicitly passing infinispan-core classloader, it can start, but no additional components can be used (e.g. loaders from another bundles).
> I can see next possible options to handle this:
> 1) Move resources to the package
> 2) Use multiple classloaders to read resources (as it's done for classes)
> 3) Use exact classloader, e.g. use fixed infinispan-core classloader to get infinispan-core-component-metadata.dat. Dunno if this would work for all resources, like jgroups configuration files.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-3858) RHQ management -- [RecoveryAdmin] forceCommit operation call throws NumberFormatException
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3858?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-3858:
-------------------------------------
Assignee: (was: Mircea Markus)
> RHQ management -- [RecoveryAdmin] forceCommit operation call throws NumberFormatException
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-3858
> URL: https://issues.jboss.org/browse/ISPN-3858
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 6.0.0.Final
> Reporter: Tomas Sykora
> Attachments: recoveryAdminForceCommitByInternalIdNumFormatException.txt
>
>
> Operation ShowInDoubtTransactions is working and it is possible to identify internal IDs of in doubt transactions.
> Operation force rollback by internal id is working as well.
> Remove recovery info by internal id is working as well.
> However, operation force commit by internal id is throwing java.lang.NumberFormatException: For input string: "1125908496777218" etc., see attached file with full stack trace.
> "Bonus" question: how can we externally (from jon gui? somewhere else?) identify properties for commit/rollback operations using Xid?
> i.e.: Format Id, Global Tx Id and Branch Qualifier?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-1146) Improve documentation around transaction and locking
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-1146?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-1146:
-------------------------------------
Assignee: (was: Mircea Markus)
> Improve documentation around transaction and locking
> ----------------------------------------------------
>
> Key: ISPN-1146
> URL: https://issues.jboss.org/browse/ISPN-1146
> Project: Infinispan
> Issue Type: Task
> Components: Transactions
> Reporter: Mircea Markus
>
> As suggested by Jonathan Halliday:
> - preserving some subset of the existing transactional guarantees is all well and good BUT if the user is relying on additional 'guarantees' that are not preserved in all cases then they'll be in trouble. Therefore, it's essential to document not just what the minimum expected guarantees for a given config are, but also that no additional properties that may coincidently be observed are actually guaranteed. Some vendors go further and explicitly document the bad things that may happen with given settings, since in some cases these are not easy to reproduce in testing.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months