Strange behaviour of Seam Mail when sending unsynchonized as

[mschmidke]

Hello,

as you can see, I am digging deeper into the Seam Mail thing.

By now, I have a POJO Seam component, event scoped, with an @Asynchronous method send(), which sends a mail (by calling renderer.render).

From the application, this method is called twice one immediately after the other.

This results in some strange behaviour (and no mails being sent).

It seems I solved this by adding "@Synchronized" to the component (since it is a timing issue, I can never be really sure ...)

But I have a question:

Obviously when called two times simultaneously, the one renderer interferes with the other. In my mail class I could solve this by synchronizing it, but what about the front page renderer? If accidentally in the same moment a mail is rendered also a page is rendered?

Will I have some very random-caused irreproducible strange problems in the future?

[pmuir]

Do you get a stack trace?

[mschmidke]

Yes, but to explain it I must go a little deeper.

My template looks like

<ui:repeat value="#{recipients}" var="rec">
 <m:to>#{rec}</m:to>
 ....
</ui:repeat>

and recipients gets into the context by

@Asynchronous
public void send(List<String> recipients) {
 Context c=Contexts.getEventContext();
 c.set("recipients", recipients);
 renderer.render("...");
}

The caller is a jBPM action class with:

 Mailhandler mh=(Mailhandler)Components.getInstance(Mailhandler.class);
 mh.send(new Vector<String>(getRecipients()));

If I only send one mail, everything works fine. If I send two at the same time (two mail actions in jBPM which are executed immediately one after the other), I get some error from class InternetAddress telling the recipient's syntax is wrong ("@domain" is missing). I think either the ui:repeat or the m:to gets confused in some way when simultaneously used in multiple threads.

I checked everything, I can't find any other synchronizity side effect (for example in the recipients list - everything is copied before usage), so I think it must be some issue with the renderer.

(I wrote this all from memory; if you need even more info, let me know, I'll post the exact strack trace when I'm back in office tomorrow)

Marcus.

[pmuir]

Ok, this is possible, I haven't tested this (and the renderer is a bit tricky ;). If you can post a simple app to reproduce to JIRA that would be great :)

[mschmidke]

Now I've tried to reproduce it in a simple environment.

Unfortunately no problem.

Ok, for the first I can work around by putting @Synchronized on the class, as mentioned above.

Let's hope that there is no interference with the page renderer ...

Thank you for listening! :-)

[pmuir]

Ok, if you manage to nail down the problem, let us know (things like this are very complex, but we are certainly interested in "real-world" feedback for Seam!)

[mschmidke]

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!!!

[mschmidke]

Couldn't wait till next week ...

I did not manage to find the root cause. Too many nested ELResolvers, MockRequests and so on. Still don't know from where the problem arises. Everything I saw was ThreadLocal.

But I think I managed to work around this (this time for real) using a plain old Java synchronized() around the renderer call (synchronizing on some static member, of course). Perhaps not the legal J2EE way, but might be acceptable since it's detached using @Asynchronous.

Now every single mail is arriving as expected ...

[pmuir]

As I said, I'm keen to get this fixed, if there is indeed a problem with Seam ;)

So, if you manage to produce some simple reproduction environment then please, let me know!

[mschmidke]

Well ... finally my knowledge about the error sufficed to create a simple reproduction.

You find it here: http://jira.jboss.org/jira/browse/JBSEAM-2493.

Marcus.