I am using a embedded ActiveMQ in my application, the queue works excellent,
Now we want a way to be able to monitor this ActiveMQ, due to its embedded nature we cannot use the default web console provided by ActiveMQ.
I have had a look here http://activemq.apache.org/how-can-i-monitor-activemq.html , the provided options haven't helped much in my cause due to following reasons
Using JConsole is not a nice option because it uses up much of server resources and causes JVM to be slow.
StatisticsPlugin is a nice approach but doesn't provide a UI view, and gets reset on every server restart (This is what we will use if nothing else is found).
Have also had a look at similar question on SO ActiveMQ: how to programmatically monitor embedded broker , this is not what I want
Recently have heard about a tool called Hawtio , but this also seems to be useful when ActiveMq is running as standalone instance, (Please Correct If I am wrong on this, Any pointers will be definitely helpful)
So the help that I need is
Is Hawtio really useful for embedded instance ?
Are there any other tools availablle to achieve this goal?
Any help really appreciated.
I have used hawtio, its very useful tools for monitoring ActiveMQ. It used JMX internally which takes you java process running and monitor it.
Related
I have an application that runs within a tomcat (a handful of java servlets) on linux. Now I am tasked to monitor the ressources (such as CPU, memory usage, etc.) within this tomcat (not the single servlets).
I am not a programmer (so I cannot change code) and I am not allowed to change anything within the code. I am also not very familiar with Java (so my apologies if I throw a few things together).
The only thing I can do is start tomcat with java-parameters that activate jmx. So I can remotly check tomcat and the application/servlets running within from remote using JMX.
Question:
What tools (or possibilities) are available to find out what kind of monitoring/ressource information the tomcat (or application with the mbeans) is offering?
I am thinking along the lines of a snmpwalk which would allow me to discover the information provided by snmp. However, I have no idea how to do this with java and jmx (found tons of articles on the internet on how to program it, but that is out of the question).
Thank you very much for your help
You are better off looking at an APM tool to fit this use case. I work for AppDynamics and we do just this. The other common tools are Dynatrace and New Relic. These tools will attach to a Java application at runtime and provide deep monitoring, visibility, transaction tracing, and troubleshooting capabilities. AppDynamics also automatically baselines all of the metrics and alerts you when things start having issues.
I've been researching Apache's commons-daemon and it seems pretty cool: basically its an API as well as a library that helps register your JAR with the underlying OS so that it can be started and stopped like a daemon service. Additionally, it intercepts OS signals that would normally kill your app and instead gives you a chance to shutdown politely.
So it's got me wondering, if given the choice between deploying your business logic inside EJBs and wrapping them in a container like OGS or JBoss, why not just create a daemon JAR that listens on a port and responds to client requests?
Is it just the benefit of all the features/services that an app container provides out of the box (security, logging, etc.), or are there times when it would be favorable to choose a daemon over an app container/EJB solution?
Basically, what I'm asking if: when is it more appropriate to use an app container/EJB solution, and when is it more appropriate to use commons-daemon to help build a system-level service (in Java)?
Disclaimer: just interested in these two choices, I am aware that other solutions exist (web containers, ESBs, OSGi, etc.). But for the purposes of this question I am only interested in hearing the reasoning between app container or daemon solutions. Thanks in advance!
Why don't you look at it like System level (daemon) vs Application level (in container)?
This will give more or less clear distinction (especially if worked with Linux some time).
For Daemon:
has its own life cycle (you can start and stop it separately);
different privileges (could be run under different user);
use case is something like CRON, MailServer, synchronization and any system-level service.
For Container:
managed app (by some privileged user via Container console);
plenty of out-of-the-box features (which you'd already mentioned);
use case some general case business application.
Well the simple answer is yes, the app server (Glassfish or JBoss) give you plenty of nice things that you would have to implement or setup yourself in a plain Java SE app.
However it is not so black and white, and you can get a lot of the application server goodness with very little effort, I am in the process of writing a blog series on exactly this topic.
My reason for not using an app server, was that we had a project for a widely distributed software product, and we wanted to avoid having to patch and maintain thousands of application server instances!
However if your app will be running in one place, there is little reason to go Java SE.
I am considering using Java 6's embedded HTTP server for some sort of IPC with a Java daemon. It works pretty well and it's nice that's already bundled with all Java 6 installations. No need of additional libraries.
However, I would like to know if someone has tried this with production environments with heavy load. Does it perform well? Should I be looking for something more robust such as Tomcat or Jetty?
Well, as much as it saddens me to say bad things about Java, I'd really not recommend it for production use, or any kind of heavy use scenario. Even though it works well for small stuff like unit/integration tests, it has big memory issues when it is used intensivelly, especially when you use it for a big number of connections at once. I've had similar issues to the ones described here:
http://neopatel.blogspot.com/2010/05/java-comsunnethttpserverhttpserver.html
And Jetty is not that good for heavy production usage for pretty much the same reason. I'd go with Tomcat if I were you.
As an alternative, I believe you could consider Java Messaging Service as an alternative to Inter Process Communications and just have a JMS server running (like Active MQ)
If you want something that ships with Java have a look at RMI or RMI/IIOP.
I need to scale calls into Tomcat and it's been suggested to launch threads internally. Has anyone needed to do this and, if so, what solutions did they come up with?
Creating your own threads inside an application server is generally discouraged because the server should manage threads for better scalability. You can also run into problems if the container makes assumptions about what's available in a thread context, such as security information (e.g., authenticated Subject). That typically happens if you spawn a thread and then use a server resource from that thread which is unknown to the container.
Check to see if there is a way to get container managed threads from Tomcat. WebLogic and WebSphere support the commonj.WorkManager, which allows you to schedule work on container managed threads. Spring can also use commonj, but I'm not sure if that support is available on Tomcat.
You shouldn't really launch threads from within your webapp unless you have a very specific need to do so. Without more details on your problem it is hard to tell if this is the right approach to solve your problem.
You might want to take a look at Quartz, which "is a full-featured, open source job scheduling system that can be integrated with, or used along side virtually any J2EE or J2SE application".
Your question is a bit vague. Tomcat itself already uses a thread pool to service HTTP requests. You can increase the number of threads through Tomcat configuration - look to the Tomcat wiki for info on this.
If you mean that in your code you want to launch threads, then I advise perusing the java.util.concurrent API introduced in Java 5. Also read "Java Concurrency in Practice", which is the text on this subject.
What is the problem you are trying to solve with threads?
If have long running tasks you should use JMS + a full Java EE container.
If you trying to handle excess load you could consider two tomcat instances, however, if you are using http sessions you will need to investigate session replication.
If you are forced to use Tomcat consider using the Executors framework in java.util.concurrency.
as others asked, you should give more details as to what you're trying to accomplish.
Otherwise, tomcat uses thread pools. increase the number of threads in the pool. Use a newer version of tomcat -- 6.x. Use Java 6.0_10. If needed, tune the application using a profiler and fiddle with the JVM settings, if required.
The J2EE abstraction for managed multithreading is JCA. In particular, take look at the WorkManager and Work classes. See also this arcicle. Spring also provides JCA-backed work manager abstraction.
Does anyone know if it is possible to restart a J2EE application (from the application)? If so, how?
I would like to be able to do it in an app-server-agnostic way, if it is possible.
The application will be run on many different app servers-- basically whatever the client prefers.
If it isn't possible to do this in an app-server-agnostic manner, then it probably isn't really worth doing for my purposes. I can always just display a message informing the user that they will need to restart the app manually.
I would suggest that you're unlikely to find an appserver agnostic way. And while I don't pretend to know your requirements, I might question a design that requires the application to restart itself, other than an installer that is deploying a new version. Finally, I would suggest that for any nontrivial purpose "any" appserver will not work. You should have a list of supported app servers and versions, documented in your release notes, so you can test on all of those and dont have to worry about supporting clients on a non-conforming server/version. From experience, there are always subtle differences between, for example, Apache Tomcat and BEA WebLogic, and these differences are often undocument and hard to determine until you run into them.
Most application servers provide a JMX interface, so you could invoke that.
I'd suggest using servicewrapper to manage the application server, and then use its api methods for requesting a restart of the service. There would be some configuration involved and its hard to know if this would work in your particuar environment, but thats the only solution that I know of which is even reasonably cross-server compatible.