Thanks for the test. "dukehoops" wrote : To follow up further. Below is a test i wrote trying to capture above failure. When I run it I observe the following: | - if no debugger is used, test passes | - if I step through with a debugger when EvictCommand.perform calls ctx.lookUpNode(fqn) the underlying MVCCInvocationContext sometimes has a non-null mvccTCtx and sometimes mvccTCtx is null?! It seems to depend on where I break and for how long - though pattern is unclear. |
Wow, that's not nice. "dukehoops" wrote : | 1. From my understanding ctx.mvccTCtx should NOT be null when used accessed from EvictCommand.perform in the above test. Do you agree? If not, why (how is it that mvccTCtx can be null in this case)? | Agreed. Between the InvocationContextInterceptor and the TxInterceptor, this should be made available. "dukehoops" wrote : | 2. Since it seems I can affect the outcome of the test merely by attaching a debugger and breaking throughput, I am guessing either multiple threads or timestamping is involved. Given that the entire duration of the test didn't exceed 40-50 seconds (including my think time) when varying results were obtained, this does not seem to be related to underlying JTA tx timing out. Any idea where to look for debugger breaks can affect? | It could be that the reference to the tCtx needs to be volatile, let me think about how and when this is accessed and let you know. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217065#4217065 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4217065 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
