As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We are using ActiveMQ 5.2 as our implementation of choice and we picked it a while ago. It performs well enough for our use right now. Since its been a while, I was wondering what other Java Message Service implementations are in use and why? Surely there are more than a few.
Before delving into JMS, consider AMQP as well - might be a new standard.
JMS providers I worked with (in varying degrees):
TIBCO EMS - very quick and robust, good API support, Java friendly, native C API exists. Best commercial choice I've used.
Websphere MQ (and its JMS implementation) - so, so. Pub/sub not exactly quick, many configurations options and choices are 'strange' and overly complex from the long history of that product. Just look at the amount of documentation...
Solace JMS - very high throughput (the JMS broker is built in hardware !), good choices of connecting protocols (MQTT, AMQP, XML over http as admin protocols)
Fiorano MQ - used to be agressive in marketing but lost a lot of market share, maturity concerns
Sonic MQ - solid product, also supports a C API
Active MQ - if you want to go with an open-source product (unexpensive support, great community, limited add-on products, limited enterprise features) this is probably your best choice. Works out of the box and is the backbone of several tools like Apache Camel, for example.
We rely on AMQ (5.1) via the Camel framework, and there haven't been any issues. AMQ 4 was a tad more fishy.
WebLogic JMS provider when using WebLogic. Works great.
TIBCO EMS. It's a commercial message service with Java/JMS, C, .net, and other bindings for it.
Sun's Open source OpenMQ (https://mq.dev.java.net/). You can get free and paid support for the same.
See this blog post about some comparison with ActiveMQ, etc -- http://alexismp.wordpress.com/2008/06/06/openmq-the-untold-story/.
I've heard that OpenMQ is more stable.
ActiveMQ is more flexible. as in, you can use it with more languages. There are probably more people on ActiveMQ's mailing list than OpenMQ.
In one of the recent projects I was in we used Sonic MQ. Good overall implementation with good bindings to .NET.
We had a little of scalability problems, but I have to admit that the scalability requirements were very strict: if I can recall correctly, something like 20,000 messes a second with no delays allowed between the 200 different clients (every client had to receive every message at the same time).
I've used JBossMQ, which comes with JBoss app server up to version 4, and which is solid but limited. JBoss Messaging was the replacement, comes with JBossAS 5, and is a huge improvement.
ActiveMQ I have a real dislike for. The developer(s) seem to have gone for performance and features to the detriment of stability, and it's phenomenally buggy. Given that it's the JMS fabric for Geronimo, I worry.
IBM WebSphere MQ 5 and 6
Active MQ 5.2.0
Also Check out Micro QueueManager at http://codingjunky.com/page5/page4/page4.html It is small, easy to install and use for smaller projects.
I have used ActiveMQ in production for a couple of years but I was never happy about its stability (specially with it clustered-enabled). Never looked back after switching to OpenMQ. You might want to look into RabbitMQ or ZeroMQ.
We are using SonicMQ, JBossMQ and the "micro broker" of Lotus Expeditor Integrator. We are using them for different purposes:
-JBossMQ is used internally and to communicate out of all our Java EE applications which run on JBoss.
-Lotus Expeditor is used in "remote sites" where we do only have limited resources and IT staff
-SonicMQ is our Messaging backbone, we use it for connecting central systems, but also to connect remote systems in approx. 1000 sites.
We are having good experiences with all of them, but our experience is also that with a more complex environment you have to do a more active administration of the Messaging system. This became especially true with SonicMQ at our site :-) . From a performance perspective we made the best experiences with SonicMQ especially in Queue based persistent messaging.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
For distributed computing using java stack, how can these frameworks or libs can fits in these categories.
documentation
adoption
easy to use and integrate with well widely used technologies like spring, orm and web frameworks
fault tolerant
security.
EJBs could replace all these new kids on the block for distributed computing, scalable and fault tolerant system architecture?
EJB 3 are designed to be easy to use and easy to integrate, there is a lot of documentation and they are the Java standard for distributed computing.
The EJB container provides the transaction management and the security based on standard specification. The container itself is provider by many companies with enterprise support or free use (IBM, JBoss, Oracle)
Your software can become fault tolerant without modification to the code is you follow the EJB specs, you can just put the servers in cluster (there are many cluster strategies) and can scale horizontally without effort is you use stateless session beans
The other frameworks/.technologies you mentioned are very valid but none can provide all these features
You're asking a too general question.
EJB is been used for many years now , and is widely documented, perhaps more than all the technologies you mentioned altogether, and more mature.
You can use JAAS for authorization and authentication (when it comes to security).
For example, I'm using the Krb5LoginModule at the oVirt open source project I'm one of its maintainers.
You can use secured HTTP when accessing the web container of the application server.
At oVirt we're using the JBoss application server, and you can use JBoss-cluster to achieve clustering. You can use infinispan to get a scalable shared data structure (data grid) across nodes.
We use Spring components at our application (for injection you can use CDI) - for LDAP queries, for working with the DB (we currently prefer Spring-JDBC over JPA due to performance reasons).
I've been using a stack of web application that looks up beans that are injected with EntityManager and perform CRUD operations using JPA (and hibernate as the JPA provider) for several years, prior to my current working place
I'm sure you can achieve all this using spring - for example - use a stack of spring-mvc + spring-orm.
I don't think any of the technologies will give you a distributed system in a "magical" way, and you will still have to invest time on development, design, testing of scalability, etc..
Our frontend is simple Jetty (might be replaced with Tomcat later on) server. Through servlets, we are providing a public HTTP API (more or less RESTful) to expose our product functionality.
In the backend, we have a Java process which does several kind of maintenance tasks. While the backend process usually does it own tasks when it's time, now and then, the frontend needs to wake-up the backend to execute a certain task in the background.
Which (N)IO library would be ideal for this task? I found Netty, Grizzly, kryonet and plain RMI. For now, I am inclined to say Netty, it seems simple to use and it is probably very reliable.
Does any of you have experience in this kind of setups? What would your choice be?
thanks!
Try to translate this document which answer to your question.
http://blog.xebia.fr/2011/11/09/java-nio-et-framework-web-haute-performance/
This society, as french famous Java EE experts, did a lot of poc of NIO servers in the context of a french challenge sponsored by VmWare (USI2011). It was about building a simple quizz app that can handle a load of 1 million connected users.
They won that challenge with great results.
Their implementation was Netty + Gemfire and they only replaced the CachedThreadPool by a MemoryAwareThreadPool.
Netty seems to offer great performances, and is well documented.
They also considered Deft, inspired by Tornado (python/facebook) but it's still a bit immature for them
Edit: here's the translated link provided in the comments
My preference is Netty. It's simple yet flexible. Very fast and the community around Netty is awesome.
The company I work for is currently evaluating CoralReactor. It is a commercial software but it has the easiest API I have ever seen for Java NIO. My personal opinion is that Netty makes things too complicated, especially if you want to go garbage-free and single-threaded, which are a requirement for many companies from the finance, advertisement and game industry.
I would decouple them by using JMS, just have some (set of) control queues your backend sits there listening on and you're done. No need to write a custom nio api here.
One sample provider is hornetq. This can be run as an in process jms broker as well, it uses Netty under the covers.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am currently using BlazeDS and covet the features of LCDS, but am never going to ask my customers to pay the $$$. Therefore I am considering starting to build these capabilities myself, using third party tools (dpHibernate?) or switching to GraniteDS.
Since, we are coming up on the two year anniversary of the last time this question was asked, I thought I'd ask it again.
Since that time, Spring-Flex has added Hibernate serialization support to BlazeDS to avoid lazy init exceptions. There is also a new BlazeDS configuration option to serialize read-only properties.
On the other hand, the Tide capability of GraniteDS seems to be maturing.
Plus the servlet 3.0 spec has been out for a while and maybe the additional support for NIO makes a difference for those who need push-type messaging.
So what's the latest?
As of today (February 29, 2012), the GraniteDS community is still very active, the product evolves with new features on a regular basis and you can get developer and production support if you run into technical issues (see here) or just want a kind of insurance for critical deployements.
GraniteDS' messaging is based on asynchronous servlets, it is mature (introduced late 2007), proven in demanding production environments and much more scalable than the BlazeDS messaging stack (based on classical servlets).
I've never used GraniteDS in production, but in my opinion it will always have more goodies than BlazeDS..unless some company will decide to make money from BlazeDS, like adding features, offering paid support & professional services. I think that Farata Systems is doing that but probably they are doing custom development for various clients..and not adding features into the mainline.
So probably from a productivity point of view GraniteDS can be a good choice - before choosing it I will double check if the community is quite active, if you receive answers to your technical question on their forums and most important if it's easy to understand the GraniteDS source code in case you run into technical difficulties.
Related to messaging I assume that if you wish a professional solution you will not choose niether BlazeDS not GraniteDS - there are dedicated solutions on the market. If not both should be ok (BlazeDS has a little bit more options from what I know).
By professional solutions I mean LCDS, Lightstreamer, Kaazing (and probably more). Some important features from LCDS which are not included BlazeDS: reliable messaging, message throttling, the ability to deploy the solution in architectures where DMZ is a must (http://www.lightstreamer.com/architecture.htm), the ability to connect also to non Flex clients (HTML).
Actually we (Farata Systems) continue improving our open source offering that works nicely BlazeDS. The latest version (4.2) of our tool called Clear Data Builder can generate CRUD applications in minutes based on Hibernate or POJOs. We hooked up Spring framework too - all BlazeDS client's requests are processed by Spring's DispatcherServlet.
Here's the Wiki Page http://cleartoolkit.com/dokuwiki/doku.php. There are screencasts and a workshop at the bottom of the main Wiki page that takes you step-by-step through the BlazeDS with Hibernate process and you'll also see how easy it is to connect the Spring Security module. We support data synchronization, hierarchical data collections, transactional updates, pagination, and more.
Apparently, we need to make more noise to make this nice (and free) product more popular :)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Which is the best Java memcached client, and why?
As the author of spymemcached, I'm a bit biased, but I'd say it's mine for the following reasons:
Designed from scratch to be non-blocking everywhere possible.
When you ask for data, issue a set, etc... there's one tiny concurrent queue insertion and you get a Future to block on results (with some convenience methods for common cases like get).
Optimized Aggressively
You can read more on my optimizations page, but I do whole-application optimization.
I still do pretty well in micro-benchmarks, but to compare fairly against the other client, you have to contrive unrealistic usage patterns (for example, waiting for the response on every set operation or building locks around gets to keep them from doing packet optimization).
Tested Obsessively
I maintain a pretty rigorous test suite with coverage reports on every release.
Bugs still slip in, but they're usually pretty minor, and the client just keeps getting better. :)
Well Documented
The examples page provides a quick introduction, but the javadoc goes into tremendous detail.
Provides High-level Abstractions
I've got a Map interface to the cache as well as a functional CAS abstraction. Both binary and text support an incr-with-default mechanism (provided by the binary protocol, but rather tricky in text).
Keeps up with the Specs
I do a lot of work on the server itself, so I keep up with protocol changes.
I did the first binary protocol server implementations (both a test server and in memcached itself), and this was the first production-ready client to support it, and does so first-class.
I've also got support for several hash algorithms and node distribution algorithms, all of which are well-tested for every build. You can do a stock ketama consistent hash, or a derivative using FNV-1 (or even java's native string hashing) if you want better performance.
I believe memcached java client is the best client.
Features
Binary protocol support. fastest way to access the key/value stored in memcached server.
UDP protocol support. You can set key with tcp protocol, and get with udp protocol. Acctually, some big corporations are doing like this.
Support customized serialization and deserialization.
Connection pool with NIO and direct buffer. Dynamically increase connections when out of use for the connection pool.
Performance
Refer to performance for a benchmark test of existing popular memcached java clients.
Deserializing while receiving the response
Performance tuning into each line of the source code.
If these are numbers still valid, then ... http://xmemcached.googlecode.com/svn/trunk/benchmark/benchmark.html
As of about a year ago, when I had to use a memcached java client, the spymemcached connector was described as an optimized API with more features. Since then there've been a number of new releases of the memcached client so it may be worth checking out.
FWIW the spy client has worked perfectly for me.
I have been using SpyMemcached and have to agree that it is the best one available out there, with lots of newer improvements.
There is the memcached client for Java and spymemcached. Not much experience with either though.
Please try xmemcached, it is also nio based and have some powerful features.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We're creating a web system using Java and Servlet technology (actually Wicket for the presentation layer) and we need our system to be available nearly always as our customers will be quite dependent on it.
This has lead us to look for a good book focusing on the subject or another resource which explains how to set up a more redundant and fail safe architecture for our system.
A non exclusive list of questions we have at the moment:
How do you have one domain name (like http://www.google.com) which are actually served by several servers with load balancing to distribute the users? Isn't there always a point which is weaker in such a solution(the two [as there can't be more] DNS servers for google.com in their case)?
It seems like a good idea to have several database servers for redundancy and load balancing. How is that set up?
If one of our web servers goes down we would like to have some kind of fail over and let users use one that is still up. Amongst other things the sessions have to be synchronized in some way. How is that set up?
Do we need some kind of synchronized transactions too?
Is Amazon Computer Cloud a good option for us? How do we set it up there? Are there any alternatives which are cost effective?
Do we need to run in a Java EE container like JBoss or Glassfish?
Regarding GlassFish, centralized administration through the admin GUI is a big help for environments with more than one appserver instance to manage. "Always available" is overloaded. It can be service availability with no session retention on failure, or it can mean data availability with session information backed up. Of course, GlassFish can do both. A couple of resources that may be of help regarding GlassFish and high availability:
Guide to GlassFish High Availability:
http://www.sun.com/offers/details/glassfish_HAref_config.html
Setting up a GlassFish Cluster in 10 minutes:
http://blogs.oracle.com/jclingan/entry/glassfish_clustering_in_under_10
John Clingan, GlassFish Group Product Manager
The Liferay wiki has a high availability guide entry outlining an architecture that could serve as a starting point.
This is probably a simplistic approach, but I've implemented a similar kind of load balancing and high availability solution recently.
My application had Tomcat as the web container and MySQL database. I've fronted Tomcat with the Apache Http Server and used the Apache mod_jk2 module as the interface to handle load balancing and failover.
Plenty of resources are available on the web starting from the Apache documentation. Here are a few:
http://tomcat.apache.org/connectors-doc/reference/workers.html
http://www.redhat.com/docs/manuals/rhaps/jonas-guide/s1-load-balancing.html
http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html
For MySQL, check out MySQL proxy for load balancing and failover. Its a good idea to have more than one database servers for load balancing and fail over. one set of databases can be for reads and the other set for writes. Depending upon the volume, you might want to allocate more/less servers for read/writes. Your database documentation might also help you in the configuration.
HTH.
A friend of mine says that Building Scalable Web Sites is the definitive book on the subject:
Scalable Internet Architectures by Theo Schlossnagle might also be of interest.
I just finished reading Architecting Enterprise Solutions: Patterns for High-Capability Internet-based Systems. Excellent introduction for me on scalability, availability, performance, security, and a whole lot of other aspects for Enterprise Systems