[JBoss JIRA] (ISPN-2342) The x-site implementation needs an inter-site state transfer mechanism
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2342?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2342:
--------------------------------
Fix Version/s: (was: 6.0.0.Final)
(was: 6.0.0.Beta1)
> The x-site implementation needs an inter-site state transfer mechanism
> ----------------------------------------------------------------------
>
> Key: ISPN-2342
> URL: https://issues.jboss.org/browse/ISPN-2342
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cross-Site Replication
> Reporter: Erik Salter
> Assignee: Erik Salter
> Labels: jdg62
>
> To bring up a new site or recover a failed site, I need an inter-site state transfer mechanism for synchronizing keys.
> Note that initially, this should a manual process that is invoked on one site to one of its configured backups.
> This should be based on the non-blocking state transfer mechanism for consistency.
> The pseudo-design may look similar to the following:
> - Manually invokable, background thread
> - Since the bridge end is open, there are writes happening to keys. Keep track of the puts/removes on the main data owner.
> - Iterate through the key set.
> - If the key has already been modified since the process started, discard.
> - Else synchronously write the key value in a TX context
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (ISPN-3175) Upgrade the java hotrod client to support remote querying
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3175?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3175:
--------------------------------
Fix Version/s: 6.0.0.Alpha3
(was: 6.0.0.Alpha2)
> Upgrade the java hotrod client to support remote querying
> ---------------------------------------------------------
>
> Key: ISPN-3175
> URL: https://issues.jboss.org/browse/ISPN-3175
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Mircea Markus
> Assignee: Adrian Nistor
> Priority: Blocker
> Labels: jdg62
> Fix For: 6.0.0.Alpha3, 6.0.0.Final
>
>
> Once we'll have ISPN-3169(define query fluent API), ISPN-3173(add a new query operation over hotrod) and ISPN-3174(String-based query language) in place, this is about connecting the dots: invoke the remote query on the server and present the result to the user.
> h3.On the client side
> As described in ISPN-3173, the query is sent as a byte[] to the server: the payload.
> The request payload is query specific (not defined in the HR protocol) and at this stage has the following format: [Q_TYPE] [QUERY_ST] [FIRST_INDEX] [PAGE_SIZE]. This format accommodates the remote query requirements as defined in ISPN-3169.
> - Q_TYPE (protobuf's byte) and query identifier, 1 for JPAQL (this is the query type we'll support). In future we'll add different query types as well.
> - QUERY_STRING (protobuf's string)- JPAQL string generated by the fluent API (ISPN-3169). Parameters are encoded in this string (vs being sent separately)
> - FIRST_INDEX + PAGE_SIZE (protobuf's int)- used for paginating/iterating over the result set.
> HR response: [HR_SUCESS_FLAG] [payload]
> PAYLOAD = [NUM_EL] [PROJ_SIZE] [ELEMENTS]
> - even though at this stage we don't support projections (see ISPN-3169) PROJ_SIZE is added for future compatibility when projection will be supported.
> Note that the payload for both request and response should be marshalled with protobuf as this information is read/written over multiple clients.
> h3.On the server side
> - the server module reads the query operation and the payload (byte[])
> - invokes QueryFacade.query(byte[]) : byte[]
> - QueryFacade is an interface defined in the server modules
> - has an implementation in the remote-query module (new modules)
> - the reason for adding this module: RemoteQueryImpl cannot be in the server modules (ASL) as it has a dependency on the query module (LGPL) which would "contaminate" the server module. Another option would be to merge it in the query module itself, but doesn't feel like a natural fit as its responsibility is serializing data (protobuf). OTOH if it is small we can merge it there so that we don't add a new module to the system?
>
> For an overview on the remote querying see https://community.jboss.org/wiki/QueryingDesignInInfinispan
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (ISPN-2971) AsyncStoreStressTest is broken
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2971?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2971:
--------------------------------
Fix Version/s: (was: 6.0.0.Alpha2)
> AsyncStoreStressTest is broken
> ------------------------------
>
> Key: ISPN-2971
> URL: https://issues.jboss.org/browse/ISPN-2971
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.2.5.Final
> Reporter: Adrian Nistor
> Assignee: Galder Zamarreño
> Labels: testsuite_stability
> Fix For: 6.0.0.Final
>
>
> This test is not run during normal test suite, but we still need to fix this failure and the leaked threads (see System.exit(0) in main method):
> {code}
> testReadWriteRemove(org.infinispan.stress.AsyncStoreStressTest) Time elapsed: 72.377 sec <<< FAILURE!
> java.lang.UnsupportedOperationException
> at java.util.AbstractMap$SimpleImmutableEntry.setValue(AbstractMap.java:726)
> at org.infinispan.stress.AsyncStoreStressTest.testReadWriteRemove(AsyncStoreStressTest.java:140)
> 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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months