We are currently developing a small application which needs to communicate with a machine interface via a propriety tcp protocol.
For this low level communication stuff we used Netty to implement the necessary encoders and decoders. Since we also need some Java EE things like WebService, JPA etc we thought about integrating the netty server in an Java EE 6 application. Therefore we would use an ApplicationScoped managed CDI bean, where the bootstrapping is triggered in a PostConstruct method and the unregistering is done in the PreDestroy callback.
So the main question is:
Would this lead to problems, since as far as I know it is technically not allowed to start threads in a Java EE environment (I think Netty starts some threads here)?
If yes, what kind of problems? Since we don't need clustering, we would just use a standard Java EE 6 app server like GlassFish.
Most people will recommend against it, since improper termination and resource lock-ups can lead to catastrophic results. However, if you know what you're doing, there is no reason not to.
That said, based on what you need it for, I would recommend looking into Java Connector Architecture first. It already provides established contracts for connection, transaction, security, life-cycle, work, etc. management. So, you have a much better chance of writing a good implementation as well as transfer thread management to the container. See this and this to get you started.
Related
My app requires bidirectional continuous communication with a high volume of clients (which are java agents installed on user machines) in addition it includes a spring mvc webapp which provides a standard jsp UI to manage these agents.
I’ve only looked at the basics of java akka (no time to learn scala for this project). But it seems like a good choice to handle the high volume of client agents. I’ve looked at akka spring integration module and akka-spring-java examples and using akka on the spring side seems pretty straight forward.
I thought using akka remoting with the client agent side might also be a good idea, the agent which will likely be embedded in another app basically runs a thread needs watch various processes in the user’s jvm and communicates with services on server. Using location transparency would simplify the architecture conceptually and possibly be more efficient.
This article suggests this may not be the correct approach
Peer-to-Peer vs. Client-Server
The alternative to using remoting would to use camel websockets which seem to be associated with the akka spring integration module.
What would be the best direction to take in the context of my app given it's tech stack?
You probably don't want to use remoting for a server-clients situation. Remoting gives both sides the same rights and privileges. It was designed for clusters and peer-to-peer.
Take a look at Akka I/O. It gives you asynchronous actors on both sides, but fits the server-client use case better. You wouldn't have to worry about threads and processes.
Also remember, that even when using Akka with Java you need the Scala library as a dependency.
In our system we have a legacy standalone java application which we are trying to made available for new webapps we are developing all together running in a server (f.e. Tomcat)
In order to made requests to this app lighter we thought about made them directly to the same vm using jndi instead of developing a webservice interface.
I would like to start this application environment in some webapp context and make some API available to other webapps and invoke interfaces' methods.
I've not been able to bind this objects by JNDI in the Tomcat's read-only Context without adding the app in the Common lib, when I get more problems due to incompatibilities between dependencies versions. Maybe the best solution is to deploy these interfaces as EJBs so I'd use a Java EE Server instead of a servlet container. Or maybe I'd use some other framework such as Camel or something.
Thanks in advance and any suggestion will be helpful.
I would suggest to wrap your legacy java interfaces in REST. When you expose them as REST APIs, they will become available for any client, not only java. Also you don't need any Application Servers for that, all you need is a jar file for your REST reference implementation.
From performance perspective, well, I know theoretically JNDI should be faster, but in the real world the difference in performance becomes significant ONLY for very very performance intensive applications.
However, if performance is your primary requirement then wrap your legacy interfaces in EJBs.
Manual JNDI/RMI lookups are going to be the fastest, BUT and this is a rather big but, unless you are well experienced in network programming and multi threading, I would advise you to steer clear of that, and use a container. There are a lot of nitty gritty details that the container takes care of and you can concentrate on implementing your business logic.
I'm debating whether I should use java RMI or standard Java networking for an application i'm working on.
The app will be a networked system that has heartbeat sensors and failsafe-features. So it's a 3-tiered system, with at least a DB and java application.
So if my Database fails on one machine, I'd like the 2nd machine to "sense" this.
I'm a bit confused about Java RMI, whether it's worth it to learn it.
Or if I use standard Java networking , I can do the same as RMI? I mean, if I really know the Java networking well.
Thanks!
These days it is pretty easy to set up web services using SOAP or REST. With REST you can use XML or JSON messages without really having to know all about it. All these types of services can be accessed from .NET code or PHP or Javascript. (Well ... SOAP is sort of a pain except in .NET and Java. //personal opinion )
Spring can help you set up a service and a client interface to it is pretty easy. Fairly close to standard Annotations on bean classes and business methods define the interfaces and Spring does the heavy lifting. (I'm talking about Spring Web Services and not the Spring Remoting, though that would work as well. Spring Remoting isn't much better than RMI IMHO.)
You can also use Jersey (JAX-WS) or Jackson (Parse JSON) to do the remoting. Standard Annotations on bean classes and what-not build the interfaces. CXF will do JAX-WS and JAX-RS as well. Those are Java standards for building services and clients that communicate via remote messages.
Alternatively there are eclipse tools for generating both sides of the remote interface. All are tied to some framework (Axis-2 or CXS are some). Its sort of a code generation thing.
You might want to look into these a bit and see which one resonates with the way you look at things.
I know that I prefer all of these over using RMI. But I haven't used RMI directly in a long time.
RMI is higher level protocol compared to the bare TCP/IP support in Java via Socket class that you seem to refer to as "Java networking". If the only thing your system does is sending heartbeats and there are just few nodes you should choose RMI for simplicity reasons. As all of the participants are JVMs there is no need for any interop and extra libraries to support that and as the number of participants is limited there is no need to consider anything fancy.
I'm a long-time client-side (Swing) developer and I operated pretty much by myself in the same job for a long time. Working from home in a vacuum, I was pretty much completely isolated from the community. I recently took a position as a server-side Java guy for a startup, and I'm learning a ton of stuff but I'm the only Java person and am pretty much on my own again. Having never done server-side Java before, so much of this stuff is completely new and I feel like I have no idea what the normal best-practices are, or I don't have an intuitive feel for what tools to use for what jobs. I keep reading and reading various Internet sources (SO is awesome!) trying to bulk up my knowledge, but some things seem hard to search for because they don't have any obvious keywords. Hopefully some of you gurus here can point me in the right direction.
I'm in charge of implementing our backend REST service, which for now supports our website and an iPhone app. We're doing a social media site, eventually with many different clients. Currently the only clients of the service are our own website and our own iPhone app. I'm using Jersey, Spring, Tomcat, and RDS (Amazon's MySQL) on Amazon's EC2 platform. Our media storage is via S3. I've picked up all of these things pretty quickly and so far so good -- things are working fine with the website and the iPhone app. Cool.
Our next step is adding some long-running server-side processing. This processing is basically CPU-intensive stuff that doesn't involve any communication until it's done. I'm trying to figure out what the best way to handle this is. I'm thinking of using Amazon's SQS to queue up jobs in response to the REST events that should trigger them, but I can't figure out how I should handle the dequeuing and processing. I know I need some threads somewhere that take jobs off the SQS queue and process them, and then tell the REST service that the job is done. But where do these threads live?
In a plain "java -jar jobconsumer.jar" process on another EC2 instance that starts a small thread pool. Maybe use Spring to wire up this piece and start it running?
In a webapp deployed in a container like Tomcat on another EC2 instance? I don't really know what benefits I would get from this, but somehow running in a container like this seems more stable? Does this sort of container even really support long-running processing loops, or is it just good at responding to HTTP events?
Now that I write it out like that, I don't really see why I would want to use a container. It just seems like an over-complication. However, the Java community seems so centered on these types of containerized, "managed" environments that to not use a container seems somehow wrong. I feel like maybe I'm not understanding what some of the major benefits of these containers are? I mean, beyond the obvious benefits of the web-facing Servlet and JSP specs. Would any of the functionality of those specs help me out with something like this?
For a regular Java web app, you almost certainly want to be using one of the Servlet containers such as Tomcat - it takes care of accepting connections, parsing and serialising HTTP messages, JSPs, SSL, authentication, etc for you.
For a non-web app, the argument for using Tomcat (or similar) is weaker, but there are a few reasons to still consider it:
straightforward to add JSPs for querying and managing the app or add a web API in future
easy distribution of releases (one .war vs. an unholy mess of jars and config files)
hot deployment (although I've yet to see anyone using this for anything serious)
In terms of long-running processing loops, Servlet containers don't help you out beyond notifying your ServletContextListener when the app starts, so you can kick off any long-running tasks.
It's worth noting that if you're already using Spring, it's relatively easy to switch from a stand-alone app to a container using ContextLoaderListener, so it shouldn't be a problem if you decide later that you need the web stuff.
We recently faced a similar question, as we are hosting a large distributed service on EC2.
In short, we are very happy with Jetty 7 as a container. We use it for our user-facing-www, public-api, and internal-backend-api services. In some cases we use it for non-api services such as a workqueue, simply to expose a bit of status & health info for our monitoring.
The great thing about Jetty (any version) is that it can be configured in ~5 lines of code, with zero external config files etc. It's not a container specifically, but an http server that you can embed.
We use Guice for dependency injection, which also favors config-file-less implementations.
Long lived Java processes are nothing to worry about - you basically bring up your servers / threads / threadpools in your main method and don't call System.exit until you want to shutdown explicitly.
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.