I'm currently migrating our code from Jboss7 to Wildfly10.
The Server itself starts up totaly fine.
When trying to connect our client with the working new wildfly10 server for ejb-remote calls it just won't work.
The only thing I get to work with is the following error:
org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector setupEJBReceivers
WARN: Could not register a EJB receiver for connection to remote-ip:8080
java.lang.RuntimeException: Operation failed with status WAITING at
org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:94)
at
org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:80)
at
org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
at
org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:161)
at
org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:118)
at
org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:47)
at
org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:281)
at
org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:291)
at
org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:178)
at
org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
at com.sun.proxy.$Proxy2.connect(Unknown Source) at
de.cinovo.rcp.test.RemoteEJBClient.invokeStatelessBean(RemoteEJBClient.java:39)
at de.cinovo.rcp.test.RemoteEJBClient.main(RemoteEJBClient.java:25)
Exception in thread "main" java.lang.IllegalStateException:
EJBCLIENT000025: No EJB receiver available for handling
[appName:de.cinovo.tcc.server-ear,
moduleName:de-cinovo-tcc-server-ejb-6.0-SNAPSHOT, distinctName:]
combination for invocation context
org.jboss.ejb.client.EJBClientInvocationContext#180542f at
org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:798)
at
org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:128)
at
org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
at
org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
at
org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
at
org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
at
org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
at com.sun.proxy.$Proxy2.connect(Unknown Source) at
de.cinovo.rcp.test.RemoteEJBClient.invokeStatelessBean(RemoteEJBClient.java:39)
at de.cinovo.rcp.test.RemoteEJBClient.main(RemoteEJBClient.java:25)
There is no error, warning, info or anything showing up in the server log, while trying to connect.
There is some action on the port via tcp while watching during a call attempt.
The realy funny part is:
If I use the same wildfly setup on my local machine, the exact same connection method works, but only while using localhost as the ip address within the jboss-ejb-client.properties.
As soon as I change the ip into 127.0.0.1 or my current ip address, it will fail with the same error as above.
Relevant information:
Wildfly will respond to a telnet on port 8080
Wildfly is the only service listening on 8080
My /etc/hosts is correctly configured
Changing the port doesn't fix the problem
Wildfly Version 10.1.0.Final
Relevant parts from my standalone.xml
<subsystem xmlns="urn:jboss:domain:remoting:3.0">
<endpoint/>
<http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
</subsystem>
[...]
<subsystem xmlns="urn:jboss:domain:undertow:3.1">
<buffer-cache name="default"/>
<server name="default-server">
<http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
[...]
</subsystem>
[...]
<interfaces>
<interface name="public">
<any-address/>
</interface>
</interfaces>
[...]
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
<socket-binding name="http" interface="public" port="${jboss.http.port:8080}"/>
<socket-binding name="https" port="${jboss.https.port:8443}"/>
[...]
</socket-binding-group>
My jboss-ejb-client.properties
endpoint.name=client-endpoint
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=<host-ip>
remote.connection.default.port=8080
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
remote.connection.default.username=<usernmae>
remote.connection.default.password=<pswd>
Client-Code
final Hashtable jndiProperties = new Hashtable();
jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
final Context context = new InitialContext(jndiProperties);
[...]
return context.lookup("ejb:" + appName + "/" + moduleName + "/" + distinctName + "/" + beanName + "!" + viewClassName);
EJB-Client-Maven-Dependency :
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-ejb-client-bom</artifactId>
<version>10.1.0.Final</version>
<type>pom</type>
</dependency>
Anyone out there who had the same problem and knows what I'm doing wrong?
Looks like there is a missing definition in the standalone.xml in the socket.binding-group:
<outbound-socket-binding name="remote-ejb">
<local-destination socket-binding-ref="http"/>
</outbound-socket-binding>
So for everybody interested, here is the solution to my problem:
based on the comment by Steve C and the help of a friend, we figured out that the problem is not server based.
It appears that there are some antivirus programs, which do something with your HTTP messages, as soon as the HTTP-upgrade negotiations with the Wildfly/server are done. They seem to manipulate the sent/received packages, which leads to the problem in the client, as it is no longer able to understand the answers.
Therefore it never gets to react, since the package appears to have been lost - hence the IoFuture exception and EJB receiver not found.
Long story short: removing the antivirus program from our systems (in our case Bitdefender) leads to everything working as intended...
Related
I have a Wildfly messaging live/backup pair and a single Wildfly instance as application server (all version 26.0.1). I'm using Wildfly with the integrated ActiveMQ server as remote messaging brokers (not plain ActiveMQ servers directly).
For testing I use
the helloworld-mdb quickstart example (https://github.com/wildfly/quickstart/tree/main/helloworld-mdb) deployed on the Wildfly application server with MDBs receiving messages and a servlet for sending messages using an injected JmsContext and injected Queue/Topic (I renamed the queue/topic and removed the #JMSDestinationDefinitions in order to define the destinations in the messaging-activemq subysystem configuration)
and two simple JMS client programs: one for sending messages to a queue, and one for receiving messages from a queue (they just go the default route: obtain an InitialContext, look up a destination and a connection factory, and create a connection and a session)
My setup almost works. The client programs and MDBs reconnect automatically on messaging broker failover/failback. However, the servlet from the quickstart example blocks when sending messages after the live/backup pair fails over, and no messages are sent. It fails after around one minute with the following stack trace:
12:15:53,496 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /helloworld-mdb/HelloWorldMDBServletClient: javax.jms.JMSRuntimeException: AMQ219014: Timed out after waiting 30,000 ms for response when sending packet 71
at org.apache.activemq.artemis#2.19.0//org.apache.activemq.artemis.jms.client.JmsExceptionUtils.convertToRuntimeException(JmsExceptionUtils.java:88)
at org.apache.activemq.artemis#2.19.0//org.apache.activemq.artemis.jms.client.ActiveMQJMSProducer.send(ActiveMQJMSProducer.java:100)
at org.apache.activemq.artemis#2.19.0//org.apache.activemq.artemis.jms.client.ActiveMQJMSProducer.send(ActiveMQJMSProducer.java:124)
at deployment.helloworld-mdb.war//org.jboss.as.quickstarts.servlet.HelloWorldMDBServletClient.doGet(HelloWorldMDBServletClient.java:95)
at javax.servlet.api#2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:503)
at javax.servlet.api#2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at io.opentracing.contrib.opentracing-jaxrs2//io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:52)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.security.elytron-web.undertow-server#1.10.1.Final//org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.lambda$handleRequest$1(ElytronRunAsHandler.java:68)
at org.wildfly.security.elytron-base#1.18.3.Final//org.wildfly.security.auth.server.FlexibleIdentityAssociation.runAsFunctionEx(FlexibleIdentityAssociation.java:103)
at org.wildfly.security.elytron-base#1.18.3.Final//org.wildfly.security.auth.server.Scoped.runAsFunctionEx(Scoped.java:161)
at org.wildfly.security.elytron-base#1.18.3.Final//org.wildfly.security.auth.server.Scoped.runAs(Scoped.java:73)
at org.wildfly.security.elytron-web.undertow-server#1.10.1.Final//org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.handleRequest(ElytronRunAsHandler.java:67)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:117)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.core#2.2.14.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.core#2.2.14.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.core#2.2.14.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at org.wildfly.security.elytron-web.undertow-server-servlet#1.10.1.Final//org.wildfly.elytron.web.undertow.server.servlet.CleanUpHandler.handleRequest(CleanUpHandler.java:38)
at io.undertow.core#2.2.14.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow#26.0.1.Final//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.core#2.2.14.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow#26.0.1.Final//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
at io.undertow.core#2.2.14.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:275)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:79)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:134)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:131)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow#26.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1544)
at org.wildfly.extension.undertow#26.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1544)
at org.wildfly.extension.undertow#26.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1544)
at org.wildfly.extension.undertow#26.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1544)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:255)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:79)
at io.undertow.servlet#2.2.14.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:100)
at io.undertow.core#2.2.14.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
at io.undertow.core#2.2.14.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:852)
at org.jboss.threads#2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads#2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jboss.threads#2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads#2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at org.jboss.xnio#3.8.5.Final//org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: javax.jms.JMSException: AMQ219014: Timed out after waiting 30,000 ms for response when sending packet 71
at org.apache.activemq.artemis#2.19.0//org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:539)
at org.apache.activemq.artemis#2.19.0//org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:443)
at org.apache.activemq.artemis#2.19.0//org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sendFullMessage(ActiveMQSessionContext.java:552)
at org.apache.activemq.artemis#2.19.0//org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendRegularMessage(ClientProducerImpl.java:296)
at org.apache.activemq.artemis#2.19.0//org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:268)
at org.apache.activemq.artemis#2.19.0//org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:143)
at org.apache.activemq.artemis#2.19.0//org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:125)
at org.apache.activemq.artemis#2.19.0//org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:483)
at org.apache.activemq.artemis#2.19.0//org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:220)
at org.apache.activemq.artemis#2.19.0//org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:207)
at org.apache.activemq.artemis.ra#2.19.0//org.apache.activemq.artemis.ra.ActiveMQRAMessageProducer.send(ActiveMQRAMessageProducer.java:137)
at org.apache.activemq.artemis#2.19.0//org.apache.activemq.artemis.jms.client.ActiveMQJMSProducer.send(ActiveMQJMSProducer.java:97)
... 53 more
Caused by: ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ219014: Timed out after waiting 30,000 ms for response when sending packet 71]
... 65 more
I followed 7.8.12. Connect a pooled-connection-factory to a Remote Artemis Server, but I'm using http-connectors instead of remote-connectors because of using Wildfly as remote brokers.
All configurations are based on standalone-full-ha.xml with just the following modifications.
Messaging live Wildfly server "messaging-node-1":
changed cluster password
added replication-master
changed cluster connection name
added two destinations
...
<subsystem xmlns="urn:jboss:domain:messaging-activemq:13.0">
<server name="default">
<security elytron-domain="ApplicationDomain"/>
<cluster password="${jboss.messaging.cluster.password:**changed-password**}"/>
<statistics enabled="${wildfly.messaging-activemq.statistics-enabled:${wildfly.statistics-enabled:false}}"/>
<replication-master cluster-name="messaging-cluster" group-name="activemq-group"/><!-- added -->
<security-setting name="#">
<role name="guest" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true"/>
</security-setting>
<address-setting name="#" dead-letter-address="jms.queue.DLQ" expiry-address="jms.queue.ExpiryQueue" max-size-bytes="10485760" page-size-bytes="2097152" message-counter-history-day-limit="10" redistribution-delay="1000"/>
<http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor"/>
<http-connector name="http-connector-throughput" socket-binding="http" endpoint="http-acceptor-throughput">
<param name="batch-delay" value="50"/>
</http-connector>
<in-vm-connector name="in-vm" server-id="0">
<param name="buffer-pooling" value="false"/>
</in-vm-connector>
<http-acceptor name="http-acceptor" http-listener="default"/>
<http-acceptor name="http-acceptor-throughput" http-listener="default">
<param name="batch-delay" value="50"/>
<param name="direct-deliver" value="false"/>
</http-acceptor>
<in-vm-acceptor name="in-vm" server-id="0">
<param name="buffer-pooling" value="false"/>
</in-vm-acceptor>
<jgroups-broadcast-group name="bg-group1" jgroups-cluster="activemq-cluster" connectors="http-connector"/>
<jgroups-discovery-group name="dg-group1" jgroups-cluster="activemq-cluster"/>
<cluster-connection name="messaging-cluster" address="jms" connector-name="http-connector" discovery-group="dg-group1"/>
<jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
<jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>
<jms-queue name="TestQueue" entries="java:jboss/exported/queue/TestQueue" durable="true"/>
<jms-topic name="TestTopic" entries="java:jboss/exported/topic/TestTopic"/>
<connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
<connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector" ha="true" block-on-acknowledge="true" reconnect-attempts="-1"/>
<pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm" transaction="xa"/>
</server>
</subsystem>
...
Messaging backup Wildfly server "messaging-node-2"
Same as above except replication-master replaced by replication-slave
...
<subsystem xmlns="urn:jboss:domain:messaging-activemq:13.0">
<server name="default">
...
<replication-slave cluster-name="messaging-cluster" group-name="activemq-group"/>
...
</server>
</subsystem>
...
Application Wildfly server "application-node-1"
Replaced integrated ActiveMQ server definition with a remote broker and added external destinations. Notice the use of the default name and JNDI entries for the connection factory (for the EE and EJB subsystems):
...
<subsystem xmlns="urn:jboss:domain:messaging-activemq:13.0">
<http-connector name="node-1-http-connector" socket-binding="messaging-node-1" endpoint="http-acceptor"/>
<http-connector name="node-2-http-connector" socket-binding="messaging-node-2" endpoint="http-acceptor"/>
<pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="node-1-http-connector node-2-http-connector" user="JmsTest" password="JmsTest"/>
<external-jms-queue name="TestQueue" entries="java:/queue/TestQueue"/>
<external-jms-topic name="TestTopic" entries="java:/topic/TestTopic"/>
</subsystem>
...
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
...
<outbound-socket-binding name="messaging-node-1">
<remote-destination host="..." port="8180"/>
</outbound-socket-binding>
<outbound-socket-binding name="messaging-node-2">
<remote-destination host="..." port="8180"/>
</outbound-socket-binding>
</socket-binding-group>
...
The servlet:
#WebServlet("/HelloWorldMDBServletClient")
public class HelloWorldMDBServletClient extends HttpServlet {
private static final long serialVersionUID = -8314035702649252239L;
private static final int MSG_COUNT = 5;
#Inject
private JMSContext context;
#Resource(lookup = "java:/queue/TestQueue")
private Queue queue;
#Resource(lookup = "java:/topic/TestTopic")
private Topic topic;
#Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
resp.setContentType("text/html");
PrintWriter out = resp.getWriter();
out.write("<h1>Quickstart: Example demonstrates the use of <strong>JMS 2.0</strong> and <strong>EJB 3.2 Message-Driven Bean</strong> in JBoss EAP.</h1>");
try {
boolean useTopic = req.getParameterMap().keySet().contains("topic");
final Destination destination = useTopic ? topic : queue;
out.write("<p>Sending messages to <em>" + destination + "</em></p>");
out.write("<h2>The following messages will be sent to the destination:</h2>");
for (int i = 0; i < MSG_COUNT; i++) {
String text = "This is message " + (i + 1);
**context.createProducer().send(destination, text); // fails**
out.write("Message (" + i + "): " + text + "</br>");
}
out.write("<p><i>Go to your JBoss EAP server console or server log to see the result of messages processing.</i></p>");
} finally {
if (out != null) {
out.close();
}
}
}
protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
doGet(req, resp);
}
}
Procedure: start the live/backup pair and the application server, deploy helloworld-mdb.war to the application server and load the servlet page in a web browser. For failover, shut down the live messaging server. Reload the servlet page in the web browser. Result: the web browser keeps waiting for around one minute and then receives what the servlet has printed so far ("...The following messages will be sent to the destination:" <EOF>).
Sending and receiving messages using the JMS client programs works after failover. MDBs keep receiving messages after failover. Just application server message sending fails.
I have unsuccessfully
tried changing the timeout configuration values of the cluster connection
moved message sending to a stateless session bean (in order to test transactions)
replaced the JmsContext with a connection factory to no avail; createSession() blocks, then fails with "...Caused by: ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ219014: Timed out after waiting 30,000 ms for response when sending packet 63]"
...
#Resource(mappedName = "java:/JmsXA")
private ConnectionFactory connectionFactory;
#Resource(mappedName = "java:/queue/TestQueue")
private Queue queue;
...
Connection connection = connectionFactory.createConnection();
Session session = connection.createSession();
Questions:
Are the messaging and application server configurations correct for my setup?
What could be the reason that sending messages using the injected JmsContext and Queue fails after failover?
I would appreciate any help.
Update 1
Just FYI: The application server notices when the live messaging server goes down:
17:11:40,908 WARN [org.apache.activemq.artemis.core.client] (Thread-2 (ActiveMQ-client-global-threads)) AMQ212037: Connection failure to 172.*.*.*/172.*.*.*:8180 has been detected: AMQ219015: The connection was disconnected because of server shutdown [code=DISCONNECTED]
...repeated around 30 times and an Exception:
17:11:40,904 WARN [org.jboss.activemq.artemis.wildfly.integration.recovery] (Thread-2 (ActiveMQ-client-global-threads)) being disconnected for server shutdown: ActiveMQDisconnectedException[errorType=DISCONNECTED message=AMQ219015: The connection was disconnected because of server shutdown]
at org.apache.activemq.artemis#2.19.0//org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:1089)
at org.apache.activemq.artemis.journal//org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
at org.apache.activemq.artemis.journal//org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
at org.apache.activemq.artemis.journal//org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at org.apache.activemq.artemis.journal//org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
I am load testing an application deployed on Wildfly 20 using JMeter. The observation is that under load of 300 requests/sec and more Wildfly server doesn't respond to few requests and those requests time out. On analyzing server logs (both system and application) and thread dumps nothing related to this is found and memory utilization is also normal.
On tuning some parameters such as Open File Descriptors, Wildfly IO threads/Task Max Threads, Max Connections and Apache configuration [details below] the number of requests getting timed out have significantly reduced but still a lot of requests time out.
Using Wildfly Runtime for monitoring during load testing one thing drew my attention that even on setting the Undertow's Http Max Connections parameter to a value lets say 1000 the Connection Count value (circled in screenshot below) never exceeds 256. On playing with this parameter a bit I saw that Http Max Connections parameter sets to any value less than 256 but never more. And it looks like once this limit is reached no new request is served as gets timed out until some connections are freed.
Is there is some other configuration (Apache or OS) which puts this limit or any other Wildfly configuration responsible for this? Am I missing anything?
[Used Wildfly Management Console for all configurations]
[from standalone.xml]
<subsystem xmlns="urn:jboss:domain:io:3.0">
<worker name="default" io-threads="300" task-max-threads="300"/>
<buffer-pool name="default"/>
</subsystem>
...
<subsystem xmlns="urn:jboss:domain:undertow:11.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other" statistics-enabled="true">
<buffer-cache name="default"/>
<server name="default-server">
<http-listener name="default" max-connections="500" socket-binding="http" max-cookies="100" record-request-start-time="true" redirect-socket="https" enable-http2="true"/>
<https-listener name="https" socket-binding="https" max-cookies="100" record-request-start-time="true" security-realm="ApplicationRealm" enable-http2="true"/>
<host name="default-host">
<location name="/" handler="welcome-content"/>
<filter-ref name="limit-connections"/>
<http-invoker security-realm="ApplicationRealm"/>
</host>
</server>
<servlet-container name="default">
<jsp-config/>
<websockets/>
</servlet-container>
<handlers>
<file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
</handlers>
<filters>
<request-limit name="limit-connections" max-concurrent-requests="10000" queue-size="10000"/>
</filters>
</subsystem>
[Apache configuration]
<IfModule mpm_worker_module>
ServerLimit 40
StartServers 2
MaxClients 1000
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
</IfModule>
[Wildfly Runtime monitoring console during testing]
Maybe your server is not tuned to cater the maximum number of processes? Add the following to your /etc/security/limits.conf file:
jboss soft nproc 8000
jboss hard nproc 12000
jboss soft nofile 9999
jboss hard nofile 9999
I'm migrating from JBoss 6.4.3 to JBoss 7.2 and saw a Valves are no longer supported warning during deployment. This came from a jboss-web.xml file with:
<valve>
<class-name>org.jboss.web.rewrite.RewriteValve</class-name>
</valve>
...and a corresponding rewrite.properties file:
RewriteCond %{HTTP:X-Forwarded-Proto} http
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
Could anyone advise how to rewrite this (no pun intended) for Undertow?
You can create a rewrite filter in the Undertow subsystem, and then reference it in the server host within the configuration file (standalone.xml or domain.xml - depending on the mode in which you start the application server).
I can think of two options, which might help you:
Using the JBoss Application Server Client (should be placed in path/to/jboss-7.2/bin/)
Creating the rewrite filter with the custom name redirect-http-to-https:
./jboss-cli.sh --connect --command="/subsystem=undertow/configuration=filter/rewrite=redirect-http-to-https:add(redirect=\"true\",target=\"https://%{LOCAL_SERVER_NAME}%{REQUEST_URL}\")"
Using/referencing the filter redirect-http-to-https:
./jboss-cli.sh --connect --command="/subsystem=undertow/server=default-server/host=default-host/filter-ref=redirect-http-to-https:add(predicate=\"equals(%p,80)\")"
Manually editing the respective config file (e.g. standalone.xml)
<subsystem xmlns="urn:jboss:domain:undertow:11.0" default-server="default-server" [...]>
<buffer-cache name="default"/>
<server name="default-server">
[...]
<host name="default-host" alias="localhost">
<filter-ref name="redirect-http-to-https" predicate="equals(%p,80)"/>
</host>
</server>
[...]
<filters>
<rewrite name="redirect-http-to-https" target="https://%{LOCAL_SERVER_NAME}%{REQUEST_URL}" redirect="true"/>
</filters>
</subsystem>
Note: For the Undertow exchange attributes (e.g. LOCAL_SERVER_NAME) refer to Undertow documentation. Further, the part predicate=\"equals(%p,80)\" in the filter-refchecks the requested port (%p -> just another Undertow exchange attribute) and if it equals to 80, then it triggers our redirect filter redirect-http-to-https - you can change the port 80 as per your need.
Hello I have a webapp on Wild Fly 12 server and I want a colleague from work to access it. When I try to access it with my ip (from my computer or his) it says it can not connect). It only works from my computer with localhost. This is what I`ve tried:
I replaced in standalone.xml the old tags with this:
<interfaces>
<interface name="management">
<inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
</interface>
<interface name="public">
<inet-address value="${jboss.bind.address:0.0.0.0}"/>
</interface>
</interfaces>
But it doesn`t work...Do you have any solutions ? Thank you
Not that easy to analyze with the given information. Your configuration is correct, it should work.
What have you tested? Connecting to an application or to the Wildfly-Base-URL([YOUR-IP]:8080)?
Are there any other changes in the standalone.xml?
FYI: You don't have to use the binding with 0.0.0.0. It's possible to use <any-address/> instead of <inet-address value="${jboss.bind.address:0.0.0.0}"/>.
I am running JBoss EAP 6.2 (embedded HornetQ 2.3.12.Final) as a standalone Messaging server that will host JMS Queues and Topics.
There will be other JBoss servers that remotely connect to the Messaging Server's Queues and Topics.
Using this Stackoverflow answer: Binding JBoss AS 7 to all interfaces
I made the following change to my standalone-full.xml configuration:
<interfaces>
...
<interface name="public">
<!--<inet-address value="${jboss.bind.address:127.0.0.1}"/>-->
<any-address/>
</interface>
</interfaces>
After making this change, I can successfully connect from other JBoss servers via port 4447 (JBoss Remoting) and writing JMS Client code (ConnectionFactory, Connection, MessageProducer, etc).
JBoss log has the following, which is reassuring:
[org.jboss.as.remoting] (MSC service thread 1-3) JBAS017100:
Listening on 0.0.0.0:4447
However, I cannot connect via a remote MDB. :-( I need to figure this out because we do MDBs and not JMS Client code.
I looked at my JBoss log, and see the following error:
HQ121005: Invalid "host" value "0.0.0.0" detected for "netty" connector.
Switching to "ptenn-fc20.arbfile.org". If this new address is incorrect please
manually configure the connector to use the proper one.
I looked through the <subsystem xmlns="urn:jboss:domain:messaging:1.4"><hornetq-server> ... section and did not see anything about how to specify a different address for the "netty" connector.
It definitely seems that Netty is using the public interface that I specified, I'm puzzled as to why JBoss Remoting (on port 4447) is fine listening on 0.0.0.0, but Netty (on port 5445) is not.
If anyone has any ideas, insight, or suggestions, I would sincerely appreciate it. :-)
Thanks,
Philip
Philip,
The host is specified via the interfaces element of standalone-full-ha.xml.
You then refer to that interface in the socket-bindings element of same config file.
e.g. The sample below binds JMS to a specific IP address and no longer 0.0.0.0...
<interfaces>
<interface name="management">
<!--<inet-address value="${jboss.bind.address.management:127.0.0.1}"/>-->
<inet-address value="0.0.0.0"/>
</interface>
<interface name="public">
<inet-address value="0.0.0.0"/>
<!--just an FYI that we can use the following syntax too-->
<!--<any-address/>-->
</interface>
<interface name="jms"> <-- HERE
<inet-address value="${jboss.bind.address}"/>
</interface>
<!-- TODO - only show this if the jacorb subsystem is added -->
<interface name="unsecure">
<!--
~ Used for IIOP sockets in the standard configuration.
~ To secure JacORB you need to setup SSL
-->
<inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
</interface>
</interfaces>
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
.
.
.
<!--JMS-->
<socket-binding name="messaging" port="5445" interface="jms"/> <-- HERE
.
.
.
</socket-binding-group>
Rob