[JBoss JIRA] (ISPN-3628) Tests from Infinispan CDI module fail randomly
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-3628?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek updated ISPN-3628:
----------------------------------
Environment:
ORACLE JDK and RHEL5_x86, RHEL5_x86_64
IBM JDK,RHEL5_x86
OPEN JDK and RHEL5_x86, RHEL5_x86_64
ORACLE JDK and RHEL6_x86, RHEL6_x86_64
OPEN JDK and RHEL6_x86, RHEL6_x86_64
Solaris 10 Sparc, Oracle JDK 7
was:
ORACLE JDK and RHEL5_x86, RHEL5_x86_64
IBM JDK,RHEL5_x86
OPEN JDK and RHEL5_x86, RHEL5_x86_64
ORACLE JDK and RHEL6_x86, RHEL6_x86_64
OPEN JDK and RHEL6_x86, RHEL6_x86_64
> Tests from Infinispan CDI module fail randomly
> ----------------------------------------------
>
> Key: ISPN-3628
> URL: https://issues.jboss.org/browse/ISPN-3628
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Affects Versions: 6.0.0.Beta2, 6.0.0.CR1, 6.0.0.Final
> Environment: ORACLE JDK and RHEL5_x86, RHEL5_x86_64
> IBM JDK,RHEL5_x86
> OPEN JDK and RHEL5_x86, RHEL5_x86_64
> ORACLE JDK and RHEL6_x86, RHEL6_x86_64
> OPEN JDK and RHEL6_x86, RHEL6_x86_64
> Solaris 10 Sparc, Oracle JDK 7
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Priority: Minor
> Labels: testsuite_stability
>
> Add some links from jenkins
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
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
10 years, 7 months
[JBoss JIRA] (ISPN-3780) CLONE - InvalidateL1Command during ST should not cancel writing the entry by ST in nontx
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3780?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3780:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> CLONE - InvalidateL1Command during ST should not cancel writing the entry by ST in nontx
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-3780
> URL: https://issues.jboss.org/browse/ISPN-3780
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.3.0.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Priority: Critical
> Labels: 620
> Fix For: 6.1.0.Final
>
>
> When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry.
> Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once.
--
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
10 years, 7 months
[JBoss JIRA] (ISPN-3364) Tests from org.infinispan.atomic package fail with AssertionError
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3364?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-3364:
-------------------------------------
Changes in https://github.com/infinispan/infinispan/pull/2274 were tested to work with the following JVMs in both the new tests and MapStressTest
IBM JRE 6
{quote}
java version "1.6.0"
Java(TM) SE Runtime Environment (build pxa6460sr13ifix-20130303_02(SR13+IV37419))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr13-20130114_134867 (JIT enabled, AOT enabled)
J9VM - 20130114_134867
JIT - r9_20130108_31100
GC - 20121212_AA)
JCL - 20130303_02
{quote}
and IBM JDK 7
{quote}
java version "1.7.0"
Java(TM) SE Runtime Environment (build pxa6470sr5-20130619_01(SR5))
IBM J9 VM (build 2.6, JRE 1.7.0 Linux amd64-64 Compressed References 20130617_152572 (JIT enabled, AOT enabled)
J9VM - R26_Java726_SR5_20130617_1436_B152572
JIT - r11.b04_20130528_38954ifx1
GC - R26_Java726_SR5_20130617_1436_B152572_CMPRSS
J9CL - 20130617_152572)
JCL - 20130616_01 based on Oracle 7u25-b12
{quote}
> Tests from org.infinispan.atomic package fail with AssertionError
> -----------------------------------------------------------------
>
> Key: ISPN-3364
> URL: https://issues.jboss.org/browse/ISPN-3364
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.Alpha1
> Environment: RHEL5_x86, RHEL5_x86_64, RHEL6_x86, RHEL5_x86_64 with IBM JDK7
> Reporter: Vitalii Chepeliuk
> Assignee: William Burns
> Labels: 620
> Fix For: 6.1.0.Final
>
> Attachments: LocalDeltaAwarePassivationTest.log.zip, ReplDeltaAwarePassivationTest.log.zip
>
>
> Following tests fail from org.infinispan.atomic package
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testAtomicMap
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testDeltaAware
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testFineGrainedAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testAtomicMap2
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testDeltaAware
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testDeltaAware2
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testFineGrainedAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testFineGrainedAtomicMap2
> Add link on jenkins job https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
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
10 years, 7 months
[JBoss JIRA] (ISPN-3364) Tests from org.infinispan.atomic package fail with AssertionError
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3364?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3364:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2274
> Tests from org.infinispan.atomic package fail with AssertionError
> -----------------------------------------------------------------
>
> Key: ISPN-3364
> URL: https://issues.jboss.org/browse/ISPN-3364
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.Alpha1
> Environment: RHEL5_x86, RHEL5_x86_64, RHEL6_x86, RHEL5_x86_64 with IBM JDK7
> Reporter: Vitalii Chepeliuk
> Assignee: William Burns
> Labels: 620
> Fix For: 6.1.0.Final
>
> Attachments: LocalDeltaAwarePassivationTest.log.zip, ReplDeltaAwarePassivationTest.log.zip
>
>
> Following tests fail from org.infinispan.atomic package
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testAtomicMap
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testDeltaAware
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testFineGrainedAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testAtomicMap2
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testDeltaAware
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testDeltaAware2
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testFineGrainedAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testFineGrainedAtomicMap2
> Add link on jenkins job https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
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
10 years, 7 months
[JBoss JIRA] (ISPN-3773) State transfer thread can stop even though there are pending transfer tasks
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3773?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3773:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> State transfer thread can stop even though there are pending transfer tasks
> ---------------------------------------------------------------------------
>
> Key: ISPN-3773
> URL: https://issues.jboss.org/browse/ISPN-3773
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: nbst
> Fix For: 7.0.0.Final
>
>
> Noticed in NonTxOriginatorBecomingPrimaryOwnerTest. The state transfer thread finished the last inbound transfer task, but just before stopping another task is started. The new task doesn't prevent the state transfer thread from stopping, and the node will never request those segments (thus blocking the rebalance from ending).
> {noformat}
> 15:28:31,033 TRACE (asyncTransportThread-1,NodeC:) [InboundTransferTask] Successfully requested segments [33, 6, 7, 8, 9, 11, 13, 50, 54, 20, 52, 22, 59, 25, 24, 27, 26, 29, 28, 31] of cache ___defaultcache from node NodeA-49040
> 15:28:31,264 TRACE (remote-thread-1,NodeC:___defaultcache) [StateConsumerImpl] Adding transfer from NodeA-49040 for segments [32, 5, 6, 7, 8, 10, 12, 51, 49, 19, 21, 53, 23, 59, 25, 24, 27, 26, 28, 30]
> 15:28:31,264 TRACE (remote-thread-1,NodeC:___defaultcache) [StateConsumerImpl] Starting transfer thread: false
> 15:28:31,264 DEBUG (remote-thread-1,NodeC:___defaultcache) [StateConsumerImpl] Finished adding inbound state transfer for segments [5, 6, 7, 8, 10, 12, 19, 21, 23, 25, 24, 27, 26, 28, 30, 32, 51, 49, 53, 59] of cache ___defaultcache
> 15:28:31,264 TRACE (remote-thread-1,NodeC:___defaultcache) [StateTransferLockImpl] Signalling transaction data received for topology 41
> 15:28:31,264 TRACE (asyncTransportThread-1,NodeC:) [StateConsumerImpl] Stopping state transfer thread
> {noformat}
--
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
10 years, 7 months
[JBoss JIRA] (ISPN-3770) Incorrect Content-Type header when putting object via REST and get with different Accept
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3770?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3770:
-----------------------------------
Fix Version/s: 6.1.0.Final
> Incorrect Content-Type header when putting object via REST and get with different Accept
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-3770
> URL: https://issues.jboss.org/browse/ISPN-3770
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Jiří Holuša
> Assignee: Galder Zamarreño
> Fix For: 6.1.0.Final
>
>
> When putting serialized object via REST post and then getting it back with different Accept header (for example application/json), the retrieved data has still the "creation-time" Content-Type and data doesn't change in any way.
> I would expect retrieving nice json structure for instace.
> Code snippet:
> {code}
> public void testCustomObjectGetAcceptJSONAndXML() throws Exception{
> String fullPathKeyA = fullPathKey(KEY_A);
> TestSerializable object = new TestSerializable("CONTENT");
> ByteArrayOutputStream bout = new ByteArrayOutputStream();
> ObjectOutputStream oo = new ObjectOutputStream(bout);
> oo.writeObject(object);
> oo.flush();
> oo.close();
> byte[] byteData = bout.toByteArray();
> post(fullPathKeyA, byteData, "application/x-java-serialized-object");
> HttpResponse getJson = get(fullPathKeyA, null, HttpServletResponse.SC_OK, true, "Accept", "application/json");
> assertTrue(getJson.getHeaders("Content-type")[0].getValue().contains("application/json")); //this assertion fails
> HttpResponse getXml = get(fullPathKeyA, null, HttpServletResponse.SC_OK, true, "Accept", "application/xml");
> assertTrue(getXml.getHeaders("Content-type")[0].getValue().contains("application/xml")); //this assertion fails
> }
> {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
10 years, 7 months
[JBoss JIRA] (ISPN-3770) Incorrect Content-Type header when putting object via REST and get with different Accept
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3770?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-3770:
----------------------------------------
Hmmm, I had the chance to look into this more closely. We have [tests|https://github.com/infinispan/infinispan/blob/master/integrationtes...] where we put a custom Serializable object via Hot Rod, and we can retrieve it via REST using json/xml easily. I don't see why the same should not be possible if the serialized object was stored via REST. Reopening and assigning it to myself to investigate more deeply.
> Incorrect Content-Type header when putting object via REST and get with different Accept
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-3770
> URL: https://issues.jboss.org/browse/ISPN-3770
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Jiří Holuša
> Assignee: Mircea Markus
>
> When putting serialized object via REST post and then getting it back with different Accept header (for example application/json), the retrieved data has still the "creation-time" Content-Type and data doesn't change in any way.
> I would expect retrieving nice json structure for instace.
> Code snippet:
> {code}
> public void testCustomObjectGetAcceptJSONAndXML() throws Exception{
> String fullPathKeyA = fullPathKey(KEY_A);
> TestSerializable object = new TestSerializable("CONTENT");
> ByteArrayOutputStream bout = new ByteArrayOutputStream();
> ObjectOutputStream oo = new ObjectOutputStream(bout);
> oo.writeObject(object);
> oo.flush();
> oo.close();
> byte[] byteData = bout.toByteArray();
> post(fullPathKeyA, byteData, "application/x-java-serialized-object");
> HttpResponse getJson = get(fullPathKeyA, null, HttpServletResponse.SC_OK, true, "Accept", "application/json");
> assertTrue(getJson.getHeaders("Content-type")[0].getValue().contains("application/json")); //this assertion fails
> HttpResponse getXml = get(fullPathKeyA, null, HttpServletResponse.SC_OK, true, "Accept", "application/xml");
> assertTrue(getXml.getHeaders("Content-type")[0].getValue().contains("application/xml")); //this assertion fails
> }
> {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
10 years, 7 months
[JBoss JIRA] (ISPN-3770) Incorrect Content-Type header when putting object via REST and get with different Accept
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3770?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño reassigned ISPN-3770:
--------------------------------------
Assignee: Galder Zamarreño (was: Mircea Markus)
> Incorrect Content-Type header when putting object via REST and get with different Accept
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-3770
> URL: https://issues.jboss.org/browse/ISPN-3770
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Jiří Holuša
> Assignee: Galder Zamarreño
>
> When putting serialized object via REST post and then getting it back with different Accept header (for example application/json), the retrieved data has still the "creation-time" Content-Type and data doesn't change in any way.
> I would expect retrieving nice json structure for instace.
> Code snippet:
> {code}
> public void testCustomObjectGetAcceptJSONAndXML() throws Exception{
> String fullPathKeyA = fullPathKey(KEY_A);
> TestSerializable object = new TestSerializable("CONTENT");
> ByteArrayOutputStream bout = new ByteArrayOutputStream();
> ObjectOutputStream oo = new ObjectOutputStream(bout);
> oo.writeObject(object);
> oo.flush();
> oo.close();
> byte[] byteData = bout.toByteArray();
> post(fullPathKeyA, byteData, "application/x-java-serialized-object");
> HttpResponse getJson = get(fullPathKeyA, null, HttpServletResponse.SC_OK, true, "Accept", "application/json");
> assertTrue(getJson.getHeaders("Content-type")[0].getValue().contains("application/json")); //this assertion fails
> HttpResponse getXml = get(fullPathKeyA, null, HttpServletResponse.SC_OK, true, "Accept", "application/xml");
> assertTrue(getXml.getHeaders("Content-type")[0].getValue().contains("application/xml")); //this assertion fails
> }
> {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
10 years, 7 months
[JBoss JIRA] (ISPN-3738) Entry version gets lost during topology change -> NPE
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3738?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3738:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Entry version gets lost during topology change -> NPE
> -----------------------------------------------------
>
> Key: ISPN-3738
> URL: https://issues.jboss.org/browse/ISPN-3738
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.1.0.Final
>
>
> Replicated TX cache with WSC, A, B are in cluster, C is joining
> 0. The current CH already contains A and B as owners, C is joining (is not primary owner of anything yet). B is primary owner of K=V.
> 1. A sends PrepareCommand to B and C with put(K, V) (V is null on all nodes)
> 2. C receives PrepareCommand and responds with no versions (it is not primary owner)
> 3. topology changes on B - primary ownership of K is transfered to C
> 4. B receives PrepareCommand, responds without K's version (it is not primary)
> 5. B forwards the Prepare to C as it sees that the command has lower topology ID
> 6. C responds to B's prepare with version of K
> 7. K version is *not* added to B's response, B responds to A
> 8. A finds out that topology has changed, forwards prepare to C
> 9. C responds to C's prepare with version of K
> 10. A receives C's response, but the versions are not added to transaction
> 11. A sends out CommitCommand missing version of K
> 12. all nodes record K=V without version as usual ImmortalCacheEntry
> 13. the next time we try to increase version of K=V, we fail with NPE in SimpleClusteredVersionGenerator (actually when it tries to throw IllegalArgumentException because the null version is unexpected version class)
--
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
10 years, 7 months