I dont want to compare apple with orange, this was already done, for example, in:
http://blog.shinetech.com/2011/06/10/nodejs-from-the-enterprise-java-perspective/
http://adamgent.com/post/10440924094/does-java-have-an-answer-to-node-js
Actually, I do not have a concurrency problem with JBoss AS 7, but if I had on, what should I do?
Should I:
SOLUTION I:
horizontal/vertical scale
use HTTPD in front of JBoss AS
use #Asynchrounous or Messaging Systems (such as AKKA) for ALL tasks
...
SOLUTION II:
use node.js (rhino.js)
Can anyone provide practical experiences where JBoss AS 7 failed to scale? I have never had such experiences for myself.
For example, imagine a web application with 10.000.000 concurrent request *on a single machine* (with a single jboss-as-instance or a single node.js-instance).
What would be the result?
Would node.js works normally while JBoss AS 7 crash?
In general, Java EE is primarily targetted at high-scale application and most of the design decisions comply to that, from persistence over session and cache replication to view layers.
While Node.js may be good for certain tasks, Java EE 6 is (IMO) good if you want to use it for whole stack.
There's more comming regarding scalability, like JSR-352. So Java EE is yet to improve.
Regarding your question - "while JBoss AS 7 crash" - it doesn't generally crash. Usually it's faulty or poorly written application what crashes. Node.js gives certain API. Java EE gives a multitude of APIs, which sometimes are misused or conceptually misunderstood, which results in problems like OutOfMemoryException. With a properly designed application, there should be no problem with horizontal scaling.
There are few proven examples of node.js supporting a large and popular application as of yet. Like any new technology of this type, it will get tested and if it scales will garner support. Nobody can truly answer your question from a technical standpoint.
Related
We have an oracle forms application, and one of the many thoughts (considered converting to non-oracle-form technology) was to use JHeadStart (oracle product) that converts the oracle forms to ADF application. But we would like to not use ADF, so is there any way that we can remove the dependency on ADF?
If anyone feels this is not the question to ask, instead of giving me -ve marks please comment me and I will remove this question.
Thanks.
As always, it depends on what you want to achieve. I don't know JHeadStart, but to me, it sounds like a tool converting a legacy application to a framework that might be considered legacy soon. There are a few supporters of ADF, so I believe it's a good thing if you're ready to live with the compromises a full-stack framework brings. But in general, ADF is not popular among JSF developers (mostly because of those compromises, which often turn out to be too restrictive). Even more generally speaking, JSF is not popular among UI developers. That, in turn, is a bit unfair, but I observe a huge movement to pure JavaScript UI frameworks.
This indicates that using a tool like JHeadStart isn't the most future-proof approach. It's (probably) good to survive the next month, but in the long run, it'll probably backfire.
Let's have a look at the question from another angle. Why do you want to get rid of Oracle forms? Most likely, it's because of recruiting problems, but it might also have something to do with architecture. Oracle Forms supports a programming style integrating the database layer tightly with the UI layer. That's a very efficient way to write small applications, but it scales badly if your application grows.
So I'd recommend spending some extra money and time to re-implement your application from scratch. Automated tools tend to generate code that's hard to maintain. Re-designing your application from scratch gives you the opportunity to build an application that lasts a decade.
Oh, and I don't think it's possible to use JHeadStart without introducing ADF. Simply because JHeadStart has been designed with ADF in mind.
We are creating a web app where we need to have concurrency for a few business cases. This application would be deployed in a tomcat container. I know that creating user defined threads in the web container is a bad idea and am trying to explore options that i have.
Have my multi-threaded library used as a JCA component. We are averse to using this approach because of the learning curve that might be involved.
I know that there's WorkManager API's available but i guess thats not implemented by tomcat so this option goes out.
I did some research and found out that CommonJ library is recommended for Tomcat. Has anyone used it?
Also, I see that there are ManagedExecutorService available but I am not sure how to use it and is it different from WorkManager API's (and the commonJ library)?
Any help on this appreciated. By the way, using JMS is out of question because of deployment environment. I am inclining towards points 3 and 4 but i do not have much knowledge on it. Could someone guide pls.
Since you're using Tomcat, don't worry about it and do whatever you want. The Servlet section of Java EE makes no mention of threads etc. That's mostly under the EJB section.
Tomcat itself doesn't do much at all in terms of worrying about managing threads, it's a pretty non-invasive container.
Its best to tie your threads to a ServletContextListener so that you can pay attention to the application lifecycle, and shutdown your stuff when you app shuts down, but beyond that, don't overly concern yourself about it and use whatever you're happy with.
Addenda -
The simple truth is Tomcat does not care, and it's not that sophisticated. Tomcat has a thread pool for each of the HTTP listeners and that's about the end of its level of management. Tomcat is not going to take threads from a quiet HTTP listener and dedicate them to a busy one, for example. If Tomcat was truly interested in how you create threads, it would prevent you from doing so -- and it doesn't.
That means that thread management outside of the HTTP context falls squarely on your shoulders as an implementor. Java EE exposes these kinds of facilities, and the interfaces make great reads. But the simple truth is that the theoretical capabilities espoused by the Java EE API docs, and the reality of modern implementations is far different, particularly on low end systems such as Tomcat.
Not to disparage Tomcat. Tomcat is a great piece of software. But for most of its use cases, the extra management capability simply is not necessary.
Setting up your own thread pool (using the JDK provided facilities) and working with your own thread lifecycle model will likely see you successfully through whatever project you're working on. It's really not a big deal.
There are a couple of options. Regardless container restrictions that might or might not be in place, spawning individual threads on demand is nearly always a bad idea. It's not that this wouldn't work in a Servlet environment, but the number of threads you can potentially create might get completely out of hand.
The simplest solution to go with is a plain old Java SE thread pool via a normal executer service. Start the pool in a Servlet listener and provide access to it via some static variable. Not overly pretty, but it gets the job done. Depending on your exact use case this might actually be the best solution (if your use case is pretty low-level).
Another option is to add OpenEJB to your war, and then take advantage of the #Asynchronous annotation.
Yet another option, is to realize that one typically uses Tomcat if the business requirements are extremely simple or low-level. That's pretty much the entire point of using something as bare bone a Tomcat. As soon as you find yourself in need of adding (tons of) libraries, you might have outgrown Tomcat and might be better of using a server that already has the functionality you need (in this case asynchronous execution). Examples are TomEE, GlassFish, Resin, JBoss AS, Geronimo, etc.
Every Servlet -Java EE base component for HTTP request processing- in your Web Application is a Singleton, and each request runs in its own independent thread so there is no need to start/stop user generated threads on your own. Your Web Container -in this case Tomcat- manages all that stuff.
Besides that, you need to have in mind some considerations for multi-threaded processing in your code. For example, since Servlets are singletons and many threads are spawned for this class is a bad idea to have instance attributes in this components.
I have used CommonJ many times and it works very well. It can be initialized and destroyed from a ServletContextListener.
As stated in the title, I would like to know if it's safe to develop a website using one of the actuals "omg" platforms that are Node.js and Ringo.js at their actual version.
Also, I would like to know if they support cookies/sessions and how do they deals with multi-fields post (fieldname[] in PHP).
Thank you
--Edit--
Thanks for all the links guys.
What can you tell me about Ringojs ?
Since I haven't figured which platform to start playing with. I must admit that the fact it can use Java seamlessly really impress me. The only available XSLT 2.0 library is in Java. I could use it as a templating system.
Is there anyone who had the chance to play with Ringojs?
From my experience using both, Ringo is more stable and "safer" for production use but you can comfortably deploy both. In addition to the ability to wrap existing Java libraries that you mention, you also get the benefit of being able to run it in an existing webapp container which manages the lifecycle of the application for you and ensures its availability.
That being said, it doesn't have to be an either or decision. By using my common-node package and assuming you don't use any Java libraries, it's perfectly feasible to maintain a project that runs on both without any changes to the code.
I've also included benchmarks that test the performance of Node.js vs. RingoJS the results of which you can find in the common-node/README.md. To summarize: RingoJS has slightly lower throughput than Node.js, but much lower variance in response times while using six times the RAM with default Java settings. The latter can be tweaked and brought down to as little as twice the memory usage of Node with e.g. my ringo-sunserver but at the expense of decreased performance.
Node.js is stable, so yes it's safe to use. Node.js is capable of handling cookies, sessions, and multiple fields but are not as easy to manage. Web frameworks solve this problem.
I recommend Express.js, it's an open-source web framework for Node.js which handles all of this and more.
You can download it here:
https://github.com/visionmedia/express
I hope this helped!
Examples of some of the bigger sites running Node.js
https://www.learnboost.com/
http://ge.tt/
https://gomockingbird.com/
https://secured.milewise.com/
http://voxer.com/
https://www.yammer.com/
http://cloud9ide.com/
http://beta.etherpad.org/
http://loggly.com/
http://wordsquared.com/
Yes. It is. https://github.com/joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node and https://github.com/joyent/node/wiki/modules
cookies/sessions/forms etc http://expressjs.com/ makes it easier
Ringojs is a framework developed by Hannes Wallnöver and uses rhino as it's scripting framework. There are webframeworks, templating-engines, orm-packages and many many more things already available. Have a look at the tutorial featuring a good subset of packages you may use for a simple web-application. It's not too long and straightforward.
Even thought some of those packages used within the tutorial (e.g. ringo-sqlstore]) are marked as 0.8 and come with the hint "consider this being beta" they are already very stable and bugs - if you find one - get fixed or commented on very fast.
And the power of uncountable java-libraries out there is at your fingertips - so if you already have java-knowledge this knowledge isn't wasted. Rhino - the scripting-engine - even enables you to implement interfaces and extend classes. It is possible a little more advanced but i've done it and i know of packages taking advantage of such features (like ringo-ftpserver which is a wrapper around Apache FtpServer written in java)
Another pro for me is - because ringojs is based on java - it works fairly well with multithreading with ringo/worker for example.
While multithreading is faster in some cases, sometimes we just want to spawn multiple worker processes to do work. This has the benefits of not crashing the main app if one of the worker crashes, and that the user doesn't need to worry a lot about inter-locking stuffs.
COM+'s Application Pooling seems like a good way to achieve this on Windows. The downside is that we need to write a COM+ wrapper for the worker process.
However, when I search for Application Pooling on Google, it seems like most of its usages are related to IIS. Don't other applications (such as scientific/graphics) find it useful to spawn multiple worker processes?
So there are several questions:
Why isn't COM+ more popular in areas other than IIS? If I write a non-IIS application and want to use process management on Windows, should I go with COM+ or are there better alternatives out there?
What would be the cross platform way to do it? Are there libraries out there that give me a "process pool" (worker processes will intelligently pick up work, can be managed, etc.)
I can't offer any answers to the COM aspect of your question, but it's worth noting there's another world (besides HPC MPI) where multi-processing (rather than the more common multi-threading approach) is apparently alive, well and thriving: Python.
Why ? Python's GIL ("global interpreter lock") cripples most attempts to multithread python code so badly that multiprocessing is the generally recommended approach to parallelising Python on SMP. The standard library includes process pools; there are various other options too.
Python certainly ought to satisfy any multi-platform requirement!
You might want to investigate how the apache web server manages process pools. From version 2.0 it runs natively on windows and one of the multi-processing models it supports are process pools. A part of apache is also APR (apache portable runtime), which handles platform-specific issues.
No one can answer why something is not popular because may be no body is looking for what you are looking for. After .NET came in picture, people shifted from COM to Managed Environment, before .NET, COM and ATL and relative other technologies were quite painful to implement and they would crash and were also quite difficult to debug.
That is the reason, managed environment came in existence.
However, .NET 4 onwards, parallel libraries give much more power to user for parallel programming and also you can spawn and control other proceeses.
For multiplatform, you can look for zvrba's answer.
Yes, other applications--especially science applications--find it useful to spawn multiple processes. Since few super-computers run Microsoft Windows, scientists generally avoid using anything that ties them to a Microsoft platform. Nothing related to COM will help scientists leverage their enormous existing code base written in Fortran.
People who choose to run IIS have generally already drunk the Microsoft Koolaid, so they have fewer inhibitions to tying themselves to Microsoft's proprietary platforms, which is why COM-specific terminology will get lots of hits related to IIS.
One of the open standards for doing what you want is the Message Passing Interface. Several implementations exist and some of them run on supercomputers using Fortran. Some of them run on cheaper computers using sexier languages.
See http://en.wikipedia.org/wiki/Message_Passing_Interface
There hasn't been a mob rushing through the doors of COM application pooling primarily because of two factors:
COM is a pain in the ass to deal with compared to just about anything else
Threading can be a headache, but it's a lot easier and more convenient to manage than inter-process communication
COM application pooling was essentially created for IIS. It has one very specific benefit over normal multithreading: the multiple processes are fully isolated from each other. This is important for data security and for app stability when dealing with third party plugins of questionable stability.
Scientific computing generally doesn't need strong data security isolation between operations, and I would venture to guess that scientific computing doesn't rely much on third party plugins of questionable stability. When doing big math operations, you're either using a sexy numerics library that had better be rock solid to be taken seriously, or you're using your own code, in which case crashes should be fixed and repeat offenders should be spanked.
Oh, and all crashes except stack overflow can be trapped and dealt with within a multithreaded app, especially if it's your own code.
In short, COM app pooling is overkill for just about anything other than IIS.
Google's webbrowser chrome is a multi-process architecture software. It is open source, so you can check out its code and see how to manage processes.
I'm in the beginning phases of a Blackberry/J2ME project -- and along with other limitations that come with this wonderful platform, the lack of support for reflection and 1.3 language level mean that the vast majority of existing IoC containers are unusable. (Google has Guice for Android with no AOP, but even that requires support for annotations).
So the space of IoC containers on J2ME is pretty limited. The one framework that has caught my attention is called Signal Framework, and it looks pretty promising. It tries to stay conceptually close to Spring Framework's IoC, implementing a small subset of its functionality, and does so without relying on bytecode-modification or causing runtime xml parsing. Instead, it processes configuration XMLs at build-time to generate java code which implements this IoC functionality.
Generally speaking, code generation at build time seems like a very wise approach for mobile applications -- and if my app has to do less XML parsing on user's device, that's great too!
So, what have your experiences been with implementing IoC on J2ME/CLDC, and how were you able to extinguish that bitter taste in your mouth?
We used Spring ME at TomTom. It worked out pretty well.
In J2ME you need to reduce the number of classes you use as much as possible to reduce the size of jar files. This leads to many design compromises not least of which is flexibility.
It is not easy to adjust to J2ME development when you have to throw must of what you hae learnt (and come to value highly) about OO out the window. The truth is if you want apps that can run on a large range of phones you need to be very sensitive to the constraints of the devices.
As such I do not think an IoC framework will match many people's needs for J2ME development.
You might be interested in checking out FallME. Even though I haven't used it personally, it seems like a no non-sense framework built specifically for the J2ME platform.
I came across Spring ME during a Dutch JUG conference (have no experience with it whatsoever).
Signal Framework it is.
Update: unfortunately, Signal is very undercooked right now, so I'm going with Israfil IOC with custom additions.