SchedulerNaturalOrderIterator causes infinite loop

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

SchedulerNaturalOrderIterator causes infinite loop

jkuchta
Hi,

my application gets stuck quite quickly when I run on Sun JVM 1.6.0_24. I do not observe it when I run on JVM 1.6.0_18.

I did my testes with official release btm-2.1.0.jar and also with a snapshot version btm-2.1.1-20110311.090521-4.jar. It behaves the same way, i.e. some threads get stuck no matter what library is deployed. The provided thread dumps were made when the snapshot version btm-2.1.1-20110311.090521-4.jar was deployed.

Hanging threads have prefix SRRoute in their name. All the SRRoute threads are stuck in the method XAResourceManager.collectUniqueNames(). It seems they are running in an infinite loop, so I suspect the SchedulerNaturalOrderIterator is the culprit.

"SRRoute-4" prio=10 tid=0x9f07e000 nid=0xdee runnable [0x9df89000]
   java.lang.Thread.State: RUNNABLE
        at java.util.HashMap.put(HashMap.java:372)
        at java.util.HashSet.add(HashSet.java:200)
        at bitronix.tm.internal.XAResourceManager.collectUniqueNames(XAResourceManager.java:272)

"SRRoute-3" prio=10 tid=0x9f09c000 nid=0xded runnable [0x9dfda000]
   java.lang.Thread.State: RUNNABLE
        at bitronix.tm.internal.XAResourceManager.collectUniqueNames(XAResourceManager.java:272)

The attached file contains three full thread dumps showing the same thing, i.e. stuck SRRoute threads. The dumps were made when the snapshot version btm-2.1.1-20110311.090521-4.jar was deployed
thread-dump-3x.log
Reply | Threaded
Open this post in threaded view
|

Re: SchedulerNaturalOrderIterator causes infinite loop

jkuchta
I have forgotten to provide my development environment details. Here it is:

Sun JVM we are running on: Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 5) Linux 2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT 2007 i686 athlon i386 GNU/Linux
Server: 8xOpteron QuadCore 2.4G, 64GB

I have also attached another thread dump showing all SRRoute threads stuck in a different place. This time it is XAResourceManager.findXAResourceHolderState(XAResource), again SchedulerNaturalOrderIterator is involved.

thread-dump-2.log
Reply | Threaded
Open this post in threaded view
|

Re: SchedulerNaturalOrderIterator causes infinite loop

Ludovic Orban-2
This is very surprising. I fail to see how this could be caused by a race condition as the Scheduler object is only accessed by a single thread IIRC. How often is that happening?

What could happen is that resources continuously get added to the scheduler while it is being iterated but it's hard to believe as simply changing your JDK makes your application working fine.

Adding debug logs to the Scheduler class (especially in the SchedulerNaturalOrderIterator.hasNext() method) would help figuring out what's going wrong in XAResourceManager.collectUniqueNames() and probably XAResourceManager.findXAResourceHolderState() as well.

I've prepared a build with extra debug logs in the Scheduler class (see attached source file) and published the jar over there:
 https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/btm/btm/2.1.1-SNAPSHOT/btm-2.1.1-20110315.143128-5.jar

Please try again while collecting debug logs with the least possible amount of threads you can get to reproduce the issue. This should give us a better idea of what's going on.

Ludovic


2011/3/13 jkuchta <[hidden email]>

I have forgotten to provide my development environment details. Here it is:

Sun JVM we are running on: Java(TM) SE Runtime Environment (build
1.6.0_24-b07)
OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 5) Linux
2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT 2007 i686 athlon i386
GNU/Linux
Server: 8xOpteron QuadCore 2.4G, 64GB

I have also attached another thread dump showing all SRRoute threads stuck
in a different place. This time it is
XAResourceManager.findXAResourceHolderState(XAResource), again
SchedulerNaturalOrderIterator is involved.

http://old.nabble.com/file/p31136694/thread-dump-2.log thread-dump-2.log
--
View this message in context: http://old.nabble.com/SchedulerNaturalOrderIterator-causes-infinite-loop-tp31136251p31136694.html
Sent from the Bitronix Transaction Manager mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Scheduler.java (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SchedulerNaturalOrderIterator causes infinite loop

Leos Bitto
SchedulerNaturalOrderIterator seems to be broken to me because it changes its state (its private fields) in its method hasNext(). I have always expected iterator's hasNext() method to be idempotent. Expecting that every Iterator instance will be always used so that hasNext() and next() calls are 1:1 seems to be a very dangerous assumption. In your situation it is 2:1, because hasNext() is called not only by the client, but even by the method next() itself - so I believe that the iterator skips half of the records! Additionally, it might happen that the client's call to hasNext() returns true, so it proceeds to call next() which might throw NoSuchElementException because its own call to hasNext() returns false. Very broken indeed! If such client then swallows this NoSuchElementException, the situation happens to be very unclear...
Reply | Threaded
Open this post in threaded view
|

Re: SchedulerNaturalOrderIterator causes infinite loop

Ludovic Orban-2
You are wrong, SchedulerNaturalOrderIterator.hasNext() is perfectly idempotent like it should be.

It is true that hasNext() modifies the iterator's internal state and that next() calls hasNext() but that's an implementation detail that doesn't break the Iterator interface contract at all: the iterator doesn't change the _iterated collection_'s internal state and you can call hasNext() a million times between two next() calls and always get the correct result.

If any of the Scheduler or the SchedulerNaturalOrderIterator class is broken, it certainly isn't related to what you're reporting. Please try to read and understand the code before posting such bold statement next time, or at the very least please try to be much more precise if you think you've identified a bug.


2011/3/18 Leos Bitto <[hidden email]>

SchedulerNaturalOrderIterator seems to be broken to me because it changes its
state (its private fields) in its method hasNext(). I have always expected
iterator's hasNext() method to be idempotent. Expecting that every Iterator
instance will be always used so that hasNext() and next() calls are 1:1
seems to be a very dangerous assumption. In your situation it is 2:1,
because hasNext() is called not only by the client, but even by the method
next() itself - so I believe that the iterator skips half of the records!
Additionally, it might happen that the client's call to hasNext() returns
true, so it proceeds to call next() which might throw NoSuchElementException
because its own call to hasNext() returns false. Very broken indeed! If such
client then swallows this NoSuchElementException, the situation happens to
be very unclear...
--
View this message in context: http://old.nabble.com/SchedulerNaturalOrderIterator-causes-infinite-loop-tp31136251p31180218.html
Sent from the Bitronix Transaction Manager mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: SchedulerNaturalOrderIterator causes infinite loop

Leos Bitto
Ludovic Orban-2 wrote
You are wrong, SchedulerNaturalOrderIterator.hasNext() is perfectly idempotent like it should be.

... you can call hasNext() a million times between two next() calls and always get the correct result.
You are right. I am sorry, I misunderstood the invariants which seem to be properly protected. At this moment I would guess that this issue could be related to some threading issues. You wrote that you thought the Scheduler object was only accessed by a single thread, but I have found at least one place where it would get accessed by another thread, too: TransactionTimeoutTask#execute() (invoked by TaskScheduler) calls BitronixTransaction#timeout(), which calls setStatus(Status.STATUS_MARKED_ROLLBACK) and that calls XAResourceManager#collectUniqueNames(), no synchronization (or even any other kind of memory barrier) anywhere.
Reply | Threaded
Open this post in threaded view
|

Re: SchedulerNaturalOrderIterator causes infinite loop

jkuchta
In reply to this post by Ludovic Orban-2
I am not able to reproduce the problem with the provided SNAPSHOT library btm-2.1.1-20110315.143128-5.jar even If I disable DEBUG logging level.

I did my own experimental code changes and basically when I added any logging I could not reproduce the problem anymore.

Some observations when I use the original btm-2.1.0  lib:
1) It happens only in a thread with the most complicated transaction. In my case the most complicated transaction means two datasources (JMS [swiftmq ], DB [oracle]) . The JMS datasource is enlisted 4 times as 4 different JMS queues participate in the transaction (i.e. TMJOIN is used)
2) It is possible to reproduce it with a single thread, so the concurrency is not the problem.
3) It happens when operations XAResourceManager.enlist() or XAResourceManager.delist() are called
4) It fails quite fast, 3000 transactions should do the job

From what I have seen I believe it should be reproducible quite easily for anyone (Sun JVM 1.6.0_24, two datasources, one of them listed several times and it should happen)

Now just pure speculations

My guess is that the JVM does some optimizations which are not compatible with the code. The optimization is not in place when there is a chance that some IO ops can happen.

Can there be a concurrency on a multi core processor for a single thread? Like the operations of a single thread are performed concurrently when it is considered 'safe'? I do not know.

An instance of SchedulerNaturalOrderIterator is always accessed from a single thread right? So the following change should have no impact right? (I marked two SchedulerNaturalOrderIterator attributes as volatile)

    private class SchedulerNaturalOrderIterator implements Iterator {
        private int nextKeyIndex;
        private volatile List objectsOfCurrentKey;
        private volatile int objectsOfCurrentKeyIndex;

When I run this code it does not fail anymore. So this makes me believe that a single thread can run its operations concurrently.
Reply | Threaded
Open this post in threaded view
|

Re: SchedulerNaturalOrderIterator causes infinite loop

Leos Bitto
jkuchta wrote
I am not able to reproduce the problem with the provided SNAPSHOT library btm-2.1.1-20110315.143128-5.jar even If I disable DEBUG logging level.

I did my own experimental code changes and basically when I added any logging I could not reproduce the problem anymore.
I guess that the logging slows down or synchronizes the threads and so it hides the real cause of the problem.

jkuchta wrote
Some observations when I use the original btm-2.1.0  lib:
1) It happens only in a thread with the most complicated transaction. In my case the most complicated transaction means two datasources (JMS [swiftmq ], DB [oracle]) . The JMS datasource is enlisted 4 times as 4 different JMS queues participate in the transaction (i.e. TMJOIN is used)
As a workaround, you could theoretically use only one JMS session (which provides only one XAResource to enlist in the XA transaction) and create all the consumers and producers from it.

jkuchta wrote
2) It is possible to reproduce it with a single thread, so the concurrency is not the problem.
I am afraid that even when you create only one thread, there still are other threads which might interfere with it (for example the timeout scheduler, etc.).

jkuchta wrote
Can there be a concurrency on a multi core processor for a single thread? Like the operations of a single thread are performed concurrently when it is considered 'safe'? I do not know.
No way. In Java everything in one thread executes exactly in the order of the source code.

jkuchta wrote
An instance of SchedulerNaturalOrderIterator is always accessed from a single thread right?
Yes, at least in the methods findXAResourceHolderState and collectUniqueNames of XAResourceManager where it gets stuck according to your posted thread dumps.

jkuchta wrote
So the following change should have no impact right? (I marked two SchedulerNaturalOrderIterator attributes as volatile)

    private class SchedulerNaturalOrderIterator implements Iterator {
        private int nextKeyIndex;
        private volatile List objectsOfCurrentKey;
        private volatile int objectsOfCurrentKeyIndex;

When I run this code it does not fail anymore.
The impact might be that by reading and writing volatile fields, the thread's memory view synchronizes with the main memory - according to the changes in the Java memory model, introduced by JSR133 (from Java 5). So this change might in fact cover the main cause of this issue, instead of finding it and fixing it properly. Additionally, there is no guarantee that future JVM optimalizations would not break this "fix".
Reply | Threaded
Open this post in threaded view
|

Re: SchedulerNaturalOrderIterator causes infinite loop

Ludovic Orban-2
In reply to this post by jkuchta
See my answers inline.

2011/3/18 Leos Bitto <[hidden email]>


jkuchta wrote:
>
> I am not able to reproduce the problem with the provided SNAPSHOT library
> btm-2.1.1-20110315.143128-5.jar even If I disable DEBUG logging level.
>
> I did my own experimental code changes and basically when I added any
> logging I could not reproduce the problem anymore.
>

I guess that the logging slows down or synchronizes the threads and so it
hides the real cause of the problem.

I believe the same.


 
jkuchta wrote:
>
> 2) It is possible to reproduce it with a single thread, so the concurrency
> is not the problem.
>

I am afraid that even when you create only one thread, there still are other
threads which might interfere with it (for example the timeout scheduler,
etc.).

Indeed but that's a good indicator that the lack of synchronization isn't due to external multi-threading, it's purely internal to BTM threads.

 
jkuchta wrote:
>
> An instance of SchedulerNaturalOrderIterator is always accessed from a
> single thread right?
>

Yes, at least in the methods findXAResourceHolderState and
collectUniqueNames of XAResourceManager where it gets stuck according to
your posted thread dumps.

That's what puzzles me: I agree there are some missing memory fences at a few locations but in this case I fail to see what could tamper with the transaction scheduler's internals, unless maybe transaction suspension and resuming onto another thread?

 
jkuchta wrote:
>
> So the following change should have no impact right? (I marked two
> SchedulerNaturalOrderIterator attributes as volatile)
>
>     private class SchedulerNaturalOrderIterator implements Iterator {
>         private int nextKeyIndex;
>         private volatile List objectsOfCurrentKey;
>         private volatile int objectsOfCurrentKeyIndex;
>
> When I run this code it does not fail anymore.
>

The impact might be that by reading and writing volatile fields, the
thread's memory view synchronizes with the main memory - according to the
changes in the Java memory model, introduced by JSR133 (from Java 5). So
this change might in fact cover the main cause of this issue, instead of
finding it and fixing it properly. Additionally, there is no guarantee that
future JVM optimalizations would not break this "fix".

Once again I have to agree here: the two fields you've marked as volatile don't need to be multithread safe so if that solves your issue I guess this is purely by coincidence and you're merely hiding the root cause by marking these fields volatile.

I am quite certain the 1.6.0_24 JVM's Hotspot got a new optimization somewhere in some form of native code it generates which triggers this problem after some method gets jit'ed. That would explain why you need to wait for 3000 transactions to run before you hit the problem: that's the time it takes for hotspot to decide to compile a method into native code. I just can't figure out which method and when that happens.

You may want to try to find out if this theory is right by lowering the the amount of executions required before Hotspot compiles a method by adding -XX:CompileThreshold=1000 on your JVM command line. Since the default for the server VM is 10000 you should see the problem 10 times faster. Adding -XX:+PrintCompilation would be the next step as Hotspot would then print out which methods it compiles. With a bit of luck it will be possible to correlate the appearance of the infinite loop with a method compilation and trace back the problem from there.

Something else I noticed is that all SchedulerNaturalOrderIterator and SchedulerReverseOrderIterator methods should synchronize on Scheduler.this. This definitely is a bug which I missed but once again I cannot figure out how this could have caused your problem even if adding the synchronized blocks could solve it.



Please let us know how things turned out.

Thanks,
Ludovic
Reply | Threaded
Open this post in threaded view
|

Re: SchedulerNaturalOrderIterator causes infinite loop

jkuchta
Hi

I collected some logs with enabled switch -XX:+PrintCompilation. See attached printcomp.zip file. It includes:

appl.log - application debug log including inlined output of -XX:+PrintCompilation
printcomp.log - complete output obtained due to enabled switch -XX:+PrintCompilation
thread-dump.log - thread dump showing the thread SRRoute-1 stuck in the method XAResourceManager.collectUniqueNames

The appl.log shows that the last jitted bitronix method is XAResourceManager::collectUniqueNames before the thread get stuck.

2011-03-22 10:53:03.437 DEBUG [bitronix-disk-force-batcher] () bitronix.tm.journal.TransactionLogAppender - forcing log writing
899       bitronix.tm.internal.XAResourceManager::collectUniqueNames (51 bytes)
2011-03-22 10:53:03.440 DEBUG [bitronix-disk-force-batcher] () bitronix.tm.journal.TransactionLogAppender - done forcing log
...
2011-03-22 10:53:03.594 DEBUG [SRRoute-1] () bitronix.tm.BitronixTransaction - committing, 2 enlisted resource(s)

2011-03-22 10:53:03.594 is the last log entry from SRRoute-1 thread. I also have similar log showing that the method XAResourceManager.findXAResourceHolderState() was jited just before a thread got hung in it.

Does it make any sense?

printcomp.zip
Reply | Threaded
Open this post in threaded view
|

Re: SchedulerNaturalOrderIterator causes infinite loop

Leos Bitto
It seems to me that it is very importart to know which of the following messages is in the full debug log after the start of the application:

trying to use ConcurrentExecutor
trying to use BackportConcurrentExecutor
using SimpleAsyncExecutor
using SyncExecutor
Reply | Threaded
Open this post in threaded view
|

Re: SchedulerNaturalOrderIterator causes infinite loop

Ludovic Orban-2
I don't think the executors have anything to do with that problem as only XAResource commands are executed asynchronously, I can't see any place where a bitronix.twopc.executor.Job subclass would call any of the two methods cited above.

The unsynchronized Scheduler iterator looks more and more like the root cause to me but as I said, I can't think of a way this could be the cause unless the transactions are being suspended and resumed.

I've deployed a build where the iterators are synchronized over there:
 http://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/btm/btm/2.1.1-SNAPSHOT/btm-2.1.1-20110322.141755-6.jar

and I believe this will solve the problem but I'm worried about not being able to prove the fix is right. It may be time to open a JIRA to track this.


2011/3/22 Leos Bitto <[hidden email]>

It seems to me that it is very importart to know which of the following
messages is in the full debug log after the start of the application:

trying to use ConcurrentExecutor
trying to use BackportConcurrentExecutor
using SimpleAsyncExecutor
using SyncExecutor

--
View this message in context: http://old.nabble.com/SchedulerNaturalOrderIterator-causes-infinite-loop-tp31136251p31211005.html
Sent from the Bitronix Transaction Manager mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: SchedulerNaturalOrderIterator causes infinite loop

jkuchta
In reply to this post by Leos Bitto
the default SyncExecutor is used

2011-03-22 20:36:24.008 DEBUG [AORoute-2] () bitronix.tm.TransactionManagerServices - using SyncExecutor
Reply | Threaded
Open this post in threaded view
|

Re: SchedulerNaturalOrderIterator causes infinite loop

jkuchta
In reply to this post by Ludovic Orban-2
I tested the provided BTM SNAPSHOT and it works fine. I no longer see  the problem with hanging threads. Works for me. Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: SchedulerNaturalOrderIterator causes infinite loop

Ludovic Orban-2
As I said, I suspect the lack of synchronization on the Scheduler iterators were the root cause as they're at the crossing of all the symptoms but I still cannot prove it.

I'm going to recommend you to be extra careful in the coming days and very closely monitor BTM to make sure it's now working fine.

Please get back to us in a week or so, or when you feel confident about this build quality. I'll then start the release process to get 2.1.1 out.

Thanks,
Ludovic

2011/3/23 jkuchta <[hidden email]>

I tested the provided BTM SNAPSHOT and it works fine. I no longer see  the
problem with hanging threads. Works for me. Thanks.
--
View this message in context: http://old.nabble.com/SchedulerNaturalOrderIterator-causes-infinite-loop-tp31136251p31217725.html
Sent from the Bitronix Transaction Manager mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: SchedulerNaturalOrderIterator causes infinite loop

Vladimir Kulev
Hi,

It seems like I am having the same problem, stuck threads with infinite loop in findXAResourceHolderState or collectUniqueNames, both caused by SchedulerNaturalOrderIterator.
I see that you found a possible solution here, so if you have a build which can be used as drop-in replacement for btm-2.1.0, I would appreciate testing it on our server.

Ludovic Orban-2 wrote
As I said, I suspect the lack of synchronization on the Scheduler iterators
were the root cause as they're at the crossing of all the symptoms but I
still cannot prove it.

I'm going to recommend you to be extra careful in the coming days and very
closely monitor BTM to make sure it's now working fine.

Please get back to us in a week or so, or when you feel confident about this
build quality. I'll then start the release process to get 2.1.1 out.

Thanks,
Ludovic

2011/3/23 jkuchta <jkuchta@indracompany.com>

>
> I tested the provided BTM SNAPSHOT and it works fine. I no longer see  the
> problem with hanging threads. Works for me. Thanks.
> --
> View this message in context:
> http://old.nabble.com/SchedulerNaturalOrderIterator-causes-infinite-loop-tp31136251p31217725.html
> Sent from the Bitronix Transaction Manager mailing list archive at
> Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: SchedulerNaturalOrderIterator causes infinite loop

Ludovic Orban-2
It's there: http://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/btm/btm/2.1.1-SNAPSHOT/btm-2.1.1-20110322.141755-6.jar

2011/3/29 Vladimir Kulev <[hidden email]>

Hi,

It seems like I am having the same problem, stuck threads with infinite loop
in findXAResourceHolderState or collectUniqueNames, both caused by
SchedulerNaturalOrderIterator.
I see that you found a possible solution here, so if you have a build which
can be used as drop-in replacement for btm-2.1.0, I would appreciate testing
it on our server.


Ludovic Orban-2 wrote:
>
> As I said, I suspect the lack of synchronization on the Scheduler
> iterators
> were the root cause as they're at the crossing of all the symptoms but I
> still cannot prove it.
>
> I'm going to recommend you to be extra careful in the coming days and very
> closely monitor BTM to make sure it's now working fine.
>
> Please get back to us in a week or so, or when you feel confident about
> this
> build quality. I'll then start the release process to get 2.1.1 out.
>
> Thanks,
> Ludovic
>
> 2011/3/23 jkuchta <[hidden email]>
>
>>
>> I tested the provided BTM SNAPSHOT and it works fine. I no longer see
>> the
>> problem with hanging threads. Works for me. Thanks.
>> --
>> View this message in context:
>> http://old.nabble.com/SchedulerNaturalOrderIterator-causes-infinite-loop-tp31136251p31217725.html
>> Sent from the Bitronix Transaction Manager mailing list archive at
>> Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>

--
View this message in context: http://old.nabble.com/SchedulerNaturalOrderIterator-causes-infinite-loop-tp31136251p31271822.html
Sent from the Bitronix Transaction Manager mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: SchedulerNaturalOrderIterator causes infinite loop

Ludovic Orban-2
I can't be any more precise than 'as soon as possible, as time permits'.

2.1.1 is complete and well tested, it's just about launching the release process.


2011/3/30 Vladimir Kulev <[hidden email]>
After a day of testing no problem occurred (it was enough before). I am looking forward to 2.1.1 release, do you have some expectations about it?


On Wed, Mar 30, 2011 at 1:35 AM, Ludovic Orban <[hidden email]> wrote:
It's there: http://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/btm/btm/2.1.1-SNAPSHOT/btm-2.1.1-20110322.141755-6.jar

2011/3/29 Vladimir Kulev <[hidden email]>

Hi,

It seems like I am having the same problem, stuck threads with infinite loop
in findXAResourceHolderState or collectUniqueNames, both caused by
SchedulerNaturalOrderIterator.
I see that you found a possible solution here, so if you have a build which
can be used as drop-in replacement for btm-2.1.0, I would appreciate testing
it on our server.


Ludovic Orban-2 wrote:
>
> As I said, I suspect the lack of synchronization on the Scheduler
> iterators
> were the root cause as they're at the crossing of all the symptoms but I
> still cannot prove it.
>
> I'm going to recommend you to be extra careful in the coming days and very
> closely monitor BTM to make sure it's now working fine.
>
> Please get back to us in a week or so, or when you feel confident about
> this
> build quality. I'll then start the release process to get 2.1.1 out.
>
> Thanks,
> Ludovic
>
> 2011/3/23 jkuchta <[hidden email]>
>
>>
>> I tested the provided BTM SNAPSHOT and it works fine. I no longer see
>> the
>> problem with hanging threads. Works for me. Thanks.
>> --
>> View this message in context:
>> http://old.nabble.com/SchedulerNaturalOrderIterator-causes-infinite-loop-tp31136251p31217725.html
>> Sent from the Bitronix Transaction Manager mailing list archive at
>> Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>

--
View this message in context: http://old.nabble.com/SchedulerNaturalOrderIterator-causes-infinite-loop-tp31136251p31271822.html
Sent from the Bitronix Transaction Manager mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email






--
Vladimir Kulev
Mobile: +7 (921) 555-44-22
Jabber: [hidden email]
Skype: lightoze