Although here it is described that JMX is enabled by default in HornetQ, I do not see any MBeans in jconsole, after connectin to the process of WildFly. What do I miss?
WildFly 8.2.0.Final
HornetQ 2.4.5.Final (here are all component versions in WildFyl 8.2.0.Final)
After backup-ing, edit your server config XML file (e.g standalone-full.xml) and add the jmx-management-enabled XML element, as described here for disabling JMX:
.......
<subsystem xmlns="urn:jboss:domain:messaging:2.0">
<hornetq-server>
<!-- next line is to be added -->
<jmx-management-enabled>true</jmx-management-enabled>
...........
</hornetq-server>
...........
After that restart WildFly.
Related
I have a JAVA application which I want to monitor its JMX attributes using telegraf tool.
The tool provides jolikia plugin to monitor JMX attributes. I have added following dependencies to my app's pom.xml file regarding Maven section of Jolokia documentation:
<dependency>
<groupId>org.jolokia</groupId>
<artifactId>jolokia-core</artifactId>
<version>1.3.7</version>
</dependency>
<dependency>
<groupId>org.jolokia</groupId>
<artifactId>jolokia-client-java</artifactId>
<version>1.3.7</version>
</dependency>
This is my /etc/telegraf/telegraf.conf file:
[[inputs.jolokia]]
context = "/jolokia/"
[[inputs.jolokia.servers]]
name = "wr-core"
host = "192.168.100.175"
port = "1998"
[[inputs.jolokia.metrics]]
name = "send_success"
mbean = "wr-core:type=monitor,name=execution"
attribute = "MessageSendSuccessCount"
The application is up in the provided IP/port (I can connect to it with jconsole). The application has a monitoring section which its object name (as shown in jconsole) is wr-core:type=monitor,name=execution and has the attribute MessageSendSuccessCount. But when I start telegraf service, following error occurs:
Jan 14 14:30:32 ZiZi telegraf[17258]: 2018-01-14T11:00:32Z E! Error in plugin [inputs.jolokia]: error performing request: Error decoding JSON response: invalid character '\x00' looking for beginning of value:
Note that 1998 is my app's jmx port. I also tried using 8778 which is jolokia-agent port; got:
Jan 14 14:40:03 ZiZi telegraf[9150]: 2018-01-14T11:10:03Z E! Error in plugin [inputs.jolokia]: error performing request: Post http://192.168.100.175:8778/jolokia/: dial tcp 192.168.100.175:8778: getsockopt: connection refused
EDIT 1:
I have checked my CLASSPATH and both jolokia-client and jolokia-core were listed: ../lib/jolokia-client-java-1.3.7.jar:../lib/jolokia-core-1.3.7.jar.
EDIT 2:
I have put following lines into my app's execution file:
JOLOKIA_OPTS=-javaagent:$LIB_PATH/jolokia-core-java-1.3.7.jar=port=8778,host=0.0.0.0
JAVA_OPTS="-mx4096M $JAVA_OPTS $JACOCO_OPTS $JOLOKIA_OPTS"
But when I run the file, I get this error (even though ../lib/jolokia-core-java-1.3.7.jar has been listed in the CLASSPATH):
Error opening zip file or JAR manifest missing : ../lib/jolokia-core-java-1.3.7.jar
Error occurred during initialization of VM
agent library failed to init: instrument
Found the solution.
I have skipped maven solution and tried the javaagent approach, but I had misunderstood the usage of javaagent previously; I should address jolokia jvm agent (this helped):
JOLOKIA_OPTS=-javaagent:/root/jolokia-jvm-1.3.7-agent.jar=port=8778,host=0.0.0.0
JAVA_OPTS="-mx4096M $JAVA_OPTS $JACOCO_OPTS $JOLOKIA_OPTS"
Now, my app starts with this log (successfully):
I> No access restrictor found, access to any MBean is allowed
Jolokia: Agent started with URL http://192.168.100.175:8778/jolokia/
In the other side there is no error in the telegraf console for jolokia anymore.
All the observation are implying the jolokia jvm library has been started and works successfully.
I have also found jolokia jmx documentation for using it as dependencies in the project; but since I'm not a JAVA expert (I'm testing the app), I prefer to currently use the javaagent approach and leave it for future study/experience. BTW, it may help the others.
EDIT 1:
I have found and deployed jolokia jvm agent using its spring support.
Configuring it in the spring XML file, I can now have jolokia jvm agent start listening at my app's startup.
Using Eclipse on Windows, a vertx Verticle with a misconfigured cluster.xml shows the following error in the Eclipse console:
11:46:18.536 [hz._hzInstance_1_dev.generic-operation.thread-0] ERROR com.hazelcast.cluster - [192.168.25.8]:5701 [dev] [3.5.2] Node could not join cluster. A Configuration mismatch was detected: Incompatible joiners! expected: multicast, found: tcp-ip Node is going to shutdown now!
11:46:22.529 [vert.x-worker-thread-0] ERROR com.hazelcast.cluster.impl.TcpIpJoiner - [192.168.25.8]:5701 [dev] [3.5.2] com.hazelcast.core.HazelcastInstanceNotActiveException: Hazelcast instance is not active!
This is fine, I know to reconfigure the cluster for multicast. The problem is when I deploy the same code and configuration to Linux, and run it as a fat jar then the same log doesn't show either the hz thread or the vertx worker thread logs. Instead it shows the verticle logs as:
2015-11-05 12:03:09,329 Starting clustered Vertx
2015-11-05 12:03:13,549 ERROR: VerticleService failed to start: java.lang.NullPointerException
So if I run on Linux the log to tell me there's a misconfiguration isn't showing. There's something I am missing in the vertx / maven log config but I don't know what. Maven properties are as follows:
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<exec.mainClass>main.java.eiger.isct.service.Verticle</exec.mainClass>
<log4j.configurationFile>log4j2.xml</log4j.configurationFile>
<hazelcast.logging.type>log4j2</hazelcast.logging.type>
</properties>
and I start the fat jar using:
java -Dlog4j.configuration=log4j2.xml -jar Verticle-0.5-SNAPSHOT-fat.jar
How can I get the hz thread and vertx thread to log on Linux?
I've tried adding a vertx-default-jul-logging.properties file below to the maven resources dir but no luck.
com.hazelcast.level=ALL
java.util.logging.ConsoleHandler.level=ALL
java.util.logging.FileHandler.level=ALL
THANKS for your comment.
Vertx has started logging having added
-Djava.util.logging.config.file=../logging.properties
to the java start command and with the default logging.properties like (and this is a nice config for lower level stuff):
handlers=java.util.logging.ConsoleHandler,java.util.logging.FileHandler
java.util.logging.SimpleFormatter.format=%1$tY-%1$tm-%1$td %1$tH:%1$tM:%1$tS:%1$tL %4$s %2$s %5$s%6$s%n
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
java.util.logging.ConsoleHandler.level=ALL
java.util.logging.FileHandler.level=ALL
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter
java.util.logging.FileHandler.pattern=../logs/vertx.log
.level=ALL
io.vertx.level=ALL
com.hazelcast.level=ALL
io.netty.util.internal.PlatformDependent.level=ALL
and vertx is logging to ../logs/vertx.log on Linux
I need to get some metrics from Wildfly/Undertow, specifically open/max HTTP connections and used threads and correlate it with open database connection count, which I am able to read using jboss-cli:
/subsystem=datasources/data-source=ExampleDS/statistics=pool:read-resource(recursive=true,include-runtime=true)
Is there a way to obtain the HTTP connection statistics in Wildfly 8.2?
In Wildlfy you configure the http connector thread pool specifying a worker configured via the IO subsystem:
IO Subsystem config example:
<subsystem xmlns="urn:jboss:domain:io:1.1">
<worker name="my-worker" io-threads="24" task-max-threads="30" stack-size="20"/>
<worker name="default" />
<buffer-pool name="default"/>
</subsystem>
The worker then gets added to the http-listener (or ajp-listener) using the worker attribtue:
<http-listener name="default" worker="my-worker" socket-binding="http"/>
The IO Subsystem uses the XNIO API, that exposes the statistics in the Mbean org.xnio/Xnio/nio/my-worker. You can have a look at them with a jmx-client or jvisualvm:
But I have no idea how you can read them via jboss-cli.
I have created Web Application by using JSF 2.0, Log 4j 1.2.14 and JBoss 7. When I run testcase, the log file is created. And the log file can't create when I run web application.
I there is anything I need to configur, please tell me.
Take a look at this maybe can help you.
The following filejboss-deployment-structure.xmlneeds to contain the following:
<jboss-deployment-structure>
<deployment>
<!-- Exclusions allow you to prevent the server from automatically adding some dependencies -->
<exclusions>
<module name="org.apache.log4j" />
</exclusions>
</deployment>
</jboss-deployment-structure>
Make sure the configuration file (log4j.xml or log4j.properties) is in the classpath of the web application (in this case, in the binaries).
WEB-INF/classes/log4j.properties
If you have both files (log4.properties, log4j.xml) only is considered log4j.xml. The first time you init or use some instance of org.apache.log4j.Logger, log4j search the configuration file in the classpath, then the configuration is loaded.
If you want to see this process of searching and loading more closely, add the following argument to the virtual machine:
-Dlog4j.debug
I just have a test. Config jndi in $CATALINA_HOME/conf/context.xml like below:
<Resource name="jdbc/db" auth="Container" type="javax.sql.DataSource" driverClassName="oracle.jdbc.OracleDriver" url="jdbc:oracle:thin:#tnsname" username="test" password="test" maxActive="20" maxIdle="10" defaultAutoCommit="false" maxWait="5000" validationQuery="select 1 from dual" testWhileIdle="true" timeBetweenEvictionRunsMillis="5000" removeAbandoned="true" removeAbandonedTimeout="30" logAbandoned="true" />
and I didn't config it in any others places like $CATALINA_HOME/conf/server.xml or /WEB-INF/web.xml or WEB-INF/context.xml. But I still can use it normally in JAVA code.
But from http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html, it seems that at least two files needed to be configed for JNDI.
So could anyone tell me how to config JDNI in tomcat with standard methods. Thanks!
You configured JNDI data source for your application correctly, in the context.xml file for your application. The capability to configure JNDI data sources in the web.xml is preserved in Tomcat 7.0 for compatibility with older versions of Tomcat and, if I'm not mistaken, older versions of Java EE spec.