Arquillain 中的多线程
Multiple threads in Arquillain
我正在编写一个使用一些客户端逻辑和一些服务器端逻辑的测试。在客户端,我对一些操作数据并将其存储在 JMS 队列中的 Web 服务进行 REST 调用。后来我调用 JMS 以查看写入 JMS 主题的内容,并得到了一些令人惊讶的结果。
下面是定义此问题的测试代码中有趣的部分:
@Test
@OperateOnDeployment("my-deployable")
public void testMessageInTopic() throws Exception {
// make a rest call with the minimal request
makeRequest(getMyXmlAsString());
// compare the message with the one sent to the topic
connection = factory.createConnection();
final Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
final MessageConsumer consumer = session.createConsumer(topic);
connection.start();
System.out.println("### listening for a response");
final TextMessage receivedMessage = (TextMessage) consumer.receive();
final String expectedString = "sampleFromTest"
final String receivedText = receivedMessage.getText();
System.out.println("### got this message " + receivedText);
assertEquals("the message in the received topic is the same", expectedString, receivedText);
System.out.println("#### the message was as expected");
}
makeRequest(final String data) 方法执行以下操作:
public makeRequest(final String data) {
final String url = getAppEndpoint("http://localhost:8080/doit");
final ClientRequest req= new ClientRequest(url);
req.header(HttpHeaderNames.CONTENT_TYPE, MediaType.TEXT_PLAIN);
req.body(MediaType.TEXT_PLAIN, data);
response = req.post(MyResponse.class);
}
观察日志时,我得到的消息顺序如下:
09:38:59,448 INFO [stdout] (pool-2-thread-1) ### got this message sampleFromTest
09:38:59,448 INFO [stdout] (pool-2-thread-1) #### the message was as expected
09:38:59,488 INFO [stdout] (pool-2-thread-2) ### listening for a response
很明显,嵌入式测试和客户端测试结合起来效果不佳,因为线程成为一个问题。我可以通过在我的@Before 测试方法中进行其余调用,或者通过注入 web 服务并以编程方式用请求命中它来潜在地规避这个问题。然而,由于我的兴趣在于测试完整的集成路径,混合客户端和服务器请求似乎是个好主意。那么我的问题是,是否可以 运行 我们发出客户端请求并解析容器接收到的数据的场景?
原来我遇到了这种差异,因为我在调用 jms receive() 方法时没有添加显式等待。因此,上面的输出是正确的:
09:38:59,448 INFO [stdout] (pool-2-thread-1) ### got this message sampleFromTest
09:38:59,448 INFO [stdout] (pool-2-thread-1) #### the message was as expected
09:38:59,488 INFO [stdout] (pool-2-thread-2) ### listening for a response
为了解决我的问题,我做了类似的事情来在执行更多代码之前添加一个显式的同步等待:
final TextMessage message = (TextMessage) consumer.receive(15000);
这样,在写完一条消息后,我最多等待 15 秒,让它慢慢回落。虽然我永远无法证明
### listening for a response
之前从未发生过
09:38:59,448
原题中,采用这种方式确实解决了问题。
我正在编写一个使用一些客户端逻辑和一些服务器端逻辑的测试。在客户端,我对一些操作数据并将其存储在 JMS 队列中的 Web 服务进行 REST 调用。后来我调用 JMS 以查看写入 JMS 主题的内容,并得到了一些令人惊讶的结果。
下面是定义此问题的测试代码中有趣的部分:
@Test
@OperateOnDeployment("my-deployable")
public void testMessageInTopic() throws Exception {
// make a rest call with the minimal request
makeRequest(getMyXmlAsString());
// compare the message with the one sent to the topic
connection = factory.createConnection();
final Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
final MessageConsumer consumer = session.createConsumer(topic);
connection.start();
System.out.println("### listening for a response");
final TextMessage receivedMessage = (TextMessage) consumer.receive();
final String expectedString = "sampleFromTest"
final String receivedText = receivedMessage.getText();
System.out.println("### got this message " + receivedText);
assertEquals("the message in the received topic is the same", expectedString, receivedText);
System.out.println("#### the message was as expected");
}
makeRequest(final String data) 方法执行以下操作:
public makeRequest(final String data) {
final String url = getAppEndpoint("http://localhost:8080/doit");
final ClientRequest req= new ClientRequest(url);
req.header(HttpHeaderNames.CONTENT_TYPE, MediaType.TEXT_PLAIN);
req.body(MediaType.TEXT_PLAIN, data);
response = req.post(MyResponse.class);
}
观察日志时,我得到的消息顺序如下:
09:38:59,448 INFO [stdout] (pool-2-thread-1) ### got this message sampleFromTest
09:38:59,448 INFO [stdout] (pool-2-thread-1) #### the message was as expected
09:38:59,488 INFO [stdout] (pool-2-thread-2) ### listening for a response
很明显,嵌入式测试和客户端测试结合起来效果不佳,因为线程成为一个问题。我可以通过在我的@Before 测试方法中进行其余调用,或者通过注入 web 服务并以编程方式用请求命中它来潜在地规避这个问题。然而,由于我的兴趣在于测试完整的集成路径,混合客户端和服务器请求似乎是个好主意。那么我的问题是,是否可以 运行 我们发出客户端请求并解析容器接收到的数据的场景?
原来我遇到了这种差异,因为我在调用 jms receive() 方法时没有添加显式等待。因此,上面的输出是正确的:
09:38:59,448 INFO [stdout] (pool-2-thread-1) ### got this message sampleFromTest
09:38:59,448 INFO [stdout] (pool-2-thread-1) #### the message was as expected
09:38:59,488 INFO [stdout] (pool-2-thread-2) ### listening for a response
为了解决我的问题,我做了类似的事情来在执行更多代码之前添加一个显式的同步等待:
final TextMessage message = (TextMessage) consumer.receive(15000);
这样,在写完一条消息后,我最多等待 15 秒,让它慢慢回落。虽然我永远无法证明
### listening for a response
之前从未发生过
09:38:59,448
原题中,采用这种方式确实解决了问题。