[JBoss JIRA] (ISPN-7901) Postgres drop-on-exit remove index fails
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7901?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-7901:
-------------------------------
Status: Open (was: New)
> Postgres drop-on-exit remove index fails
> ----------------------------------------
>
> Key: ISPN-7901
> URL: https://issues.jboss.org/browse/ISPN-7901
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 9.1.0.Alpha1
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.1.0.Beta1
>
>
> When drop-on-exit is true and indexing is enabled the following error occurs:
> {code:java}
> ERROR: ISPN008011: Error while creating table; used DDL statement: 'DROP INDEX "test_table_postgres_timestamp_index" ON "test_table_postgres"'
> org.postgresql.util.PSQLException: ERROR: syntax error at or near "ON"
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7858) Investigate parallel processing of message batches
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7858?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-7858:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/5184
> Investigate parallel processing of message batches
> --------------------------------------------------
>
> Key: ISPN-7858
> URL: https://issues.jboss.org/browse/ISPN-7858
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 9.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
>
> Currently, message batches are handled _sequentially_ by Infinispan, ie. a batch of messages 1-5 processes message 1 first, then message 2 etc.
> This causes the processing of message 5 to start only when the 4 previous messages have been processed.
> Investigate parallelization of this processing. One possible implementation could be for example similar to the TriCache impl [4]:
> * Use _application batches_: multiple GET requests and/or GET responses could be wrapped into a single application batch
> * Have a separate thread pool with N threads (configurable) and a queue for PUTs and GET responses
> * Process the GET requests inline (in the same thread), and (in parallel) pass the application batch on to a thread pool for processing of GET responses and/or PUT requests.
> [1] https://github.com/belaban/IspnPerfTest/blob/master/src/org/cache/impl/tr...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7858) Investigate parallel processing of message batches
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7858?page=com.atlassian.jira.plugin.... ]
Ryan Emerson commented on ISPN-7858:
------------------------------------
[~dan.berindei] Sorry, accidentally clicked "hand over to development", not sure how to undo
> Investigate parallel processing of message batches
> --------------------------------------------------
>
> Key: ISPN-7858
> URL: https://issues.jboss.org/browse/ISPN-7858
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 9.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
>
> Currently, message batches are handled _sequentially_ by Infinispan, ie. a batch of messages 1-5 processes message 1 first, then message 2 etc.
> This causes the processing of message 5 to start only when the 4 previous messages have been processed.
> Investigate parallelization of this processing. One possible implementation could be for example similar to the TriCache impl [4]:
> * Use _application batches_: multiple GET requests and/or GET responses could be wrapped into a single application batch
> * Have a separate thread pool with N threads (configurable) and a queue for PUTs and GET responses
> * Process the GET requests inline (in the same thread), and (in parallel) pass the application batch on to a thread pool for processing of GET responses and/or PUT requests.
> [1] https://github.com/belaban/IspnPerfTest/blob/master/src/org/cache/impl/tr...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7858) Investigate parallel processing of message batches
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7858?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-7858:
-------------------------------
Status: Open (was: New)
> Investigate parallel processing of message batches
> --------------------------------------------------
>
> Key: ISPN-7858
> URL: https://issues.jboss.org/browse/ISPN-7858
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 9.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
>
> Currently, message batches are handled _sequentially_ by Infinispan, ie. a batch of messages 1-5 processes message 1 first, then message 2 etc.
> This causes the processing of message 5 to start only when the 4 previous messages have been processed.
> Investigate parallelization of this processing. One possible implementation could be for example similar to the TriCache impl [4]:
> * Use _application batches_: multiple GET requests and/or GET responses could be wrapped into a single application batch
> * Have a separate thread pool with N threads (configurable) and a queue for PUTs and GET responses
> * Process the GET requests inline (in the same thread), and (in parallel) pass the application batch on to a thread pool for processing of GET responses and/or PUT requests.
> [1] https://github.com/belaban/IspnPerfTest/blob/master/src/org/cache/impl/tr...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7901) Postgres drop-on-exit remove index fails
by Ryan Emerson (JIRA)
Ryan Emerson created ISPN-7901:
----------------------------------
Summary: Postgres drop-on-exit remove index fails
Key: ISPN-7901
URL: https://issues.jboss.org/browse/ISPN-7901
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 9.1.0.Alpha1
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Fix For: 9.1.0.Beta1
When drop-on-exit is true and indexing is enabled the following error occurs:
{code:java}
ERROR: ISPN008011: Error while creating table; used DDL statement: 'DROP INDEX "test_table_postgres_timestamp_index" ON "test_table_postgres"'
org.postgresql.util.PSQLException: ERROR: syntax error at or near "ON"
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7858) Investigate parallel processing of message batches
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/ISPN-7858?page=com.atlassian.jira.plugin.... ]
Bela Ban updated ISPN-7858:
---------------------------
Description:
Currently, message batches are handled _sequentially_ by Infinispan, ie. a batch of messages 1-5 processes message 1 first, then message 2 etc.
This causes the processing of message 5 to start only when the 4 previous messages have been processed.
Investigate parallelization of this processing. One possible implementation could be for example similar to the TriCache impl [4]:
* Use _application batches_: multiple GET requests and/or GET responses could be wrapped into a single application batch
* Have a separate thread pool with N threads (configurable) and a queue for PUTs and GET responses
* Process the GET requests inline (in the same thread), and (in parallel) pass the application batch on to a thread pool for processing of GET responses and/or PUT requests.
[1] https://github.com/belaban/IspnPerfTest/blob/master/src/org/cache/impl/tr...
> Investigate parallel processing of message batches
> --------------------------------------------------
>
> Key: ISPN-7858
> URL: https://issues.jboss.org/browse/ISPN-7858
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 9.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
>
> Currently, message batches are handled _sequentially_ by Infinispan, ie. a batch of messages 1-5 processes message 1 first, then message 2 etc.
> This causes the processing of message 5 to start only when the 4 previous messages have been processed.
> Investigate parallelization of this processing. One possible implementation could be for example similar to the TriCache impl [4]:
> * Use _application batches_: multiple GET requests and/or GET responses could be wrapped into a single application batch
> * Have a separate thread pool with N threads (configurable) and a queue for PUTs and GET responses
> * Process the GET requests inline (in the same thread), and (in parallel) pass the application batch on to a thread pool for processing of GET responses and/or PUT requests.
> [1] https://github.com/belaban/IspnPerfTest/blob/master/src/org/cache/impl/tr...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7779) State transfer does not work with protobuf encoded entities
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-7779?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-7779:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1458500, https://bugzilla.redhat.com/show_bug.cgi?id=1459157
Bugzilla Update: Perform
> State transfer does not work with protobuf encoded entities
> -----------------------------------------------------------
>
> Key: ISPN-7779
> URL: https://issues.jboss.org/browse/ISPN-7779
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 9.0.0.Final
> Reporter: AHMAD ELABIARY
> Assignee: Adrian Nistor
> Fix For: 9.1.0.Final, 8.2.7.Final, 9.0.2.Final
>
>
> I am currently testing remote deployment of JBoss Data Grid 7.1 with a 3-node replicated cluster.
> Items stored in the replicated cache are protobuf encoded and indexed. I have enabled global-state persistence on each of the cluster nodes to ensure that the protobuf schema cache is not purged on startup. However, when state-transfer occurs to a node joining the cluster, the transfer triggers an array of exceptions as shown below.
> If i then kill the nodes transferring state to this erroring new joiner, the new joiner node continues to start-up and only at that point is this log message show
> {code:java}
> 15:54:19,991 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-4)
> DGISPN0001: Started ___protobuf_metadata cache from clustered container
> {code}
> It seems as through the protobuf metadata cache starts after the configured caches which means that during their startup they do not have access to the persisted schema
> *State Transfer Exception*
> {code:java}
> 2017-04-28 15:03:08,036 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (stateTransferExecutor-thread--p7-t14) ISPN000136: Error executing command PutKeyValueCommand, writing keys [[B0x4A0E4C45494C4757..[16]]: org.hibernate.search.bridge.BridgeException: Exception while calling bridge#set
> entity class: org.infinispan.query.remote.impl.indexing.ProtobufValueWrapper
> field bridge: org.infinispan.query.remote.impl.indexing.ProtobufValueWrapperFieldBridge@44f36069
> at org.hibernate.search.bridge.util.impl.ContextualExceptionBridgeHelper.buildBridgeException(ContextualExceptionBridgeHelper.java:103)
> at org.hibernate.search.bridge.util.impl.ContextualExceptionBridgeHelper$OneWayConversionContextImpl.set(ContextualExceptionBridgeHelper.java:137)
> at org.hibernate.search.engine.spi.DocumentBuilderIndexedEntity.buildDocumentFieldForClassBridges(DocumentBuilderIndexedEntity.java:890)
> at org.hibernate.search.engine.spi.DocumentBuilderIndexedEntity.buildDocumentFields(DocumentBuilderIndexedEntity.java:454)
> at org.hibernate.search.engine.spi.DocumentBuilderIndexedEntity.getDocument(DocumentBuilderIndexedEntity.java:391)
> at org.hibernate.search.engine.spi.DocumentBuilderIndexedEntity.createUpdateWork(DocumentBuilderIndexedEntity.java:301)
> at org.hibernate.search.engine.spi.DocumentBuilderIndexedEntity.addWorkToQueue(DocumentBuilderIndexedEntity.java:243)
> at org.hibernate.search.engine.impl.WorkPlan$PerEntityWork.enqueueLuceneWork(WorkPlan.java:520)
> at org.hibernate.search.engine.impl.WorkPlan$PerClassWork.enqueueLuceneWork(WorkPlan.java:282)
> at org.hibernate.search.engine.impl.WorkPlan.getPlannedLuceneWork(WorkPlan.java:154)
> at org.hibernate.search.backend.impl.WorkQueue.prepareWorkPlan(WorkQueue.java:114)
> at org.hibernate.search.backend.impl.BatchedQueueingProcessor.prepareWorks(BatchedQueueingProcessor.java:57)
> at org.hibernate.search.backend.impl.PerTransactionWorker.performWork(PerTransactionWorker.java:86)
> at org.infinispan.query.backend.QueryInterceptor.performSearchWorks(QueryInterceptor.java:241)
> at org.infinispan.query.backend.QueryInterceptor.performSearchWork(QueryInterceptor.java:235)
> at org.infinispan.query.backend.QueryInterceptor.updateIndexes(QueryInterceptor.java:228)
> at org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(QueryInterceptor.java:457)
> at org.infinispan.query.backend.QueryInterceptor.lambda$visitPutKeyValueCommand$0(QueryInterceptor.java:154)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(BaseAsyncInterceptor.java:108)
> at org.infinispan.query.backend.QueryInterceptor.visitPutKeyValueCommand(QueryInterceptor.java:154)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:79)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:57)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitNonTxDataWriteCommand(AbstractLockingInterceptor.java:107)
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitDataWriteCommand(NonTransactionalLockingInterceptor.java:39)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:77)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:79)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:57)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:397)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:340)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:123)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:79)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:57)
> at org.infinispan.interceptors.impl.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:164)
> at org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:153)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:79)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:57)
> at org.infinispan.interceptors.impl.IsMarshallableInterceptor.visitPutKeyValueCommand(IsMarshallableInterceptor.java:49)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:79)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenApply(BaseAsyncInterceptor.java:77)
> at org.infinispan.interceptors.compat.BaseTypeConverterInterceptor.visitPutKeyValueCommand(BaseTypeConverterInterceptor.java:82)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:79)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:126)
> at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:92)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:59)
> at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:53)
> at org.infinispan.interceptors.DDAsyncInterceptor.visitPutKeyValueCommand(DDAsyncInterceptor.java:59)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:79)
> at org.infinispan.interceptors.DDAsyncInterceptor.visitCommand(DDAsyncInterceptor.java:49)
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:282)
> at org.infinispan.statetransfer.StateConsumerImpl.doApplyState(StateConsumerImpl.java:621)
> at org.infinispan.statetransfer.StateConsumerImpl.applyChunk(StateConsumerImpl.java:589)
> at org.infinispan.statetransfer.StateConsumerImpl.access$000(StateConsumerImpl.java:93)
> at org.infinispan.statetransfer.StateConsumerImpl$1.run(StateConsumerImpl.java:552)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalArgumentException: Message descriptor not found : "******** I HAVE MASKED THIS VALUE *********"
> at org.infinispan.protostream.impl.SerializationContextImpl.getMessageDescriptor(SerializationContextImpl.java:166)
> at org.infinispan.query.remote.impl.indexing.WrappedMessageTagHandler.onTag(WrappedMessageTagHandler.java:65)
> at org.infinispan.protostream.ProtobufParser.parseMessage(ProtobufParser.java:75)
> at org.infinispan.protostream.ProtobufParser.parseInternal(ProtobufParser.java:57)
> at org.infinispan.protostream.ProtobufParser.parse(ProtobufParser.java:44)
> at org.infinispan.query.remote.impl.indexing.ProtobufValueWrapperFieldBridge.decodeAndIndex(ProtobufValueWrapperFieldBridge.java:58)
> at org.infinispan.query.remote.impl.indexing.ProtobufValueWrapperFieldBridge.set(ProtobufValueWrapperFieldBridge.java:46)
> at org.hibernate.search.bridge.util.impl.ContextualExceptionBridgeHelper$OneWayConversionContextImpl.set(ContextualExceptionBridgeHelper.java:134)
> ... 56 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months