Messaging queue application - java

I´m told to develop a message queue like MSMQ for some apps, but it has to be written in Java so it's able to work on a Linux server. A co-worker tested openmq via glassfish but it's very slow, even having both apps on the same computer. It would delay each message for 1 second on a slow computer and .8 on a fast one, ive read his code and everything seems fine, delays seem to be caused by openmq glassfish functions(not his code).
Ive read a bunch of things that are related to the subject but i can´t find a library or something(ive seen zeromq,openmq and i dont know if they would suit because they seem to be oriented for managing and not providing the service). The only one i think suits my needs is MSMQ and i am not able to use it for the reasons i gave before.
In a couple of months it would be used to communicate at least 200 live applications
The main reason of this question is to try get a suggestion of what should i use or if someone had used openmq with glassfish and works cool and i should re ckeck that code to look for issues.

Have you tried ActiveMQ? Easy to set up and use and can handle a hell of lot of messages. We always use it with Spring's JMS templates for pain free messaging.
http://activemq.apache.org/

Related

Spring / Java, good method for remotely interacting with command line Java app on another server?

I am working on a Spring web application where I have a need to interact with a remotely based command-line java application to run a simple search query on this application and get back the results. I initially had integrated this into my Spring app but my app is, itself, needing a lot of memory (its an app that involves huge amounts of data) and I don't think they can coexist on one server anymore.
I am running everything on Amazon ec2 so the latency between the servers should be really low. I figure I could use a direct SSH connection but am not so sure if this is the best approach. I'd like to keep the command-line app I am interacting with as simple as possible (would rather not make it into a web-service if I don't have to). I'm still fairly new to Java so sorry if this sounds like a basic question.
You have several options other than a web service. Some of them are:
Protocol Buffers
JMS
Simple socket based client/server Java
Thrift
Assuming you have or can have spring on both ends -
Exposing service objects and consuming them from a different process becomes extremely trivial using Spring's remoting support. (RmiServiceExporter may be most appropriate and least trivial to setup in this case)
It really does away with all the boiler plate code and let's you focus on your business/service logic.
You can write a hello world service and consume it from another Java program in less than twenty minutes. Once you have this "infrastructure" setup, you are free to focus on your actual business logic.
(You absolutely don't have to know rmi to get this working though rmi working knowledge may help if you run into problems. But then, what is SO community for? ;))

Does anyone use ICEpush on production server under heavy load?

ICEpush is still in alpha version, so I am curious if it is appropriate to use in web application on tomcat or tc server with many clients. How many users can be serviced by this technology with small delay? I'm curious what is delay under 100, 1000 and 10000 clients.
What else Java library for reverse AJAX is worth to look at?
Purely for the fact that if it is software in 'Alpha' state, I would suggest against it and I would be surprised if anyone admitted using it in a production environment.
If you are just trying to find out what load it can handle, then you could easily find out by writing a test case to exercise the code and run it locally. This advice of course doesn't address network latency nor horizontal scalability.

Simple middleware server for control and monitoring

I need a server. A simple one, to control a couple of computers. There are already a couple of programs in the lab, that perform some calculation and monitor tasks. They are executed on these computers. So I need a server to control them - to see the real time data from these computers, I want these programs to upload the calculation data to the server, upload also some files, that come together with this data. So the server needs to have a simple database. I also want to alter some of the calculation parameters in the realtime.
Because, you see, I'm a little tired of opening each computer with the terminal, looking at the process, get the files from each of the computers by ftp, put these files in the corresponding folder on the file storage, writing the schedule, when each program should continue it's work.
Maybe there is some middleware, that I can use for such needs? It should be simple and extensible. i thought of writing such server from scratch, it is not a big problem, but I have a severe time shortage and many other things to do.
And it would be cool, that this server would be developer-friendly. So I could just take it's API and write whatever I need.
I'm using Java, so it would be great, that this server would also "understand" Java. ;-) RMI is cool, but because of the network architecture, I'd prefer to use plain TCP/IP for these needs. Becacuse there is always problem with setting up RMI, when there computers are in differed subnetworks.
Thank you very much for your support in advance! Please help me, otherwise my girlfriend would break up with me, because I don't see her often spending most of my time at the lab... ;-(
I am almost finishing a software like that (actually 3 softwares) the server, the clients and the admin that logs into the server and command the clients.
My problem was specific so I had to go for a custom build from scratch (TCP/IP sockets). Its not hard, just write down the protocol.
If RMI doenst help you, then you must consider making your own proto, and you could exten and add new features later.
Maybe Google Protocol Buffers would help you to build your proto
http://code.google.com/p/protobuf/
Hmm, the two that spring to mind are Jetty and Glassfish. Depends a lot on what you need to do and how you want to go about it. Both are java based.
This seems like a problem for which Bundle-Bee was created for.

Monitoring a Java web application - is JMX the right choice?

We have a Java web application and we'd like to set up some basic monitoring with a view to expanding this monitoring in future. Our plan is as follows:
(1) Collect generic information (e.g. memory and threads) about the virtual machine of the web container that application is running in.
(2) Monitor the "state" of the application. This is rather vague but at the least we'd like to see if the web application is still alive and can respond to requests.
(3) In the future we'd like to collect more information that is specific to our application. Again this is rather vague but you can assume that we might want to make certain statistics collected internally by the application available to the support staff.
Usually the web application will be deployed in a Tomcat 5.5 or 6 environment. A quick bit of searching on the web shows that JMX can be enabled for Tomcat and that JConsole can then be used to connect to the server. This gives us lots of basic information that solves point (1). Also, some information is available in the MBeans section for "Catalina" and drilling down on this I can at least, for example, see how many requests a particular servlet has received. This is not quite what we want for point (2) but at least gives us some information. There seems to be quite a lot of information there but it's rather difficult to interpret using JConsole. Perhaps there is a better tool for interpreting the MBeans exposed by Tomcat.
For point (3), it seems, at first glance that we could write our own MBeans and then make these available to something like JConsole. Personally, this would involve me learning about JMX which I'm quite happy to do but I have a concern. Having looked around I notice that most of the textbooks on the subject haven't been updated for several years and the open source tools seem to be languishing without recent updates. So my main question is a simple one. What are your opinions on JMX? Does it have a future or is it/has it been superseded by something else? Given we already have our web application but we're starting from scratch for the management console, should we choose JMX or is there something more appropriate with a better future ahead of it?
I ask this question with no personal axe to grind, I'm simply interested to hear your opinions and experiences. I'm sure there's no one correct answer but I think an informed discussion would be useful.
Thanks in advance,
Adam.
JMX is certainly a good solution here. I wouldn't worry about it languishing. Most enterprises I've worked for recently use (or have plans to use) JMX, and I'd have to hear a pretty convincing argument before choosing something else in the Java world. It's easy to write clients (monitoring solutions) for it and you can return complex data very easily indeed. Most 3rd party components support monitoring via JMX as well.
Note that you may want to consider integration with any existing management solutions (e.g. Nagios, BNC Patrol, HP Openview etc.) as well. They may not be so Java-aware, but rather prefer tests like simple HTTP connectivity for testing if a web-site is up (easy using Nagios), or integration using SNMP (which Openview talks natively).
If applicable to your situation (Java 6 update 10 JDK or later, plus on the same machine) then consider using jvisualvm instead as it can dig even deeper than JConsole.
You may find that the easiest way to do what you need is a plugin to jvisualvm knowing your application

How to test drive a networking application with custom protocol?

I'm currently developing two Java networking applications for school projects. One over TCP and the other one over UDP. In both I have to implement simple custom protocol.
Even though I'm trying pretty hard, I can't find a way how to correctly test this kind of apps, or better develop with test first development.
If I have a client and I want real test without stubbing everything out, I have to implement server with simulated behaviour, which in case of simple apps like these is almost the whole project. I understand, that when something big, than writing few lines of Perl script to test it could really help.
Right now I'm developing server and client simultaneously, so that I can at least test by hand, but this doesn't seem like a clean way to develop. The only thing that is helping is tunneling the connection through logger, so that I can see all the data that goes through (using TunneliJ plugin for IDEA).
What is the best way to TDD a networking application with custom protocol? Should I just stub everything and be fine with it?
Separate the protocol from the network layer. Testing the logic of the protocol will become easier once you can feed it your own data, without the need to go through the network stack. Even though you are not using Python, I'd suggest to look at the structure of the Twisted framework. It's a nice example of how to unit-test networking applications.
We wound up with the same problem a while ago. We decided it was simpler to put two developers on the task: one to write the server and one to write the client. We started working in the same office so that we could code, test, modify, repeat a little bit more easily.
All in all, I think it was the best solution for us. It gave us the ability to actually test the program in conditions there were not ideal. For instance, our Internet went out a couple of times and our program crashed, so we fixed it. It worked rather well for us, but if you are a sole developer, it may not be the solution for you.
Whatever you do, when writing a custom protocol, I would check out Wireshark for monitoring your network traffic to make sure all of the packets are correct.
In my app I have code such as this
m_socket.receive(packet);
doSomething(packet);
I mock up the receive and hence can exercise everything that doSomething() needs to do.
Where does this break down for you? Here you are truly unit testing that your code behaves correctly, you can also mock the socket send, and se expectations for what you think should be sent according to your protocol.
We are of course not actually testing that the other end of the protocol is happy. That's integration testing. I always hanker after getting to IT as soon as possible. It's when you interact with the "other end" that you find the interesting stuff.
You are in the luck position of being in control of both ends, in that position I would probably spend some time instrument to create suitable, controllable test harnesses.

Categories