[JBoss JIRA] (ISPN-7749) A node leaving during rebalance causes extra segment transfers
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7749?page=com.atlassian.jira.plugin.... ]
Dan Berindei resolved ISPN-7749.
--------------------------------
Fix Version/s: (was: 9.3.0.Final)
Resolution: Duplicate Issue
Duplicate of ISPN-4587
> A node leaving during rebalance causes extra segment transfers
> --------------------------------------------------------------
>
> Key: ISPN-7749
> URL: https://issues.jboss.org/browse/ISPN-7749
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 9.0.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
>
> If a node leaves during a rebalance, the only change is that other nodes will no longer request segments from that node. Otherwise the rebalance proceeds as usual, and at the end a node may delete its copy of a segment even if that leaves less than {{numOwners}} copies in the cluster.
> When the leaver is the joiner, a 2nd rebalance is very likely to return to the initial CH, but only after transferring some segments twice:
> {noformat}
> Rebalance starts: current_owners(s) = AB, pending_owners(s) = AC
> C leaves: current_owners(s) = AB, pending_owners(s) = A
> Rebalance finishes: current_owners(s) = A, pending_owners(s) = A
> 2nd rebalance starts: current_owners(s) = A, pending_owners(s) = AB
> {noformat}
> Even if the leaver is one of the old owners and the 2 segment transfers are necessary, the cluster stays for too long with less than {{numOwners}} copies of the segment:
> {noformat}
> Rebalance starts: current_owners(s) = AB, pending_owners(s) = AC
> A leaves: current_owners(s) = B, pending_owners(s) = C
> C transfers segment s from B
> Rebalance finishes: current_owners(s) = C, pending_owners(s) = C
> 2nd rebalance starts: current_owners(s) = C, pending_owners(s) = DC
> {noformat}
> We can fix this by making the pending CH a union of the current and pending CH whenever a node leavers, and only removing extra segment copies after the 2nd rebalance.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-9185) Remove compat mode from the Hot Rod protocol
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-9185:
---------------------------------------
Summary: Remove compat mode from the Hot Rod protocol
Key: ISPN-9185
URL: https://issues.jboss.org/browse/ISPN-9185
Project: Infinispan
Issue Type: Sub-task
Components: Hot Rod
Reporter: Gustavo Fernandes
Compat mode is also leaked through the Hot Rod protocol, as the server sends a byte signalling if the cache has compat mode or not, and the client uses this to calculate key owners.
The server should send instead the MediaType of the keys to help such calculations in the client.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-5451) Data Container Segment Striping
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5451?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5451:
--------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/5997
> Data Container Segment Striping
> -------------------------------
>
> Key: ISPN-5451
> URL: https://issues.jboss.org/browse/ISPN-5451
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: William Burns
> Assignee: William Burns
>
> Today each node owns a given number of segments at a time. There are many operations that are only concerned with entries of a given segment. Unfortunately this means that we must iterate over the entire contents of the cache to find only the entries that match given segments. Note this JIRA is only for the in memory data container. The cache store requires additional work and should be done separately as it may involve reworking many more areas of the code base.
> # State Transfer entry removal (this removes all entries of given segments)
> # Entry retrieval (if we could iterate by segment instead of over all values we could complete segments sooner which would reduce how much memory a client must hold)
> # Indexing may want to index by segment at some point as well
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-5451) Data Container Segment Striping
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5451?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5451:
--------------------------------
Status: Open (was: New)
> Data Container Segment Striping
> -------------------------------
>
> Key: ISPN-5451
> URL: https://issues.jboss.org/browse/ISPN-5451
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: William Burns
> Assignee: William Burns
>
> Today each node owns a given number of segments at a time. There are many operations that are only concerned with entries of a given segment. Unfortunately this means that we must iterate over the entire contents of the cache to find only the entries that match given segments. Note this JIRA is only for the in memory data container. The cache store requires additional work and should be done separately as it may involve reworking many more areas of the code base.
> # State Transfer entry removal (this removes all entries of given segments)
> # Entry retrieval (if we could iterate by segment instead of over all values we could complete segments sooner which would reduce how much memory a client must hold)
> # Indexing may want to index by segment at some point as well
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-5451) Data Container Segment Striping
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5451?page=com.atlassian.jira.plugin.... ]
Work on ISPN-5451 started by William Burns.
-------------------------------------------
> Data Container Segment Striping
> -------------------------------
>
> Key: ISPN-5451
> URL: https://issues.jboss.org/browse/ISPN-5451
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: William Burns
> Assignee: William Burns
>
> Today each node owns a given number of segments at a time. There are many operations that are only concerned with entries of a given segment. Unfortunately this means that we must iterate over the entire contents of the cache to find only the entries that match given segments. Note this JIRA is only for the in memory data container. The cache store requires additional work and should be done separately as it may involve reworking many more areas of the code base.
> # State Transfer entry removal (this removes all entries of given segments)
> # Entry retrieval (if we could iterate by segment instead of over all values we could complete segments sooner which would reduce how much memory a client must hold)
> # Indexing may want to index by segment at some point as well
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-9139) CacheWriterInterceptor invokes batch persistence operations with potentially empty entry sets
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-9139?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-9139:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.3.0.CR1
Resolution: Done
> CacheWriterInterceptor invokes batch persistence operations with potentially empty entry sets
> ---------------------------------------------------------------------------------------------
>
> Key: ISPN-9139
> URL: https://issues.jboss.org/browse/ISPN-9139
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 9.2.2.Final
> Reporter: Moritz Becker
> Assignee: Ryan Emerson
> Fix For: 9.3.0.CR1
>
>
> In {{org.infinispan.interceptors.impl.CacheWriterInterceptor#store}}, you have the following:
> {code:java}
> persistenceManager.writeBatchToAllNonTxStores(sharedMods.getMarshalledEntries(), BOTH, 0);
> persistenceManager.writeBatchToAllNonTxStores(nonSharedMods.getMarshalledEntries(), PRIVATE, 0);
> persistenceManager.deleteBatchFromAllNonTxStores(sharedMods.getKeysToRemove(), BOTH, 0);
> persistenceManager.deleteBatchFromAllNonTxStores(nonSharedMods.getKeysToRemove(), PRIVATE, 0);
> {code}
> The batch deletion causes an error with JPAStore in case of an empty key set because the an SQL query like {{where id in ()}}, i.e. the comparison set for the in clause is empty. At least with postgres, this causes the following exception:
> {code}
> ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (EE-ManagedExecutorService-default-Thread-2) ISPN000136: Error executing command CommitCommand, writing keys []: org.infinispan.persistence.jpa.JpaStoreException: Exception caught in deleteBatch()
> at org.infinispan.persistence.jpa.JpaStore.deleteBatch(JpaStore.java:350)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.lambda$deleteBatchFromAllNonTxStores$14(PersistenceManagerImpl.java:562)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.deleteBatchFromAllNonTxStores(PersistenceManagerImpl.java:562)
> at org.infinispan.interceptors.impl.CacheWriterInterceptor.store(CacheWriterInterceptor.java:406)
> at org.infinispan.interceptors.impl.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:123)
> at org.infinispan.interceptors.impl.CacheWriterInterceptor.visitCommitCommand(CacheWriterInterceptor.java:102)
> at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:38)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54)
> at org.infinispan.interceptors.impl.TransactionalStoreInterceptor.visitCommitCommand(TransactionalStoreInterceptor.java:53)
> at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:38)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54)
> at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
> at org.infinispan.interceptors.DDAsyncInterceptor.visitCommitCommand(DDAsyncInterceptor.java:142)
> at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:38)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndFinally(BaseAsyncInterceptor.java:150)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitCommitCommand(EntryWrappingInterceptor.java:183)
> at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:38)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(BaseAsyncInterceptor.java:98)
> at org.infinispan.interceptors.impl.NotificationInterceptor.visitCommitCommand(NotificationInterceptor.java:46)
> at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:38)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndFinally(BaseAsyncInterceptor.java:150)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.visitCommitCommand(AbstractTxLockingInterceptor.java:51)
> at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:38)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(BaseAsyncInterceptor.java:98)
> at org.infinispan.interceptors.impl.TxInterceptor.finishCommit(TxInterceptor.java:189)
> at org.infinispan.interceptors.impl.TxInterceptor.visitCommitCommand(TxInterceptor.java:183)
> at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:38)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54)
> at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
> at org.infinispan.interceptors.DDAsyncInterceptor.visitCommitCommand(DDAsyncInterceptor.java:142)
> at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:38)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:123)
> at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:90)
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:248)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:137)
> at org.infinispan.transaction.impl.TransactionCoordinator.commitInternal(TransactionCoordinator.java:219)
> at org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:161)
> at org.infinispan.transaction.impl.TransactionTable.afterCompletion(TransactionTable.java:851)
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:33)
> at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:196)
> at org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization.afterCompletion(AbstractTransaction.java:279)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:101)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1289)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:73)
> at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.commitIfNeeded(PersistenceManagerImpl.java:874)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.preloadKey(PersistenceManagerImpl.java:830)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.lambda$preload$2(PersistenceManagerImpl.java:279)
> at org.infinispan.persistence.jpa.JpaStore$LoadingProcessTask.call(JpaStore.java:915)
> at org.infinispan.persistence.jpa.JpaStore$LoadingProcessTask.call(JpaStore.java:843)
> at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)
> at java.util.concurrent.FutureTask.run(FutureTask.java)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)
> at java.util.concurrent.FutureTask.run(FutureTask.java)
> at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:20)
> at java.util.concurrent.ExecutorCompletionService.submit(ExecutorCompletionService.java:181)
> at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:31)
> at org.infinispan.persistence.jpa.JpaStore.process(JpaStore.java:644)
> at org.infinispan.persistence.jpa.JpaStore.process(JpaStore.java:583)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:271)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79)
> at org.infinispan.commons.util.SecurityActions.doPrivileged(SecurityActions.java:71)
> at org.infinispan.commons.util.SecurityActions.invokeAccessibly(SecurityActions.java:76)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:968)
> at org.infinispan.factories.AbstractComponentRegistry.lambda$invokePrioritizedMethods$6(AbstractComponentRegistry.java:703)
> at org.infinispan.factories.SecurityActions.lambda$run$1(SecurityActions.java:72)
> at org.infinispan.security.Security.doPrivileged(Security.java:76)
> at org.infinispan.factories.SecurityActions.run(SecurityActions.java:71)
> at org.infinispan.factories.AbstractComponentRegistry.invokePrioritizedMethods(AbstractComponentRegistry.java:696)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:689)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:607)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:229)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:1020)
> at org.infinispan.cache.impl.AbstractDelegatingCache.start(AbstractDelegatingCache.java:421)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:644)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:589)
> at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:475)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:461)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:447)
> at com.ordami.geo.service.impl.service.MatrixUpdateServiceImpl.updateMatrixEntry(MatrixUpdateServiceImpl.java:157)
> at com.ordami.geo.service.impl.service.MatrixUpdateServiceImpl$Proxy$_$$_WeldSubclass.updateMatrixEntry$$super(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:49)
> at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:77)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:120)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.doIntercept(TransactionalInterceptorRequired.java:53)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.intercept(TransactionalInterceptorBase.java:79)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:47)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84)
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72)
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56)
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79)
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68)
> at com.ordami.geo.service.impl.service.MatrixUpdateServiceImpl$Proxy$_$$_WeldSubclass.updateMatrixEntry(Unknown Source)
> at com.ordami.geo.service.impl.service.MatrixUpdateServiceImpl$Proxy$_$$_WeldClientProxy.updateMatrixEntry(Unknown Source)
> at com.ordami.geo.service.impl.service.MatrixUpdateServiceImpl$MatrixEntryUpdateTask.run(MatrixUpdateServiceImpl.java:207)
> at org.jboss.as.ee.concurrent.ControlPointUtils$ControlledRunnable.run(ControlPointUtils.java:105)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)
> at java.util.concurrent.FutureTask.run(FutureTask.java)
> at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:141)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
> at org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory$ElytronManagedThread.run(ElytronManagedThreadFactory.java:78)
> Caused by: javax.persistence.PersistenceException: org.hibernate.exception.SQLGrammarException: could not execute statement
> at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:149)
> at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:157)
> at org.hibernate.query.internal.AbstractProducedQuery.executeUpdate(AbstractProducedQuery.java:1514)
> at org.infinispan.persistence.jpa.JpaStore.deleteBatch(JpaStore.java:334)
> ... 133 more
> Caused by: org.hibernate.exception.SQLGrammarException: could not execute statement
> at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:106)
> at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:42)
> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:111)
> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:97)
> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:178)
> at org.hibernate.hql.internal.ast.exec.BasicExecutor.doExecute(BasicExecutor.java:100)
> at org.hibernate.hql.internal.ast.exec.BasicExecutor.execute(BasicExecutor.java:59)
> at org.hibernate.hql.internal.ast.exec.DeleteExecutor.execute(DeleteExecutor.java:110)
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.executeUpdate(QueryTranslatorImpl.java:450)
> at org.hibernate.engine.query.spi.HQLQueryPlan.performExecuteUpdate(HQLQueryPlan.java:374)
> at org.hibernate.internal.SessionImpl.executeUpdate(SessionImpl.java:1514)
> at org.hibernate.query.internal.AbstractProducedQuery.doExecuteUpdate(AbstractProducedQuery.java:1526)
> at org.hibernate.query.internal.AbstractProducedQuery.executeUpdate(AbstractProducedQuery.java:1504)
> ... 134 more
> Caused by: org.postgresql.util.PSQLException: ERROR: syntax error at or near ")"
> Position: 105
> at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2477)
> at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2190)
> at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:300)
> at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:428)
> at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:354)
> at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:169)
> at org.postgresql.jdbc.PgPreparedStatement.executeUpdate(PgPreparedStatement.java:136)
> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537)
> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:175)
> ... 142 more
> {code}
> Since you are doing expensive locking operations in all batch operations, I propose to change is code part to:
> {code:java}
> if (!sharedMods.getMarshalledEntries().isEmpty()) {
> persistenceManager.writeBatchToAllNonTxStores(sharedMods.getMarshalledEntries(), BOTH, 0);
> }
> if (!nonSharedMods.getMarshalledEntries().isEmpty()) {
> persistenceManager.writeBatchToAllNonTxStores(nonSharedMods.getMarshalledEntries(), PRIVATE, 0);
> }
> if (!sharedMods.getKeysToRemove().isEmpty()) {
> persistenceManager.deleteBatchFromAllNonTxStores(sharedMods.getKeysToRemove(), BOTH, 0);
> }
> if (!nonSharedMods.getKeysToRemove().isEmpty()) {
> persistenceManager.deleteBatchFromAllNonTxStores(nonSharedMods.getKeysToRemove(), PRIVATE, 0);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-9184) Remove compat mode from Remote Listener
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-9184?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9184:
------------------------------------
Description:
Remote Listeners uses compat mode checks in plenty of places to convert between storage and pojo format, and apart from that, there is a cache manager wide "event marshaller" used to unmarshal params for filters used in events, falling back to GenericJbossMarshaller when the marshaller is not set.
It should not use a global marshaller and should not hardcode JbossMarshaller, instead the remote listener themselves should have a mechanism of choosing the format of the data, similar to "useRawData" (where one can choose to receive events in a marshalled or unmarshaled way). One way of doing it is to supply a MediaType in the listener with the desired format.
was:
Remote Listeners uses compat mode checks in plenty of places to convert between storage and pojo format, and apart from that have a cache manager wide "event marshaller" used to unmarshal params for filters used in events, falling back to GenericJbossMarshaller when the marshaller is not set.
It should not use a global marshaller and should not hardcode JbossMarshaller, instead the remote listener themselves should have a mechanism of choosing the format of the data, similar to "useRawData" (where one can choose to receive events in a marshalled or unmarshaled way). One way of doing it is to supply a MediaType in the listener with the desired format.
> Remove compat mode from Remote Listener
> ---------------------------------------
>
> Key: ISPN-9184
> URL: https://issues.jboss.org/browse/ISPN-9184
> Project: Infinispan
> Issue Type: Sub-task
> Components: Listeners
> Reporter: Gustavo Fernandes
>
> Remote Listeners uses compat mode checks in plenty of places to convert between storage and pojo format, and apart from that, there is a cache manager wide "event marshaller" used to unmarshal params for filters used in events, falling back to GenericJbossMarshaller when the marshaller is not set.
> It should not use a global marshaller and should not hardcode JbossMarshaller, instead the remote listener themselves should have a mechanism of choosing the format of the data, similar to "useRawData" (where one can choose to receive events in a marshalled or unmarshaled way). One way of doing it is to supply a MediaType in the listener with the desired format.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-9182) Remove compat mode from Tasks and Scripts
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-9182?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9182:
------------------------------------
Description:
Both script and tasks hardcode GenericJbossMarshaller in several places, and use it to unmarshall parameters and user data when executing code. If the client uses a different marshaller, it breaks.
Both should rely instead on the MediaType sent by the Hot Rod client in order to convert from and to the storage format.
was:
Both script and tasks hardcode GenericJbossMarshaller in several places, and use it to unmarshall parameters and user data when executing code. If the client uses a different marshaller, it breaks.
Both should rely instead of the MediaType sent by the Hot Rod client in order to convert from and to the storage format.
> Remove compat mode from Tasks and Scripts
> -----------------------------------------
>
> Key: ISPN-9182
> URL: https://issues.jboss.org/browse/ISPN-9182
> Project: Infinispan
> Issue Type: Sub-task
> Components: Tasks
> Reporter: Gustavo Fernandes
>
> Both script and tasks hardcode GenericJbossMarshaller in several places, and use it to unmarshall parameters and user data when executing code. If the client uses a different marshaller, it breaks.
> Both should rely instead on the MediaType sent by the Hot Rod client in order to convert from and to the storage format.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-8836) Custom region definition causes ISPN000453
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8836?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-8836:
------------------------------
Status: Open (was: New)
> Custom region definition causes ISPN000453
> ------------------------------------------
>
> Key: ISPN-8836
> URL: https://issues.jboss.org/browse/ISPN-8836
> Project: Infinispan
> Issue Type: Bug
> Components: Hibernate Cache
> Affects Versions: 9.2.0.CR2
> Environment: Hibernate 5.2.13 SpringFramework 5.0.2.RELEASE
> Reporter: Anton Zalesky
> Assignee: Radim Vansa
> Priority: Critical
>
> I have entity with defined region
> @Entity
> @Table(name = "Dashboard")
> @Cache(usage = CacheConcurrencyStrategy.READ_WRITE, region = "dashboard")
> public class Dashboard {..}
> And I have infinispan.xml with custom configuration for region
> <local-cache name="dashboard" simple-cache="true" statistics="true" statistics-available="true">
> <transaction mode="NONE" />
> <expiration max-idle="14400000" />
> <memory>
> <object size="10000"/>
> </memory>
> </local-cache>
> On start I get the following exception
> org.infinispan.commons.CacheConfigurationException: ISPN000453: Attempt to define configuration for cache dashboard which already exists
> at org.infinispan.manager.DefaultCacheManager.doDefineConfiguration(DefaultCacheManager.java:370)
> at org.infinispan.manager.DefaultCacheManager.defineConfiguration(DefaultCacheManager.java:342)
> at org.infinispan.hibernate.cache.commons.InfinispanRegionFactory.getCache(InfinispanRegionFactory.java:692)
> at org.infinispan.hibernate.cache.commons.InfinispanRegionFactory.buildEntityRegion(InfinispanRegionFactory.java:332)
> at org.hibernate.cache.spi.RegionFactory.buildEntityRegion(RegionFactory.java:132)
> at org.hibernate.internal.CacheImpl.determineEntityRegionAccessStrategy(CacheImpl.java:439)
> at org.hibernate.metamodel.internal.MetamodelImpl.initialize(MetamodelImpl.java:120)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:300)
> at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:460)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:710)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:726)
> at org.springframework.orm.hibernate5.LocalSessionFactoryBean.buildSessionFactory(LocalSessionFactoryBean.java:535)
> at org.springframework.orm.hibernate5.LocalSessionFactoryBean.afterPropertiesSet(LocalSessionFactoryBean.java:519)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1769)
> at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1706)
> ... 97 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months