Is there any real difference to the performance when you use Netty and if you don't use it in an application with tens of thousand of connections?
Not really, a good reason to use Netty is to improve the reliability of the connections and leave you to code what the connection does rather than worry about the details of everything which can go wrong. (Often only comes by finding out the hard way)
Netty may help you scale over 1K connections. However if you don't need so many connections you might find that simple code performs best.
Not really, as Peter noted.
However, I've found that Netty also offers a very nice API for building a server. Although there is a bit of a learning curve to the API, it's well made and creating a new server can be trivial. It's also quite efficient code-wise, so you would have very little code, if you have a simple protocol and implementation.
This is ONLY if you are building a server for something other than HTTP. If you are talking about an HTTP web application, go with the tried an true. Apache for straight HTML pages, Tomcat if you need Servlets.
HTTP web app is not necessarily go to apache httpd and tomcat:
Check this and this to see how superior nginx is compare to apache httpd
Click here to see How Play!framework (based on Netty) outperforms those based on Tomcat/Servlet
Netty is very fast, especially with many connections.
In my experience:
It's more scalable than the standard Java IO. In particular, the old synchronous Java IO packages require you to tie up one thread per connection. This can become problematic with tens of thousands of connections!
It's approximately the same speed as what you would get if you wrote custom networking code using Java NIO, but it's a lot simpler to just use Netty directly rather than go down this route.
Twitter used Netty in its Search System:
Ref: Twitter Search is Now 3x Faster
Actually using Tomcat NIO, you can get up to 16,000 concurrent connections; mind you thats CONCURRENT connections on one machine. This was tested against as a comparison vs Jetty which topped out at 4000 when they kept giving them more and more memory. (http://www.javalobby.org/java/forums/t92965.html)
And using a 'convention over config' framework like Grails with REST functionmality built in (or simple plugins like RestRPC), you can easily build API's, webhooks, etc in seconds.
I also have more control using Spring Security plugin as to who can access what api call via what IP or what role if I want.
Netty has limitations that the plethora of Grails plugins can expand far beyond using Tomcat NIO.
Related
I am planning to do a simple Remote Procedure Call (RPM) over the web and I am currently using WebSockets. I was wondering if Jini is better than WebSockets or if there is a newer API or framework for Java to do RPC.
WebSockets and Jini are the main ones of note, both have their pluses and minuses. I'd say WebSockets is great just for the sheer amount of examples and documentation lying about. Jini is a lot different than WebSockets - so if anything the overheard of learning how to use it may not be worth it; that is up to you to evaluate, I spose.
I wouldn't use WebSockets directly because older browsers and/or corporate firewalls may have issues with it. SocksJS
is a respected wrapper that will gracefully degrade to another transport mechanism if required while still allowing you to work with a WebSockets type of API.
The client side is generally written in JavaScript but they have a number of servers written including two in Java: Vert.x and Netty. It looks like the Vert.x implementation is a little more mature at this point in time.
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'm writing my first client/server android app, and need an advice regarding server architecture.
My app is not a browser based app, but a stand alone client.
On server side i use hibernate/JPA and would like to transfer objects to client side.
What should I use:
Implement MVC- meaning writing servlets that will handle http requests (via Apache for example).
Write my own stand alone primitive server, meaning using simple sockets connection(in java for example), and handle each client in a different thread.
if you can think on a better way, you're more than welcome to share..
HTTP is definitly your choice since many carrier will block other protocols, since application servers/containers will take care of handling the multiple connexions and since it will also be a base if you decide to have a browser-based version some day ...
REST + JSON based webservices are well suited for android, given its simplicity, lightness and readability, but SOAP is also available via kSOAP2.
In my opinion. writing your own socket server is only warranted if you are required to implement your own wire protocol.
Most likely it's not a case for you.
So stick with http since it's widely adopted and has excellent client support in Android.
As for specific server side technology, you need to enumerate your requirements and do some research.
Don't start with Apache if plan to use Java, though. Pick Tomcat or Jetty. For framework, my personal choice would be Spring MVC.
Well, I have some experience in this very sphere and we used apache + php "covered" with nginx. I believe it's better to use standard approach, such Apache + PHP or Tomcat + servlets, cause it's easy to scale if needed and support... Of course it interesting to write your own application, but you might have some troubles with when traffic grows or server is down etc.
I'll need to develop a Java service that is simple because:
It only communicates via a TCP socket, no HTTP.
It runs on a dedicated server (there are no other services except the basic SSH and such)
Should I make this a standalone service (maybe in something like Java Service Wrapper) or make it run in a container like Tomcat? What are the benefits and detriments of both?
If you aren't working with HTTP, you will have to build your own connectors for Tomcat. When I've written these types of applications, I've just written them as standard Java applications. On Windows machines, I use a service wrapper that allows them to be part of the Windows startup process. On non-windows machines, you just need to add a start up script.
Using a container (regardless which) buys you that all the details about starting, stopping, scaling, logging etc, which you have to do yourself otherwise, and it is always harder than you think (at least when you reach production).
Especially the scalability is something you need to consider already now. Later it will be much harder to change your mind.
So, if somebody already wrote most of what you need, then use that.
Tomcat doesn't sound like a good choice for me in your situation. AFAIK it's primarily made for Servlets and JSPs, and you have neither. You also don't need to deploy multiple applications on your app. server etc. (so no benefit from ".war").
If you need dependency injection, connection pooling, logging, network programming framework etc., there are a lot of good solutions out there and they don't need tomcat.
For example, in my case I went for a standalone app. that used Spring, Hibernate, Netty, Apache Commons DBCP, Log4j etc. These can be easily setup, and this way you have a lot more freedom.
Should you need a HTTP server, maybe embedding Jetty is another option. With this option too, you have more control over the app. and this can potentially simplify your implementation compared to using a tomcat container.
Tomcat doesn't really buy you much if you don't use HTTP.
However, I was forced to move a non-HTTP server to Tomcat for following reasons,
We need some simple web pages to display the status/stats of the server so I need a web server. Java 6 comes with a simple HTTP server but Tomcat is more robust.
Our operation tools are geared to run Tomcat only and standalone app just falls off radar in their monitoring system.
We use DBCP for database pooling and everyone seems more comfortable to use it under Tomcat.
The memory foot-print of Tomcat (a few MBs) is not an issue for us so we haven't seen any performance change since moved to Tomcat.
A container can save you from reinventing the wheel in terms of startup, monitoring, logging, configuration, deployment, etc. Also it makes your service more understandable to non-developers.
I wouldn't necessarily go for tomcat, check out glassfish and germonimo as they are more modular, and you can have just the bits the need, and exclude the http server.
We faced a similar decision a while back, and some parts of the system ended up being jsw based, and the others as .war files. The .war option is simpler (well more standard for sure) to build and configure.
I want to implement a Java HTTP server locally, I mean the server computer would be in my control. I'm expecting not more than 20 clients to send requests to it.
I was wondering how to go about it:
Should I use a J2EE servlet container, like Apache Tomcat?
Could I use J2SE classes and just build it using them?
Are there any existing alternatives?
What does your experience suggest?
There's a simple HTTP server embedded in the Sun 1.6 JRE. It's not JavaEE or servlet-compliant, it's very lightweight, but it might be good enough for your requirements. No need to download any 3rd party stuff if this is all you need.
The javadocs, rather bizarrely, are out on their own, here.
Embed Jetty in your application. Aside from performing quite well, it is delightfully easy to use and configure
You've got many options, not the least of which are Jetty, Grizzly, and TTiny.
I would strongly urge against writing your own web server, unless you've got time to kill and want to spend it writing things that are already available to you for free.
Seriously, reuse an existing solution. Why the hell are you even thinking rolling your own?
Now, 1. I don't understand your question as being about embedding a container. 2. You mentioned long polling several time. So I'd suggest to use GlassFish v3 / Grizzly (because there are many samples, e.g. have a look at the Dead Simple Comet Example on Glassfish v3 / Grizzly).
If you don't want to rely on the way a container implemented Comet support, use atmosphere and any of the container mentioned on the web site:
Atmosphere is a POJO based framework using Inversion of Control (IoC) to bring push/Comet to the masses! Finally a framework which can run on any Java based Web Server, including Google App Engine, Tomcat, Jetty, GlassFish, Weblogic, Grizzly, JBossWeb and JBoss, Resin, etc. without having to wait for Servlet 3.0 Async support or without the needs to learn how Comet support has been differently implemented by all those Containers.
If this is not a concern, just stick with the suggested option (GlassFish v3 / Grizzly).
For a concrete and recent comparison between Comet server implementation, checkout this awesome Comet Maturity comparison grid view (source: Comet Gazing: Maturity). It might help you to make your final choice... or not :)
I guess the biggest question is: why do you want to build this?
If it is for the purpose of personal development, I'd stick to whatever standard libraries come with your JDK and build it on top of that.
If on the other hand you have a particular application that needs a dedicated HTTP server I would try to take one of the open source servlet containers, like Jetty or Tomcat and build on those.
Perhaps look at the list of 26 open source web servers at http://java-source.net/open-source/web-servers.
http://java.sun.com/developer/technicalArticles/Networking/Webserver/WebServercode.html is actual code in a single file implementing a multi threaded webserver. For your requirements, such as they are, this should suffice.
http://java.sun.com/developer/technicalArticles/Networking/Webserver/ is an analysis of the code.
If you will write your own HttpServer you will have to implement all the methods of the HTTP protocol. Tomcat can be easily used locally.
Is it for practice, fun, to implement special requirements or why don't you just embed an existing solution?
Do you really want to build a HTTP server that deals with the protocol directly, or do you just want to write web apps? If all you care about is writing the web apps, then just use Tomcat, or Jetty, or Glassfish, or another server -- it will save you a ton of work.
If you really are interested in writing your own server from scratch, then the best way would be to just use Java SE, and not use any existing server technology.
Ad your 3) option: Try JBoss Netty.
http://fisheye.jboss.org/browse/Netty/trunk/src/main/java/org/jboss/netty/example/http/websocket