Re: [infinispan-dev] infinispan 5.2.0.Beta3
I think we need to get Sanne's POV on that. I had a brief look into it and the fix looks good, but not sure if there are better ways to fix it. On Oct 26, 2012, at 7:42 PM, Ales Justin ales.jus...@gmail.com wrote: What about today's ISPN-2448? On Oct 26, 2012, at 7:38 PM, Mircea Markus mircea.mar...@jboss.com wrote: The fix for lock leaks[1] - blocker - hasn't been integrated yet as it needs more testing (Manik) and more time to review (Dan). Manik suggested testing should be ready by Mon, so I'll cut the release then. This would also allow time to finish integrating other stuff in the PR queue, in particular Vladimir's Map/Reduce cancelation(Mircea) [2] [1] ISPN-2381 Locks are removed even if not successfully unlocked [2] ISPN-1042 - Enable distributed and Map/Reduce task interruption/cancellation On 25 Oct 2012, at 17:37, Mircea Markus wrote: Hi, We have a lot of pull requests pending. Until Beta3 is released, can we please focus on these and slow down the development for now. I've grouped them as follows. Please feel free to shuffle them around/ ask for more feedback if you think appropriate, but please take ownership of them and make sure they get integrated. Dan: ISPN-2373 State transfer does not end because some segments are erroneously reported as unreceived Lookup optimisation in TransactionTable.getLocalTransaction and cleanup in BaseRpcInterceptor hierarchy ISPN-2381 Locks are removed even if not successfully unlocked Adrian: ISPN-2318 Reimplement a Topology-Aware Consistent Hash Galder: ISPN-2429 Cache restart still doesn't work properly for query-enabled caches JBQA-6819 - Added the ant script which merges and generates jacoco code coverage report file. ISPN-2412 Allow specifying container and cache when connecting via CLI Tristan: [5.1.x] ISPN-2414 Fixes to reduce memory consumption of local caches ISPN-2414 Fixes to reduce memory consumption of local caches Mircea: ISPN-2440 JGroupsTransport.invokeRemotely throws SuspectExceptions even ... Fix DummyInMemoryCacheStoreConfigurationBuilder#read() ISPN-2371 The global component registry fails to start components ISPN-2443 - tests are added for reproducing/verifying the issue. ISPN-2386 - Test reproducing/verifying the issue with ClassCastingException in case of CacheLoader usage (with storeAsBinary conf). ISPN-1042 - Enable distributed and Map/Reduce task interruption/cancellation Vladimir: ISPN-2409 - Reproduction/verification case for NotSerializableException occurence. Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Testsuite: hanging TestNG, CDI proken
Hi Sanne, sorry for my interfering in - I was lately working on CDI testsuite - evaluating the coverage, etc. and actually on my local environment as well as on Jenkins, the CDI integration tests are passing properly. I've run the tests several times, but I hadn't got the test hangouts as you have mentioned and all tests are passing on my side without failures. I've tried also the testsuite execution with TestNG version 6.7 and it is fine as well. I just thought, maybe there is something wrong with your testsuite setup or environment (just thoughts)? Best regards, Anna. - Original Message - From: Sanne Grinovero sa...@infinispan.org To: infinispan -Dev List infinispan-dev@lists.jboss.org Sent: Sunday, October 28, 2012 11:12:32 AM Subject: [infinispan-dev] Testsuite: hanging TestNG, CDI proken Hello all, besides having regular failures, I also experienced occasional hangs while running the testsuite; in some cases I found the following stack which suggests a TestNG bug: pool-3-thread-14 prio=10 tid=0x7f0d84632000 nid=0x1ce5 runnable [0x7f0d58a36000] java.lang.Thread.State: RUNNABLE at java.util.HashMap.put(HashMap.java:374) at org.testng.SuiteRunner.runTest(SuiteRunner.java:320) at org.testng.SuiteRunner.access$000(SuiteRunner.java:34) at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351) at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Even when taking multiple dumps that thread is still in the same loop, and having a single CPU stuck at 100% I'm guessing the HashMap was being used in some unsafe way regarding concurrency; we're using the first minor version of TestNG which ever supported parallel testsuite invocations so that might not be very solid. Not sure why, but upgrading TestNG from 5.14.10 to 6.7 seems to resolve the problem. Now I wish I could send a pull request, but even skipping just the core testsuite (which always fails for me even in non-parallel mode) many other modules are broken both with and without my patches, so I'm dropping my experiments as I won't send any pull requests if the tests can't back my changes up. As an example the CDI integration is: Tests run: 247, Failures: 102, Errors: 0, Skipped: 143 ...which means 2 tests are fine. Cheers, Sanne ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Testsuite: hanging TestNG, CDI proken
On Oct 29, 2012, at 8:59 AM, Anna Manukyan amanu...@redhat.com wrote: Hi Sanne, sorry for my interfering in - I was lately working on CDI testsuite - evaluating the coverage, etc. and actually on my local environment as well as on Jenkins, the CDI integration tests are passing properly. I've run the tests several times, but I hadn't got the test hangouts as you have mentioned and all tests are passing on my side without failures. I've tried also the testsuite execution with TestNG version 6.7 and it is fine as well. I just thought, maybe there is something wrong with your testsuite setup or environment (just thoughts)? We've seen CDI testsuite fail massively at points due to some bug in TestNG, and although I cannot find the exact email right now, I thought long term the idea was to move to JUnit. Example: https://infinispan.ci.cloudbees.com/job/Infinispan-master-JDK6-tcp/867/#showFailuresLink @Sanne, if you see tests failing (apart from the massive CDI failure thing, if it looks like the failures in the link above), create a JIRA and assign it to the right person. The problem is disabling the tests which is a bit tedious if you're doing per JIRA, but you could batch them up. Best regards, Anna. - Original Message - From: Sanne Grinovero sa...@infinispan.org To: infinispan -Dev List infinispan-dev@lists.jboss.org Sent: Sunday, October 28, 2012 11:12:32 AM Subject: [infinispan-dev] Testsuite: hanging TestNG, CDI proken Hello all, besides having regular failures, I also experienced occasional hangs while running the testsuite; in some cases I found the following stack which suggests a TestNG bug: pool-3-thread-14 prio=10 tid=0x7f0d84632000 nid=0x1ce5 runnable [0x7f0d58a36000] java.lang.Thread.State: RUNNABLE at java.util.HashMap.put(HashMap.java:374) at org.testng.SuiteRunner.runTest(SuiteRunner.java:320) at org.testng.SuiteRunner.access$000(SuiteRunner.java:34) at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351) at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Even when taking multiple dumps that thread is still in the same loop, and having a single CPU stuck at 100% I'm guessing the HashMap was being used in some unsafe way regarding concurrency; we're using the first minor version of TestNG which ever supported parallel testsuite invocations so that might not be very solid. Not sure why, but upgrading TestNG from 5.14.10 to 6.7 seems to resolve the problem. Now I wish I could send a pull request, but even skipping just the core testsuite (which always fails for me even in non-parallel mode) many other modules are broken both with and without my patches, so I'm dropping my experiments as I won't send any pull requests if the tests can't back my changes up. As an example the CDI integration is: Tests run: 247, Failures: 102, Errors: 0, Skipped: 143 ...which means 2 tests are fine. Cheers, Sanne ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] iOS client lib
HEllo, For a WebSocket demo, I created the following iOS lib (basically a port of the infinispan-ws.js file) https://github.com/matzew/infinispan-ios. I was wondering if there is interest in moving that project over to the umbrella infinispan repo at github. Thx, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Testsuite: hanging TestNG, CDI proken
Yes, I have encountered the same failures as well, but this was before I've updated the TestNG jar version from 5.14.6 to 5.14.10 in pom.xml for cdi/extension module. In pom.xml for cdi/extension module there is separate TestNG dependency declared with it's own version which is non-inherited from parent's pom.xml. version.testng.arquillian5.14.6/version.testng.arquillian The last build on master was done on 4th of October which is before my upgrade to 5.14.10 done of 15th of October. Would it be possible to run the build on master one more time, to see whether the update fixed the issue? - Original Message - From: Galder Zamarreño gal...@redhat.com To: infinispan -Dev List infinispan-dev@lists.jboss.org Cc: Sanne Grinovero sgrin...@redhat.com Sent: Monday, October 29, 2012 10:10:23 AM Subject: Re: [infinispan-dev] Testsuite: hanging TestNG, CDI proken On Oct 29, 2012, at 8:59 AM, Anna Manukyan amanu...@redhat.com wrote: Hi Sanne, sorry for my interfering in - I was lately working on CDI testsuite - evaluating the coverage, etc. and actually on my local environment as well as on Jenkins, the CDI integration tests are passing properly. I've run the tests several times, but I hadn't got the test hangouts as you have mentioned and all tests are passing on my side without failures. I've tried also the testsuite execution with TestNG version 6.7 and it is fine as well. I just thought, maybe there is something wrong with your testsuite setup or environment (just thoughts)? We've seen CDI testsuite fail massively at points due to some bug in TestNG, and although I cannot find the exact email right now, I thought long term the idea was to move to JUnit. Example: https://infinispan.ci.cloudbees.com/job/Infinispan-master-JDK6-tcp/867/#showFailuresLink @Sanne, if you see tests failing (apart from the massive CDI failure thing, if it looks like the failures in the link above), create a JIRA and assign it to the right person. The problem is disabling the tests which is a bit tedious if you're doing per JIRA, but you could batch them up. Best regards, Anna. - Original Message - From: Sanne Grinovero sa...@infinispan.org To: infinispan -Dev List infinispan-dev@lists.jboss.org Sent: Sunday, October 28, 2012 11:12:32 AM Subject: [infinispan-dev] Testsuite: hanging TestNG, CDI proken Hello all, besides having regular failures, I also experienced occasional hangs while running the testsuite; in some cases I found the following stack which suggests a TestNG bug: pool-3-thread-14 prio=10 tid=0x7f0d84632000 nid=0x1ce5 runnable [0x7f0d58a36000] java.lang.Thread.State: RUNNABLE at java.util.HashMap.put(HashMap.java:374) at org.testng.SuiteRunner.runTest(SuiteRunner.java:320) at org.testng.SuiteRunner.access$000(SuiteRunner.java:34) at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351) at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Even when taking multiple dumps that thread is still in the same loop, and having a single CPU stuck at 100% I'm guessing the HashMap was being used in some unsafe way regarding concurrency; we're using the first minor version of TestNG which ever supported parallel testsuite invocations so that might not be very solid. Not sure why, but upgrading TestNG from 5.14.10 to 6.7 seems to resolve the problem. Now I wish I could send a pull request, but even skipping just the core testsuite (which always fails for me even in non-parallel mode) many other modules are broken both with and without my patches, so I'm dropping my experiments as I won't send any pull requests if the tests can't back my changes up. As an example the CDI integration is: Tests run: 247, Failures: 102, Errors: 0, Skipped: 143 ...which means 2 tests are fine. Cheers, Sanne ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] broken lazy query iteration
Correct, the DocumentExtractor contract expects the absolute index. It
looks like a bug in how ISPN's Query module use it.
Emmanuel
On Fri 2012-10-26 16:09, Ales Justin wrote:
After searching for the needed in haystack, I finally found the problem.
(not to mention complete lack of tests for this *basic* feature ...)
The problem is with queries with offset when you iterate over them -- offset
is never taken into account.
There are two possible fixes -- as I see them.
1) In HS:
DocumentExtractorImpl::extract takes into account firstIndex
public EntityInfo extract(int scoreDocIndex) throws IOException {
int docId = queryHits.docId( firstIndex + scoreDocIndex );
Document document = extractDocument( fistIndex + scoreDocIndex
);
2) LazyIterator in Infinispan-Query applies the offset:
protected EntityInfo loadEntityInfo(int index) {
try {
return extractor.extract(extractor.getFirstIndex() + index);
---
Since those methods are exposed in DocumentExtractor,
I would guess they were meant for external code to use them,
instead of putting this logic into extractor itself.
So, I'll go ahead and provide a patch for (2).
-Ales
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Testsuite: hanging TestNG, CDI proken
On 29 Oct 2012, at 09:10, Galder Zamarreño wrote: On Oct 29, 2012, at 8:59 AM, Anna Manukyan amanu...@redhat.com wrote: Hi Sanne, sorry for my interfering in - I was lately working on CDI testsuite - evaluating the coverage, etc. and actually on my local environment as well as on Jenkins, the CDI integration tests are passing properly. I've run the tests several times, but I hadn't got the test hangouts as you have mentioned and all tests are passing on my side without failures. I've tried also the testsuite execution with TestNG version 6.7 and it is fine as well. I just thought, maybe there is something wrong with your testsuite setup or environment (just thoughts)? We've seen CDI testsuite fail massively at points due to some bug in TestNG, and although I cannot find the exact email right now, I thought long term the idea was to move to JUnit. Switching to JUnit won't happen very soon unfortunately, so upgrading TestNG should still be done that we won't have this kind of issues. I'll take a look at upgrading TestNG - now that we have Jenkins up and running (thanks Galder!). Example: https://infinispan.ci.cloudbees.com/job/Infinispan-master-JDK6-tcp/867/#showFailuresLink @Sanne, if you see tests failing (apart from the massive CDI failure thing, if it looks like the failures in the link above), create a JIRA and assign it to the right person. The problem is disabling the tests which is a bit tedious if you're doing per JIRA, but you could batch them up. Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] broken lazy query iteration
What's the design decision behind this?
As DE has all the info, it could easily hide the offset (and max) into impl
details.
-Ales
On Oct 29, 2012, at 11:14 AM, Emmanuel Bernard emman...@hibernate.org wrote:
Correct, the DocumentExtractor contract expects the absolute index. It
looks like a bug in how ISPN's Query module use it.
Emmanuel
On Fri 2012-10-26 16:09, Ales Justin wrote:
After searching for the needed in haystack, I finally found the problem.
(not to mention complete lack of tests for this *basic* feature ...)
The problem is with queries with offset when you iterate over them -- offset
is never taken into account.
There are two possible fixes -- as I see them.
1) In HS:
DocumentExtractorImpl::extract takes into account firstIndex
public EntityInfo extract(int scoreDocIndex) throws IOException {
int docId = queryHits.docId( firstIndex + scoreDocIndex );
Document document = extractDocument( fistIndex + scoreDocIndex
);
2) LazyIterator in Infinispan-Query applies the offset:
protected EntityInfo loadEntityInfo(int index) {
try {
return extractor.extract(extractor.getFirstIndex() + index);
---
Since those methods are exposed in DocumentExtractor,
I would guess they were meant for external code to use them,
instead of putting this logic into extractor itself.
So, I'll go ahead and provide a patch for (2).
-Ales
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Testsuite: hanging TestNG, CDI proken
On 29 October 2012 08:59, Anna Manukyan amanu...@redhat.com wrote: Hi Sanne, sorry for my interfering in - I was lately working on CDI testsuite - evaluating the coverage, etc. and actually on my local environment as well as on Jenkins, the CDI integration tests are passing properly. Hi Anna, I wouldn't call that interfering, it's exactly the kind of feedback I was looking for. I just checked master again, and it still failed for me. This is the stack I have in all tests, in case it helps: java.lang.NullPointerException at org.jboss.arquillian.testng.Arquillian.arquillianAfterClass(Arquillian.java:82) 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:74) at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:525) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:202) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:130) at org.testng.internal.TestMethodWorker.invokeAfterClassMethods(TestMethodWorker.java:222) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.runWorkers(TestRunner.java:1147) at org.testng.TestRunner.privateRun(TestRunner.java:749) at org.testng.TestRunner.run(TestRunner.java:600) at org.testng.SuiteRunner.runTest(SuiteRunner.java:317) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:312) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:274) at org.testng.SuiteRunner.run(SuiteRunner.java:223) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1039) at org.testng.TestNG.runSuitesLocally(TestNG.java:964) at org.testng.TestNG.run(TestNG.java:900) at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77) Anyway, whatever the state of CDI that looks like a separate problem; I can't run the core testsuite reliably with this version of TestNG; from Vladimir's comment I guess we can't upgrade easily so I'm opening ISPN-2450. Cheers, Sanne I've run the tests several times, but I hadn't got the test hangouts as you have mentioned and all tests are passing on my side without failures. I've tried also the testsuite execution with TestNG version 6.7 and it is fine as well. I just thought, maybe there is something wrong with your testsuite setup or environment (just thoughts)? Best regards, Anna. - Original Message - From: Sanne Grinovero sa...@infinispan.org To: infinispan -Dev List infinispan-dev@lists.jboss.org Sent: Sunday, October 28, 2012 11:12:32 AM Subject: [infinispan-dev] Testsuite: hanging TestNG, CDI proken Hello all, besides having regular failures, I also experienced occasional hangs while running the testsuite; in some cases I found the following stack which suggests a TestNG bug: pool-3-thread-14 prio=10 tid=0x7f0d84632000 nid=0x1ce5 runnable [0x7f0d58a36000] java.lang.Thread.State: RUNNABLE at java.util.HashMap.put(HashMap.java:374) at org.testng.SuiteRunner.runTest(SuiteRunner.java:320) at org.testng.SuiteRunner.access$000(SuiteRunner.java:34) at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351) at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Even when taking multiple dumps that thread is still in the same loop, and having a single CPU stuck at 100% I'm guessing the HashMap was being used in some unsafe way regarding concurrency; we're using the first minor version of TestNG which ever supported parallel testsuite invocations so that might not be very solid. Not sure why, but upgrading TestNG from 5.14.10 to 6.7 seems to resolve the problem. Now I wish I could send a pull request, but even skipping just the core testsuite (which always fails for me even in non-parallel mode) many other modules are broken both with and without my patches, so I'm dropping my experiments as I won't send any pull requests if the tests can't back my changes up. As an example the CDI integration is: Tests run: 247, Failures: 102, Errors: 0, Skipped: 143 ...which means 2 tests are fine. Cheers, Sanne
Re: [infinispan-dev] Testsuite: hanging TestNG, CDI proken
For what it's worth, I just created a branch with:
* TestNG 6.7 as a dependency in parent/pom.xml (so all modules use this)
* Updated cdi/extension/pom.xml to use ${version.testng} rather than
${version.testng.arquillian} - so it too now uses TestNG 6.7.
Ran tests.
Results from tests in cdi/extension:
Results :
Tests run: 60, Failures: 0, Errors: 0, Skipped: 0
Anyone want a pull req? ;)
- M
On 29 Oct 2012, at 16:06, Sanne Grinovero sa...@infinispan.org wrote:
On 29 October 2012 08:59, Anna Manukyan amanu...@redhat.com wrote:
Hi Sanne,
sorry for my interfering in - I was lately working on CDI testsuite -
evaluating the coverage, etc. and actually on my local environment as well
as on Jenkins, the CDI integration tests are passing properly.
Hi Anna,
I wouldn't call that interfering, it's exactly the kind of feedback I
was looking for. I just checked master again, and it still failed for
me.
This is the stack I have in all tests, in case it helps:
java.lang.NullPointerException
at
org.jboss.arquillian.testng.Arquillian.arquillianAfterClass(Arquillian.java:82)
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:74)
at
org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:525)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:202)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:130)
at
org.testng.internal.TestMethodWorker.invokeAfterClassMethods(TestMethodWorker.java:222)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112)
at org.testng.TestRunner.runWorkers(TestRunner.java:1147)
at org.testng.TestRunner.privateRun(TestRunner.java:749)
at org.testng.TestRunner.run(TestRunner.java:600)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:317)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:312)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:274)
at org.testng.SuiteRunner.run(SuiteRunner.java:223)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1039)
at org.testng.TestNG.runSuitesLocally(TestNG.java:964)
at org.testng.TestNG.run(TestNG.java:900)
at
org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77)
Anyway, whatever the state of CDI that looks like a separate problem;
I can't run the core testsuite reliably with this version of TestNG;
from Vladimir's comment I guess we can't upgrade easily
so I'm opening ISPN-2450.
Cheers,
Sanne
I've run the tests several times, but I hadn't got the test hangouts as you
have mentioned and all tests are passing on my side without failures.
I've tried also the testsuite execution with TestNG version 6.7 and it is
fine as well.
I just thought, maybe there is something wrong with your testsuite setup or
environment (just thoughts)?
Best regards,
Anna.
- Original Message -
From: Sanne Grinovero sa...@infinispan.org
To: infinispan -Dev List infinispan-dev@lists.jboss.org
Sent: Sunday, October 28, 2012 11:12:32 AM
Subject: [infinispan-dev] Testsuite: hanging TestNG, CDI proken
Hello all,
besides having regular failures, I also experienced occasional hangs
while running the testsuite; in some cases I found the following stack
which suggests a TestNG bug:
pool-3-thread-14 prio=10 tid=0x7f0d84632000 nid=0x1ce5 runnable
[0x7f0d58a36000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.put(HashMap.java:374)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:320)
at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)
at
org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Even when taking multiple dumps that thread is still in the same loop,
and having a single CPU stuck at 100% I'm guessing the HashMap was
being used in some unsafe way regarding concurrency; we're using the
first minor version of TestNG which ever supported parallel testsuite
invocations so that might not be very solid.
Not sure why, but upgrading TestNG from 5.14.10 to 6.7 seems to
resolve the
Re: [infinispan-dev] Testsuite: hanging TestNG, CDI proken
I have further changes to the CDI pom, so please issue your PR first :)
Tristan
On 10/29/2012 04:25 PM, Manik Surtani wrote:
For what it's worth, I just created a branch with:
* TestNG 6.7 as a dependency in parent/pom.xml (so all modules use this)
* Updated cdi/extension/pom.xml to use ${version.testng} rather than
${version.testng.arquillian} - so it too now uses TestNG 6.7.
Ran tests.
Results from tests in cdi/extension:
Results :
Tests run: 60, Failures: 0, Errors: 0, Skipped: 0
Anyone want a pull req? ;)
- M
On 29 Oct 2012, at 16:06, Sanne Grinovero sa...@infinispan.org wrote:
On 29 October 2012 08:59, Anna Manukyan amanu...@redhat.com wrote:
Hi Sanne,
sorry for my interfering in - I was lately working on CDI testsuite -
evaluating the coverage, etc. and actually on my local environment as well
as on Jenkins, the CDI integration tests are passing properly.
Hi Anna,
I wouldn't call that interfering, it's exactly the kind of feedback I
was looking for. I just checked master again, and it still failed for
me.
This is the stack I have in all tests, in case it helps:
java.lang.NullPointerException
at
org.jboss.arquillian.testng.Arquillian.arquillianAfterClass(Arquillian.java:82)
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:74)
at
org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:525)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:202)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:130)
at
org.testng.internal.TestMethodWorker.invokeAfterClassMethods(TestMethodWorker.java:222)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112)
at org.testng.TestRunner.runWorkers(TestRunner.java:1147)
at org.testng.TestRunner.privateRun(TestRunner.java:749)
at org.testng.TestRunner.run(TestRunner.java:600)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:317)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:312)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:274)
at org.testng.SuiteRunner.run(SuiteRunner.java:223)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1039)
at org.testng.TestNG.runSuitesLocally(TestNG.java:964)
at org.testng.TestNG.run(TestNG.java:900)
at
org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77)
Anyway, whatever the state of CDI that looks like a separate problem;
I can't run the core testsuite reliably with this version of TestNG;
from Vladimir's comment I guess we can't upgrade easily
so I'm opening ISPN-2450.
Cheers,
Sanne
I've run the tests several times, but I hadn't got the test hangouts as you
have mentioned and all tests are passing on my side without failures.
I've tried also the testsuite execution with TestNG version 6.7 and it is
fine as well.
I just thought, maybe there is something wrong with your testsuite setup or
environment (just thoughts)?
Best regards,
Anna.
- Original Message -
From: Sanne Grinovero sa...@infinispan.org
To: infinispan -Dev List infinispan-dev@lists.jboss.org
Sent: Sunday, October 28, 2012 11:12:32 AM
Subject: [infinispan-dev] Testsuite: hanging TestNG, CDI proken
Hello all,
besides having regular failures, I also experienced occasional hangs
while running the testsuite; in some cases I found the following stack
which suggests a TestNG bug:
pool-3-thread-14 prio=10 tid=0x7f0d84632000 nid=0x1ce5 runnable
[0x7f0d58a36000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.put(HashMap.java:374)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:320)
at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)
at
org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Even when taking multiple dumps that thread is still in the same loop,
and having a single CPU stuck at 100% I'm guessing the HashMap was
being used in some unsafe way regarding concurrency; we're using the
first minor version of TestNG which ever supported parallel testsuite
invocations so that might
Re: [infinispan-dev] broken lazy query iteration
Made sense to me at the time. Still does for what it's worth.
Plus the code using DocumentExtractor sill has to compute and deal with
first and max anyways.
Emmanuel
On Mon 2012-10-29 14:09, Ales Justin wrote:
What's the design decision behind this?
As DE has all the info, it could easily hide the offset (and max) into impl
details.
-Ales
On Oct 29, 2012, at 11:14 AM, Emmanuel Bernard emman...@hibernate.org wrote:
Correct, the DocumentExtractor contract expects the absolute index. It
looks like a bug in how ISPN's Query module use it.
Emmanuel
On Fri 2012-10-26 16:09, Ales Justin wrote:
After searching for the needed in haystack, I finally found the problem.
(not to mention complete lack of tests for this *basic* feature ...)
The problem is with queries with offset when you iterate over them --
offset is never taken into account.
There are two possible fixes -- as I see them.
1) In HS:
DocumentExtractorImpl::extract takes into account firstIndex
public EntityInfo extract(int scoreDocIndex) throws IOException {
int docId = queryHits.docId( firstIndex + scoreDocIndex );
Document document = extractDocument( fistIndex + scoreDocIndex
);
2) LazyIterator in Infinispan-Query applies the offset:
protected EntityInfo loadEntityInfo(int index) {
try {
return extractor.extract(extractor.getFirstIndex() + index);
---
Since those methods are exposed in DocumentExtractor,
I would guess they were meant for external code to use them,
instead of putting this logic into extractor itself.
So, I'll go ahead and provide a patch for (2).
-Ales
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Testsuite: hanging TestNG, CDI proken
On 29 Oct 2012, at 15:25, Manik Surtani wrote:
For what it's worth, I just created a branch with:
* TestNG 6.7 as a dependency in parent/pom.xml (so all modules use this)
* Updated cdi/extension/pom.xml to use ${version.testng} rather than
${version.testng.arquillian} - so it too now uses TestNG 6.7.
Ran tests.
Results from tests in cdi/extension:
Results :
Tests run: 60, Failures: 0, Errors: 0, Skipped: 0
Anyone want a pull req? ;)
I do :)
- M
On 29 Oct 2012, at 16:06, Sanne Grinovero sa...@infinispan.org wrote:
On 29 October 2012 08:59, Anna Manukyan amanu...@redhat.com wrote:
Hi Sanne,
sorry for my interfering in - I was lately working on CDI testsuite -
evaluating the coverage, etc. and actually on my local environment as well
as on Jenkins, the CDI integration tests are passing properly.
Hi Anna,
I wouldn't call that interfering, it's exactly the kind of feedback I
was looking for. I just checked master again, and it still failed for
me.
This is the stack I have in all tests, in case it helps:
java.lang.NullPointerException
at
org.jboss.arquillian.testng.Arquillian.arquillianAfterClass(Arquillian.java:82)
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:74)
at
org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:525)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:202)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:130)
at
org.testng.internal.TestMethodWorker.invokeAfterClassMethods(TestMethodWorker.java:222)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112)
at org.testng.TestRunner.runWorkers(TestRunner.java:1147)
at org.testng.TestRunner.privateRun(TestRunner.java:749)
at org.testng.TestRunner.run(TestRunner.java:600)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:317)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:312)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:274)
at org.testng.SuiteRunner.run(SuiteRunner.java:223)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1039)
at org.testng.TestNG.runSuitesLocally(TestNG.java:964)
at org.testng.TestNG.run(TestNG.java:900)
at
org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77)
Anyway, whatever the state of CDI that looks like a separate problem;
I can't run the core testsuite reliably with this version of TestNG;
from Vladimir's comment I guess we can't upgrade easily
so I'm opening ISPN-2450.
Cheers,
Sanne
I've run the tests several times, but I hadn't got the test hangouts as you
have mentioned and all tests are passing on my side without failures.
I've tried also the testsuite execution with TestNG version 6.7 and it is
fine as well.
I just thought, maybe there is something wrong with your testsuite setup or
environment (just thoughts)?
Best regards,
Anna.
- Original Message -
From: Sanne Grinovero sa...@infinispan.org
To: infinispan -Dev List infinispan-dev@lists.jboss.org
Sent: Sunday, October 28, 2012 11:12:32 AM
Subject: [infinispan-dev] Testsuite: hanging TestNG, CDI proken
Hello all,
besides having regular failures, I also experienced occasional hangs
while running the testsuite; in some cases I found the following stack
which suggests a TestNG bug:
pool-3-thread-14 prio=10 tid=0x7f0d84632000 nid=0x1ce5 runnable
[0x7f0d58a36000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.put(HashMap.java:374)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:320)
at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)
at
org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Even when taking multiple dumps that thread is still in the same loop,
and having a single CPU stuck at 100% I'm guessing the HashMap was
being used in some unsafe way regarding concurrency; we're using the
first minor version of TestNG which ever supported parallel testsuite
invocations so that might not be very solid.
Not sure why, but upgrading TestNG from
[infinispan-dev] cce on invocation context
I'm constantly seeing this CCE while running CapeDwarf cluster tests: (running 5.2.Beta2 with my iterator offset patch) 17:43:10,175 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (OOB-18,null) ISPN000136: Execution error: java.lang.ClassCastException: org.infinispan.context.impl.NonTxInvocationContext cannot be cast to org.infinispan.context.impl.TxInvocationContext at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPutKeyValueCommand(PessimisticLockingInterceptor.java:114) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132) at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:63) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:212) at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:150) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:207) at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:191) at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:136) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:127) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:129) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:93) at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:63) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:347) at org.infinispan.statetransfer.StateConsumerImpl.doApplyState(StateConsumerImpl.java:306) at org.infinispan.statetransfer.StateConsumerImpl.applyState(StateConsumerImpl.java:264) at org.infinispan.statetransfer.StateResponseCommand.perform(StateResponseCommand.java:86) at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:95) at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:110) at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:82) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:244) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:217) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:604) at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130) at org.jgroups.JChannel.up(JChannel.java:670) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020) at org.jgroups.protocols.RSVP.up(RSVP.java:172) at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) at org.jgroups.protocols.FlowControl.up(FlowControl.java:400) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244) at
Re: [infinispan-dev] Testsuite: hanging TestNG, CDI proken
Ok, I've hijacked http://issues.jboss.org/browse/ISPN-2450 and have issued
https://github.com/infinispan/infinispan/pull/1434
The pull request is for master. I think it should be applied to branch 5.1.x
as well, but I'll let one of you guys test it on 5.1.x first - I have a flight
to catch. :)
- M
On 29 Oct 2012, at 16:51, Mircea Markus mircea.mar...@jboss.com wrote:
On 29 Oct 2012, at 15:25, Manik Surtani wrote:
For what it's worth, I just created a branch with:
* TestNG 6.7 as a dependency in parent/pom.xml (so all modules use this)
* Updated cdi/extension/pom.xml to use ${version.testng} rather than
${version.testng.arquillian} - so it too now uses TestNG 6.7.
Ran tests.
Results from tests in cdi/extension:
Results :
Tests run: 60, Failures: 0, Errors: 0, Skipped: 0
Anyone want a pull req? ;)
I do :)
- M
On 29 Oct 2012, at 16:06, Sanne Grinovero sa...@infinispan.org wrote:
On 29 October 2012 08:59, Anna Manukyan amanu...@redhat.com wrote:
Hi Sanne,
sorry for my interfering in - I was lately working on CDI testsuite -
evaluating the coverage, etc. and actually on my local environment as well
as on Jenkins, the CDI integration tests are passing properly.
Hi Anna,
I wouldn't call that interfering, it's exactly the kind of feedback I
was looking for. I just checked master again, and it still failed for
me.
This is the stack I have in all tests, in case it helps:
java.lang.NullPointerException
at
org.jboss.arquillian.testng.Arquillian.arquillianAfterClass(Arquillian.java:82)
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:74)
at
org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:525)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:202)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:130)
at
org.testng.internal.TestMethodWorker.invokeAfterClassMethods(TestMethodWorker.java:222)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112)
at org.testng.TestRunner.runWorkers(TestRunner.java:1147)
at org.testng.TestRunner.privateRun(TestRunner.java:749)
at org.testng.TestRunner.run(TestRunner.java:600)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:317)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:312)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:274)
at org.testng.SuiteRunner.run(SuiteRunner.java:223)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1039)
at org.testng.TestNG.runSuitesLocally(TestNG.java:964)
at org.testng.TestNG.run(TestNG.java:900)
at
org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77)
Anyway, whatever the state of CDI that looks like a separate problem;
I can't run the core testsuite reliably with this version of TestNG;
from Vladimir's comment I guess we can't upgrade easily
so I'm opening ISPN-2450.
Cheers,
Sanne
I've run the tests several times, but I hadn't got the test hangouts as
you have mentioned and all tests are passing on my side without failures.
I've tried also the testsuite execution with TestNG version 6.7 and it is
fine as well.
I just thought, maybe there is something wrong with your testsuite setup
or environment (just thoughts)?
Best regards,
Anna.
- Original Message -
From: Sanne Grinovero sa...@infinispan.org
To: infinispan -Dev List infinispan-dev@lists.jboss.org
Sent: Sunday, October 28, 2012 11:12:32 AM
Subject: [infinispan-dev] Testsuite: hanging TestNG, CDI proken
Hello all,
besides having regular failures, I also experienced occasional hangs
while running the testsuite; in some cases I found the following stack
which suggests a TestNG bug:
pool-3-thread-14 prio=10 tid=0x7f0d84632000 nid=0x1ce5 runnable
[0x7f0d58a36000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.put(HashMap.java:374)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:320)
at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)
at
org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Even
Re: [infinispan-dev] cce on invocation context
Ales, I think you're seeing https://issues.jboss.org/browse/ISPN-2408 On Mon, Oct 29, 2012 at 6:44 PM, Ales Justin ales.jus...@gmail.com wrote: I'm constantly seeing this CCE while running CapeDwarf cluster tests: (running 5.2.Beta2 with my iterator offset patch) 17:43:10,175 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (OOB-18,null) ISPN000136: Execution error: java.lang.ClassCastException: org.infinispan.context.impl.NonTxInvocationContext cannot be cast to org.infinispan.context.impl.TxInvocationContext at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPutKeyValueCommand(PessimisticLockingInterceptor.java:114) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132) at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:63) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:212) at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:150) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:207) at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:191) at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:136) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:127) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:129) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:93) at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:63) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:347) at org.infinispan.statetransfer.StateConsumerImpl.doApplyState(StateConsumerImpl.java:306) at org.infinispan.statetransfer.StateConsumerImpl.applyState(StateConsumerImpl.java:264) at org.infinispan.statetransfer.StateResponseCommand.perform(StateResponseCommand.java:86) at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:95) at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:110) at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:82) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:244) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:217) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:604) at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130) at org.jgroups.JChannel.up(JChannel.java:670) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020) at org.jgroups.protocols.RSVP.up(RSVP.java:172) at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
Re: [infinispan-dev] Testsuite: hanging TestNG, CDI proken
On Mon, Oct 29, 2012 at 5:06 PM, Sanne Grinovero sa...@infinispan.orgwrote: On 29 October 2012 08:59, Anna Manukyan amanu...@redhat.com wrote: Hi Sanne, sorry for my interfering in - I was lately working on CDI testsuite - evaluating the coverage, etc. and actually on my local environment as well as on Jenkins, the CDI integration tests are passing properly. Hi Anna, I wouldn't call that interfering, it's exactly the kind of feedback I was looking for. I just checked master again, and it still failed for me. This is the stack I have in all tests, in case it helps: java.lang.NullPointerException at org.jboss.arquillian.testng.Arquillian.arquillianAfterClass(Arquillian.java:82) 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:74) at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:525) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:202) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:130) at org.testng.internal.TestMethodWorker.invokeAfterClassMethods(TestMethodWorker.java:222) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.runWorkers(TestRunner.java:1147) at org.testng.TestRunner.privateRun(TestRunner.java:749) at org.testng.TestRunner.run(TestRunner.java:600) at org.testng.SuiteRunner.runTest(SuiteRunner.java:317) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:312) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:274) at org.testng.SuiteRunner.run(SuiteRunner.java:223) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1039) at org.testng.TestNG.runSuitesLocally(TestNG.java:964) at org.testng.TestNG.run(TestNG.java:900) at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77) This is https://issues.jboss.org/browse/ARQ-553 Of course, we do specify parallel=none in the CDI pom.xml, but because of a bug in Maven or Surefire, TestNG sometime runs with the parent configuration (parallel=tests). If you can reproduce it reliably on your machine maybe you can debug Maven and file a bug with them... I was supposed to fix the CDI suite but I never reproduced it on my machine. Anyway, whatever the state of CDI that looks like a separate problem; I can't run the core testsuite reliably with this version of TestNG; from Vladimir's comment I guess we can't upgrade easily so I'm opening ISPN-2450. Cheers, Sanne I've run the tests several times, but I hadn't got the test hangouts as you have mentioned and all tests are passing on my side without failures. I've tried also the testsuite execution with TestNG version 6.7 and it is fine as well. I just thought, maybe there is something wrong with your testsuite setup or environment (just thoughts)? Best regards, Anna. - Original Message - From: Sanne Grinovero sa...@infinispan.org To: infinispan -Dev List infinispan-dev@lists.jboss.org Sent: Sunday, October 28, 2012 11:12:32 AM Subject: [infinispan-dev] Testsuite: hanging TestNG, CDI proken Hello all, besides having regular failures, I also experienced occasional hangs while running the testsuite; in some cases I found the following stack which suggests a TestNG bug: pool-3-thread-14 prio=10 tid=0x7f0d84632000 nid=0x1ce5 runnable [0x7f0d58a36000] java.lang.Thread.State: RUNNABLE at java.util.HashMap.put(HashMap.java:374) at org.testng.SuiteRunner.runTest(SuiteRunner.java:320) at org.testng.SuiteRunner.access$000(SuiteRunner.java:34) at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351) at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Even when taking multiple dumps that thread is still in the same loop, and having a single CPU stuck at 100% I'm guessing the HashMap was being used in some unsafe way regarding concurrency; we're using the first minor version of TestNG which ever supported parallel testsuite invocations so that might not be very solid. Not
Re: [infinispan-dev] Testsuite: hanging TestNG, CDI proken
On 29 Oct 2012, at 17:12, Manik Surtani wrote: Ok, I've hijacked http://issues.jboss.org/browse/ISPN-2450 and have issued https://github.com/infinispan/infinispan/pull/1434 The pull request is for master. I think it should be applied to branch 5.1.x as well, but I'll let one of you guys test it on 5.1.x first - I have a flight to catch. :) It's in - thanks! :-) Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Transaction table cleanup
On 19 Oct 2012, at 17:40, Mircea Markus mircea.mar...@jboss.com wrote: On 19 Oct 2012, at 07:41, Vladimir Blagojevic wrote: On 12-10-19 4:15 AM, Manik Surtani wrote: You're right actually, the temporary cache created is transactional. it is built in the CreateCacheCommand and relies on the DummyTransactionManager, might be better to use batching perhaps? Or even not require for this cache to be transactional? Yes, we should keep such internal caches as simple as possible. Mircea/Manik, it could be batch I believe. If you recall Mircea, you and I talked about how to effectively move data across cluster deadlock free - we even agreed we should blog post about it :-) https://issues.jboss.org/browse/ISPN-2156 Mircea/Manik could I get some advice and code review for MapReduceManagerImpl#combine? Thanks Vladimir. The only change to make is CreateCacheCommand.create, configure the cache to be batchable[1]. Then in the MapReduceManagerImpl#combine, don't use the TransactionManager.beggin/commit but the batch API. Is this in? Have we redone M/R not to rely on transactions and instead to use batching yet? Vladimir? - M [1] https://docs.jboss.org/author/display/ISPN/Batching Thanks guys, Vladimir ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
