Re: [infinispan-dev] frequent stack in testsuite

2011-06-15 Thread Galder Zamarreño
https://issues.jboss.org/browse/ISPN-1184 On Jun 13, 2011, at 5:30 PM, Manik Surtani wrote: On 10 Jun 2011, at 15:14, Galder Zamarreño wrote: Hi Galder, I'm not sure to what you're referring to. I was not proposing to change anything on the reader side, just - if possible as I don't

Re: [infinispan-dev] frequent stack in testsuite

2011-06-13 Thread Manik Surtani
On 10 Jun 2011, at 15:14, Galder Zamarreño wrote: Hi Galder, I'm not sure to what you're referring to. I was not proposing to change anything on the reader side, just - if possible as I don't know this code - to try not sending anything if we fail to build a proper stream (instead of

Re: [infinispan-dev] frequent stack in testsuite

2011-06-13 Thread Manik Surtani
On 10 Jun 2011, at 12:23, Dan Berindei wrote: We may have a deadlock because we hold the processing lock (for reading) while invoking commands remotely (in JGroupsTransport). The remote commands might block waiting for the remote cache to start, and the remote cache won't start because it is

Re: [infinispan-dev] frequent stack in testsuite

2011-06-10 Thread Sanne Grinovero
2011/6/10 Galder Zamarreño gal...@redhat.com: On Jun 9, 2011, at 5:47 PM, Manik Surtani wrote: +1 to writing the error marker to the stream. At least prevent false alarms. Re: unit testing our externalizers, Galder, any thoughts there? The debugging done by Sanne/Dan seems to be correct.

Re: [infinispan-dev] frequent stack in testsuite

2011-06-10 Thread Galder Zamarreño
On Jun 10, 2011, at 11:42 AM, Sanne Grinovero wrote: 2011/6/10 Galder Zamarreño gal...@redhat.com: On Jun 9, 2011, at 5:47 PM, Manik Surtani wrote: +1 to writing the error marker to the stream. At least prevent false alarms. Re: unit testing our externalizers, Galder, any thoughts

Re: [infinispan-dev] frequent stack in testsuite

2011-06-10 Thread Sanne Grinovero
2011/6/10 Galder Zamarreño gal...@redhat.com: On Jun 10, 2011, at 11:42 AM, Sanne Grinovero wrote: 2011/6/10 Galder Zamarreño gal...@redhat.com: On Jun 9, 2011, at 5:47 PM, Manik Surtani wrote: +1 to writing the error marker to the stream. At least prevent false alarms. Re: unit

Re: [infinispan-dev] frequent stack in testsuite

2011-06-10 Thread Galder Zamarreño
On Jun 10, 2011, at 3:51 PM, Sanne Grinovero wrote: 2011/6/10 Galder Zamarreño gal...@redhat.com: On Jun 10, 2011, at 11:42 AM, Sanne Grinovero wrote: 2011/6/10 Galder Zamarreño gal...@redhat.com: On Jun 9, 2011, at 5:47 PM, Manik Surtani wrote: +1 to writing the error marker to the

[infinispan-dev] frequent stack in testsuite

2011-06-09 Thread Sanne Grinovero
Hello all, if I happen to look at the console while the tests are running, I see this exception popup very often: 2011-06-09 15:32:18,092 ERROR [JGroupsTransport] (Incoming-1,Infinispan-Cluster,NodeB-32230) ISPN00096: Caught while requesting or applying state

Re: [infinispan-dev] frequent stack in testsuite

2011-06-09 Thread Dan Berindei
I don't think it's an externalizer issue, as I also see some exceptions on the node that generates state: 2011-06-09 18:16:18,250 ERROR [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (STREAMING_STATE_TRANSFER-sender-1,Infinispan-Cluster,NodeA-57902) ISPN00095: Caught while

Re: [infinispan-dev] frequent stack in testsuite

2011-06-09 Thread Sanne Grinovero
2011/6/9 Manik Surtani msurt...@redhat.com: +1 to writing the error marker to the stream. At least prevent false alarms. actually if we're able to catch that an error happened, why are we sending anything? or is this because it happens half-way of the streaming? Sanne Re: unit testing our

Re: [infinispan-dev] frequent stack in testsuite

2011-06-09 Thread Vladimir Blagojevic
I think I know what is going on here and it has nothing to do with Galder's externalizers. At the moment when state producer generates state transfer it cannot lock processing lock which is being held by some other reader thread which got bogged down in container due to lock or whatever. State