[jboss-user] [JBoss Seam] - Re: Strange behaviour of Seam Mail when sending unsynchonize

MSchmidke do-not-reply at jboss.com
Fri Jan 11 08:22:53 EST 2008


Today it's even worse. :-(

Don't know why the @Synchronized could help me out yesterday.

Today, this is gone.

I've tried to find out and added a lot of printlns.

When I call the @Asynchronous method two times, the method is executed more or less simultaneously in two different threads, no matter if there is a @Synchronized on the class. This makes sense because, actually there are two different event contexts and two different instances of the mail handling component so there's nothing to be synchronized. I was wondering about this yesterday but only was glad it seemed to help.

The recipients object is passed correctly to the renderer. I can proof this by simply printing the recipients array into the mail:
...
  #{recipients}
...

This is always correct.

The exception I got yesterday is just a followup error because of wrong syntax in the m:to address. If I make the m:to address constant, there is no exception.

But the strange behaviour stays.

Instead of putting it in the m:to address, I simply printed out the objects the ui:repeat emits. And this is strange. Very strange.

The number of iterations ui:repeat makes is nearly always correct. But the objects it emits aren't. They are sometimes from the one list, sometimes from the other, and sometimes they are null if the one list is smaller than the other. Keep in mind: I proofed that the List that goes into the ui:repeat is always correct!

So there is definitively a concurrency problem somewhere in the Renderer (how can that be? Shouldn't page rendering be generally multithreadable??)

At the moment, I am completely helpless. I will go on trying to figure out how to serialize the Asynchronous calls. Perhaps I will be forced to use a MDB, but I was so glad to find the Asynchonous annotation since it is really very simple to use ...

Marcus.



There comes another idea into my mind. What if not ui:repeat itself is the problem, but the iterating context variable (var=...)? Where is it held?

Yes ... now it is crystal clear ... the problem MUST lie in the iterator variable. Tell me - where it is stored? Tell me!!

This would exactly explain all effects (the right number of iterations, the wrong objects and so on).

What a pity that I have to leave my office now. I am so curious to debug this out!!!

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119053#4119053

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119053



More information about the jboss-user mailing list