Hey, I've set the isIdentical and the method that was causing me problems (getValueObject) to be read-only, changed the behaviour of the test class to do a synchroneous receive() after sending the message and it works! The great thing is that eases my work in testing, because instead of having to send messages and wait till they are received to send some more, which would be achieved by using a counter in onMessage, now I can do everything sequentially.


Thank you very much for your help!

Stefan Puiu wrote:


Adrian,


you lost me here, as far as I know a JMS destination can be either a JMS queue or topic, from where either a message listener or a thread calling receive() on the respective destination picks it up. The problem with waiting for replies was the transaction deadlock problem, I've set all get* methods as read-only in my EJB and will try and see if calling receive() still causes a deadlock to happen.

Adrian Brock wrote:

Why don't you get the responses sent to your test?

The test can then wait for all responses or timeout.

Regards,
Adrian

On Fri, 2003-09-26 at 13:30, Stefan Puiu wrote:


Hello Adrian and thanks for the suggestion,

the point is the use case is 100% asynchronous, the JMS client is supposed to do other things and get notified when a reply comes. The processing that the MDB on the other side is doing is quite lengthy also, so this and the nature of the use case made us choose this pattern. On the other hand, in my tests (and only there) I want a synchronous behaviour because otherwise it would be a problem if I'd have to run say 5 test methods - the first method is run, it completes, the second method runs, then the reply the listener waits for arrives, and the two things go in parallel, I think it's kind of messy. On the other hand if the reply fails that won't show up in the JUnit reports, since the processing of replies isn't done in the JUnit process but in the listener onMessage method.

What I would want to have is a test class in which I have a number of testXXX methods that can be run one after another, so that testXXX2 runs after the whole message cycle triggered by testXXX1 completes.

Adrian Brock wrote:



The answer to your specific question is something like
the following in jboss.xml:

<enterprise-beans>
<entity>
<ejb-name>CMRTreeBean</ejb-name>
<local-jndi-name>java:/cmrTransactionTest/TreeLocal</local-jndi-name>
<method-attributes>
<method>
<method-name>get*</method-name>
<read-only>true</read-only>
</method>
<method>
<method-name>isIdentical</method-name>
<read-only>true</read-only>
</method>
</method-attributes>
</entity>



I don't recommend this pattern, there is little point introducing
JMS when you really have a synchronous process. In fact it will perform
much worse, besides a host of other problems you might face.


If the response message went back asynchronously to the client, then it might be worth it.

Regards,
Adrian

On Thu, 2003-09-25 at 16:57, Stefan Puiu wrote:




Hello,

I'm using JBoss 3.2.1, the 1.4.2 Sun JDK on Mandrake Linux 9.1.

I have some test classes that need to send messages on a JMS queue and expect an answer on another queue. I also read some information from a database that I use to build the messages (namely, it's a getter method). Now, I cannot send the messages on the first queue and then use a blocking receive() to wait for replies, because that would cause an application deadlock. The cause for the deadlock, as far as I could understand, was that the testXXX method that would send the message was wrapped in a transaction (the test class inherits from EJBTestCase from JUnitEJB, which wraps all calls to testXXX methods, together with the setUp and tearDown methods, in a single transaction). When a MDB of mine would also need to read the info from the database, there would be a problem, because the first transaction wouldn't have committed yet (it would commit when receiving the message). The test class wasn't modifying the database, it would just look up a value (using a findByName method), so the situation was rather stupid. That's how the method is defined in the module ejb-jar.xml:

          <query-method>
             <method-name>findByName</method-name>
             <method-params>
                      <method-param>java.lang.String</method-param>
             </method-params>
          </query-method>
          <ejb-ql><![CDATA[
             SELECT OBJECT(c)
             FROM Profile c
             WHERE c.name=?1

          ]]></ejb-ql>
       </query>

And in my test class I do something like this:

pHome = (ProfileHome) jndi.lookup ("ca/ProfileEJB");
Profile profile = null;
try {
profile = (Profile) pHome.findByName("CA_Cert").toArray() [0];
}
catch (javax.ejb.FinderException fe) {
throw new RuntimeException (fe);
}
profileId = profile.getValueObject().id;


For now I've made this go away by making the test class inherit from MessageListener and make it listen for replies, but this is kind of ugly since JUnit reports success when sending the message has completed, and it also makes it hard to have more than one test method in that class. How can I solve this? I think there was something on setting certain methods read-only on the O'Reilly site, but I don't have the link anymore. What would be a good way to run these kinds of tests? Would altering method settings for the findByName method suffice?



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user





------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to