Using the activemq jms for queue mechanism, I would like to monitor my queue for example the size of the queue. And i am using Jolokia as the bridge to perform rest requests on JMX.
Queue is configured in the wildfly and works fine:
<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
<server name="default">
<http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor"/>
...
</http-connector>
<http-acceptor name="http-acceptor" http-listener="default"/>
...
</http-acceptor>
<jms-queue name="QueueName" entries="java:/jms/queue/QueueName"/>
<pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm" transaction="xa"/>
</server>
</subsystem>
I have deployed Jolokia war file on wildfly under deployments and the following url brings me a list of attributes:
localhost:8080/jolokia/list
Now i would like to read information about my queue, so i use the following rest request:
localhost:8080/jolokia/read/org.apache.activemq.artemis:module=JMS,type=Queue,name=*QueueName*
However, this throws back the following exception:
"stacktrace": "javax.management.InstanceNotFoundException: No MBean with pattern org.apache.activemq.artemis:module=JMS,type=Queue,name=*QueueName* found for reading attributes\n\tat org.jolokia.handler.ReadHandler.searchMBeans(ReadHandler.java:160)\n\tat org.jolokia.handler.ReadHandler.fetchAttributesForMBeanPattern(ReadHandler.java:126)\n\tat org.jolokia.handler.ReadHandler.doHandleRequest(ReadHandler.java:116)\n\tat org.jolokia.handler.ReadHandler.doHandleRequest(ReadHandler.java:37)\n\tat org.jolokia.handler.JsonRequestHandler.handleRequest(JsonRequestHandler.java:161)\n\tat org.jolokia.backend.MBeanServerHandler
I have tried to enable the jmx in standalone by adding the jmx subsystem as following:
<subsystem xmlns="urn:jboss:domain:jmx:1.3">
<remoting-connector use-management-endpoint="false"/>
</subsystem>
<connector socket-binding="jmx-remote" name="jmx-remote-connector" security- realm="ApplicationRealm"/>
<socket-binding name="jmx-remote" port="${jboss.jmx.port:7909}" fixed-port="false"/>
But it still does not work. Any help regarding the corrections for my approach or an alternative approach would be appreciated.
If *QueueName* contains a / it needs to be escaped using !/. For example jms/inputq must be converted to jms!/inputq.
If you want to avoid the escaping you can use a query parameter q. The url then ends up looking like /jolokia?p=/read/....
For more information about escaping, see https://jolokia.org/reference/html/protocol.html
Related
I got this warning while I run wildFly server
16:54:56,327 WARN [org.wildfly.clustering.web.undertow] (ServerService Thread Pool -- 77) WFLYCLWEBUT0007: No routing provider found for default-server; using legacy provider based on static configuration
To get rid of this warining, you have to add the following entries to your Wildfly standalone.xml:
Add the org.wildfly.extension.clustering.web extension inside the <extensions> tag
<extension module="org.wildfly.extension.clustering.web"/>
Add the <distributable-web> subsystem inside the <profile> tag
Wildfly 21:
<subsystem xmlns="urn:jboss:domain:distributable-web:2.0" default-session-management="default" default-single-sign-on-management="default">
<infinispan-session-management name="default" cache-container="web" granularity="SESSION">
<primary-owner-affinity/>
</infinispan-session-management>
<infinispan-single-sign-on-management name="default" cache-container="web" cache="sso"/>
<infinispan-routing cache-container="web" cache="routing"/>
</subsystem>
Wildfly 23 and 26:
<subsystem xmlns="urn:jboss:domain:distributable-web:2.0" default-session-management="default" default-single-sign-on-management="default">
<infinispan-session-management name="default" cache-container="web" granularity="SESSION">
<local-affinity/>
</infinispan-session-management>
<infinispan-single-sign-on-management name="default" cache-container="web" cache="sso"/>
<local-routing/>
</subsystem>
I am migrating my jboss eap 6 to wildfly 18 as we are moving our application from java 6 to java 8 . I am new to wildfly 18, while starting the server I am getting below error -
09:22:59,671 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=undertow/server=default-server/https-listener=https' are not available:
org.wildfly.network.socket-binding.https; Possible registration points for this capability:
/socket-binding-group=*/socket-binding=*
09:22:59,672 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=undertow/server=default-server/http-listener=http' are not available:
org.wildfly.network.socket-binding.https; Possible registration points for this capability:
/socket-binding-group=*/socket-binding=*
09:22:59,678 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.**
09:22:59,698 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0050: WildFly Full 18.0.0.Final (WildFly Core 10.0.0.Final) stopped in 13ms
I changed socket bindinfs in standalone.xml file and standalone-ha.xmlAdded Socket binding changes in both files -
As i copied all these sockets from previous jboss eap 6 files.
Can i get explanation why these different 2 socket bindings needed and also worked in jboss?
What capabilities is it searching for? do i need to add some externals?
Need suggestions on this .. Do am i missing something in standalone.xml file? or package in module folder? I am confused, need to solve this issue as soon i can..
Thank you in advance!!
As #Shrishti Jain mentioned socket-binding for http would have not present in both standalone.xml and standalone-ha.xml which could be one possible reason for the error.
There is an another possibility for the above error.
As the console error log('/subsystem=undertow/server=default-server/http-listener=http' are not available) clearly gives a hint that http-listener for listener-name http under subsystem configuration for undertow server with the server name "default-server" is not available or not configured properly. The section you have to check is mentioned below
<!-- subsystem section for undertow server(subsystem=undertow/server) -->
<subsystem xmlns="urn:jboss:domain:undertow:3.1">
<buffer-cache name="default"/>
<!-- server=default-server -->
<server name="default-server">
<!-- http-listener=http -->
<http-listener name="http" socket-binding="http-new" max-post-size="6442450944" redirect-socket="https" enable-http2="true"/>
<https-listener name="https" socket-binding="https" max-post-size="6442450944" security-realm="SSLRealm" enable-http2="true"/>
....
</subsystem>
In the above snippet there are chances where the socket-binding of "http-new" might have not configured properly. In the above case the socket-binding of http-new is not present in <socket-binding-group>
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
....
<socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
<socket-binding name="http" port="${jboss.http.port:8080}"/>
<socket-binding name="https" port="${jboss.https.port:8443}"/>
</socket-binding-group>
NOTE:
The issue causing listener's socket-binding configuration should exist in both standalone.xml and standalone-ha.xml files
For this error - https , management-https ports were missing in standalone-ha.xml. We have to sure it should be there in both standalone and standalone-ha xml files.
I installed eap7.1 on RHEL73, everything works fine, but failed to use jconsole to connect server instance, I didn't find anything related with how to set jmx component on eap7.1, but found something for eap6, here is main points I found:
Should disable management binding and enable an remote binding:
Add option as eap server startup option:
-Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl
-Djboss.platform.mbeanserver
Use $JBOSS_HOME/bin/jconsole.sh to startup jconsole
But I always failed with jconsole reponse as " the connection to service:jmx:remote://192.168.56.11:4447 did not succeed"
Here is key point of domain.xml
...
<subsystem xmlns="urn:jboss:domain:remoting:4.0">
<endpoint/>
<connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
<http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
</subsystem>
...
<subsystem xmlns="urn:jboss:domain:jmx:1.3">
<expose-resolved-model/>
<expose-expression-model/>
<remoting-connector use-management-endpoint="false"/>
</subsystem>
...
<socket-binding-group name="ha-sockets" default-interface="public">
...
<socket-binding name="remoting" port="4447"/>
...
</socket-binding-group>
server startup successfully with the following log
"INFO [org.jboss.as.remoting] (MSC service thread 1-1) WFLYRMT0001: Listening on 192.168.56.11:4447"
netstat -an shows 4447 is ready.
The following is some guides on eap6 I followed:
https://access.redhat.com/solutions/149973
https://access.redhat.com/solutions/443033
https://access.redhat.com/solutions/413283
https://kb.novaordis.com/index.php/JMX_Access_to_Domain_Mode_EAP_7_Server_Node(this is for eap7)
Is there anything special on JMX for eap7.1?
Best regards
Lan
I have the same problems as you. My quick fix is:
change this:
<connector name="remoting-connector" socket-binding="remoting" **security-realm="ApplicationRealm"**/>
to this:
<connector name="remoting-connector" socket-binding="remoting" security-realm="ManagementRealm"/>
or remove realm:
<connector name="remoting-connector" socket-binding="remoting"/>
Probably I have a wrong user in ApplicationRealm or don't have the permission. I use this in zabbix jmx monitoring in domain mode with wildfly 10, 10.1 and 11.
You can connect the jconsole to EAP 7.1 with default configuration using the management realm. You just have to:
add a management user, via $JBOSS_HOME/bin/add-user.sh
start EAP
connect to jmx service address
service:jmx:remote+http://127.0.0.1:9990 via
$JBOSS_HOME/bin/jconsole.sh using credentials defined in above step
n.b.: The protokoll may differ from previous versions of eap
I have created a bounded-queue-thread-pool in Jboss 7.2.0 standalone.xml as follows:
<subsystem xmlns="urn:jboss:domain:threads:1.1">
<bounded-queue-thread-pool name="myThreadPool">
<core-threads count="6000"/>
<queue-length count="1000"/>
<max-threads count="6000"/>
<keepalive-time time="60" unit="seconds"/>
</bounded-queue-thread-pool>
</subsystem>
After that I am using this as executor in AJP connectors as follows:
<connector name="conn1" protocol="AJP/1.3" scheme="http" socket-binding="conn1" enabled="true" max-post-size="0" executor="myThreadPool" max-connections="2000"/>
<connector name="conn2" protocol="AJP/1.3" scheme="http" socket-binding="conn2" enabled="true" executor="myThreadPool" max-connections="2000"/>
<connector name="conn3" protocol="AJP/1.3" scheme="http" socket-binding="conn3" enabled="true" executor="myThreadPool" max-connections="2000"/>
At the end the socket binding for 3 connectors:
<socket-binding name="conn1" port="15007"/>
<socket-binding name="conn2" port="15008"/>
<socket-binding name="conn3" port="15009"/>
When I start jboss and create multiple http requests, each request thread is created as myThreadPool-threads-1, myThreadPool-threads-2 etc. However when I shutdown jboss using command line, these threads are not getting terminated. Here is the command I use to shutdown:
%JBOSS_HOME%\bin\jboss-cli.bat --connect controller=10.10.54.85:9999 --commands=:shutdown
Due to this, the java process of jboss-AS is not getting killed. However when I simply remove the executor from connector, the java process is terminated successfully. Can someone suggest me how to terminated all the threads of threadPool when server is shutdown?
Probably this bug is a cause of your problem, a workaround is set:
org.apache.coyote.ajp.DEFAULT_CONNECTION_TIMEOUT
Add the following to your system-properties in your host.xml, standalone.xml or domain.xml:
<system-properties>
<property name="org.apache.coyote.ajp.DEFAULT_CONNECTION_TIMEOUT" value="600000"/>
<system-properties>
this works except if we continuously send request to the server.
See also: server hang during shutdown when specifying executor in connector
ERROR HQ224018: Failed to create session: HornetQException[errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: null]
When the Jboss EAP 6.3 server is about to receive JMS message. I have the user successfully authenticated by remoting subsystem so why the user is null? How to overcome this error?
EAP documentation encorage you to:
(...) set allowClientLogin to true (...) If you would like HornetQ to
authenticate using the propagated security then set the authoriseOnClientLogin to true also.
But due to HORNETQ-883 bug you have to turn off security for messaging:
<hornetq-server>
<!-- … -->
<security-enabled>false</security-enabled>
<!-- … -->
</hornetq-server>
In short, if your JMS client is connecting from within your JEE container and have no need to supply credentials to connect to JMS (when calling factory.createConnection()), then obtain connections using the InVM Connector. The InVM Connector doesn't require credentials when opening a connection to JMS (since the caller is within the JVM instance, hence the name) but still enforces security for Remote JMS clients. Connectors and ConnectionFactories are configured in the urn:jboss:domain:messaging subsystem of standalone.xml.
Otherwise, if you don't use the InVM Connector with security enabled, you'll probably need to run the add-user script in [jboss-home]/bin to add client credentials to the appilcation-users.properties file and supply those credentials when calling factory.createConnection(username, pwd) for both Remote and InVM clients connecting via Remotely available factories.
Gory Details
In our JBoss EAP 6.4 instance, security needs to remain enabled for remote connections (outside the JVM) so our <security-settings> for HornetQ are specified appropriately. Consequently, the JMS ConnectionFactory dictates the level of security based on which Connector it is configured with.
<hornetq-server>
<connectors>
<!-- additional connectors here -->
...
<in-vm-connector name="in-vm" server-id="0"/>
</connectors>
<jms-connection-factories>
<connection-factory name="InVmConnectionFactory">
<connectors>
<connector-ref connector-name="in-vm"/>
</connectors>
<entries>
<!-- JNDI bindings here -->
<entry name="java:/ConnectionFactory" />
</entries>
</connection-factory>
...
</jms-connection-factories>
So, in the JMS client apply the standard connection boiler-plate:
InitialContext context = new InitialContext();
javax.jms.ConnectionFactory factory = (ConnectionFactory) context.lookup("java:/ConnectionFactory");
and when creating the connection:
javax.jms.Connection connection = factory.createConnection();
Transacted JMS
For Transaction-aware in-container client connections to JMS, our InVM ConnectionFactory is configured like this:
<jms-connection-factories>
...
<pooled-connection-factory name="hornetq-ra">
<transaction mode="xa"/>
<connectors>
<connector-ref connector-name="in-vm"/>
</connectors>
<entries>
<entry name="java:/JmsXA"/>
</entries>
</pooled-connection-factory>
</jms-connection-factories>
Obtain the transacted JMS ConnectionFactory as such:
InitialContext context = new InitialContext();
javax.jms.ConnectionFactory factory = (ConnectionFactory) context.lookup("java:/JmsXA");