Preventing and Handling Duplicate Messages ON onMessage() method

Incidentally ,we found our MDB handling duplicate messages ,why does it happen?

from WLS online doc,I get the infos:

"If the MDB receives the message, but fails to send an acknowledgement, the JMS producer re-sends the same message ,even the onMessage() method successful completed

So ,If the MDB manages its own transactions, then your onMessage() code must be prepared to handle duplicate messages"

The resolve way is Using the CMT on MDB
1. Set the transaction-type element inside the message-driven element in the ejb-jar.xml file to Container.

2. Set the trans-attribute element inside the container-transaction attribute in the ejb-jar.xml file to Required.

This means message receipt and acknowledgement happen within a transaction; either both happen or neither happens.


Ok , it 's very simple, But in this way ,what's difference between the synchronous & asynchronous in this scenario, asynchronous in a big transaction is looks like a synchronous method with local trans, decouple a little?

IMHO,Customer will take a good think in this scenario

*******************************************************
another notes

when using the MDB ,you should take care the sender 's transaction setting ,when set the jmsConnectionFactory,Don't forget the UserTransactionsEnabled option,which means whether send method is JTA aware

jspc error when meet the struts define tag ON Weblogic8.1 sp1

Customer report , they run the Struts "define tag" on Weblogic8.1 sp1 , but the weblogic omitted <bean:define....>operation

but the same thing on WLS 7.0 is OK

"
we replay the error when we run the Struts example struts-exercise-taglib.war

use the <bean:define> tag
"


when weblogic8.1 jspc(now is APPC) compile any jsp which use the tag , the error occur

now , I have not any idea for it , just wait BEA CS response


==========resolve info======================

it 's seems WLS version control error: we get the rolling patch very soon,it contains the new tag support class

anyone who meet the same error , can contact me for the patch

I belive BEA will renew it in WLS next service patch or else
==========

Server VM & NTSocketMuxer caused deadlock on win2000 sp3 when running WLS

our customer report WLS hang on win2000:(thread dump) :



JAVA STACK INFORMATION FOR THREADS LISTED ABOVE:
------------------------------------------------
Java Stack for "ExecuteThread: '13' for queue: 'default'":
==========
at weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.java:572)
- waiting to lock <44f75d8> (a weblogic.socket.IORecord)
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:
23)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134)
Java Stack for "ExecuteThread: '9' for queue: 'default'":
==========
at weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.java:572)
- waiting to lock <2fd5a78> (a weblogic.socket.IORecord)
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:
23)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134)

Found 1 deadlock.



=======resolve info ==============


we look for the bug at SUN bug list :

seems it 's Bug: 4854464

http://developer.java.sun.com/developer/bugParade/bugs/4854464.html


"JDK 1.3.1_06 hangs/deadlocks on Windows2000 SP3 server. This problem
is specific to server VM, and does not happen using -classic option.
Problem happens using jdk 1.3.1_02 through 1.3.1_06 (not yet sure
about jdk 1.3.1_08), and also happens with jdk 1.4.1_01 (primarily in
Weblogic environment).
"

but the bug status is still In progress, so it give 2 method to overcome it :

1) Use -classic option instead

2) Excluding a particular method using .hotspot_compiler:
exclude weblogic/socket/NTSocketMuxer processSockets


=================================