Conditional break points - sometimes yes, sometimes no. Bug?

So I have a Tomcat deployment environment and system that handles JMS messages.
Behaviour that I've been seeing is that a conditional breakpoint which HAS to be true is intermittently triggered. This is to say that it's triggered on some test runs but not others.  I know it's true at least once in all test runs though because afterwards I can see the result in the database.  The break point conditional is a particular recordId and if I can see that the record is copied to the target table, then I know it went through the code path in question.  There is some chaining to get to it but none of those items can possibly be null without causing big noticable problems earlier in the code. Note that there's no indication of an error, i.e. there is no red underline and the block of code is green.

Conditional looks like this:  something.getSomethingelse().getSomeEntityFieldOfStringType().equals("SOMERECORDID")

Question: What would happen to the breakpoint evaluation if something.getSomethingelse() took a long time?

Has anyone else seen this behaviour or know anything about it?

For the record, I have not one but two licenses. One from work for my current contract and one for when the org I'm working for uses Eclipse and won't provide a license.

2 comments
Comment actions Permalink

Hi Jim,

> something.getSomethingelse().getSomeEntityFieldOfStringType().equals("SOMERECORDID")

The reason may be in the expression. The condition involves three method calls and as you say, some of them may take some considerable time. In order to parform a method call, the debugger has to resume thread's exacution, then the call is performed in the current thread, and then threads are paused again. Due to multithreading, some threads may affect the data during the method call. Also the methods being called may have some side effects and thus indirectly affect the result of condition expression.
Note that this applies not only to breakpoints' condition, but also to any variable renderer that involves method calls: toString() or Collection renderers. There renderers may be switched off, so default ones will be used which do not use method calls.
If possible, please try to rewrite the expression to avoid method calls as much as possible. For example, if getSomething() actually returns some value stored in a field, it is better (and faster) to use field access expression. Note that even if the field is private and is not normally accessible from breakpoint's context, debugger can still evaluate this expression.

0
Comment actions Permalink

Regarding the data, good thinking but I'm afraid we thought of that already. The data doesn't change due to threading.  Each thread has one and only one Entity and associated satalite records, each of which is a discreet unit of data.  Also, the Entities are not attached to the HIbernate Entity manager at the time in question and the values are handled in read-only fashion, meaning we can write em but don't.  It's new records that are created and passed on to the persistence widget. Some Hibernate calls are made in the processing widget but it's just data retrival to base decisions on.

As for the rest, what you say makes sense and is something along the lines of what I expected to hear.  We only just started using the conditional breakpoints so this is some learning pain for us.

Please let me test and verify by breaking some of these chains and seeing if I can get any breakpoint skipping in multi-threaded mode before we mark this resolved.  Since we are calling .equals("someString"), I would expect some but if I can reduce the problem by breaking down the chains, it counts as verification IMHO.

Problem is that my collegues really love to chain stuff. What I want is a "Chain Breaker" live template that will replace chained code and put in intermediary variables and maybe another that does it with a null check. Got anything lke that? ;-) If not, maybe I can write em.

0

Please sign in to leave a comment.