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.
Related
I'm currently planing an application (brainstorming, more or less), designed to be used in small organizations. The app will require syncronization w/ a backend-server, e.g. for user management and some advanced, centralized functionality. This server has to be hosted locally and should be able to run on Linux, Mac and Windows. I haven't decided how I'm going to realize this, mainly I simply don't know which would be the smartest approach.
Technically speaking, a very interessting approach seemed to be node.js + mongoose, connecting to a local MongoDB. But this is where I'm struggeling: How do I ensure that it's easy and convienient for a organization's IT to set this up?
Installing node.js + MongoDB is tedious work and far from standartized and easy. I don't have the ressources to provide a detailled walthrough for every major OS and configuration or do take over the setup myself. Ideally, the local administrator should run some sort of setup on the machine used as server (a "regular" PC running 24/7 should suffice) and have the system up and running, similar to the way some games provide executables for hosting small game-servers for a couple friends (Minecraft, for instance).
I also thought about Java EE, though I haven't dug into an details here. I'm unsure about whether this is really an option.
Many people suggest to outsource the backend (BaaS), e.g. to parse.com or similar services. This is not an option, since it's mandatory that the backend will be hosted locally.
I'm sorry if this question is too unspecific, but unfortunately, I really don't know where to start.
I can give you advice both from the sysadmin's side and the developers side.
Sysadmin
Setting up node.js is not a big task. Setting up a MongoDB correctly is. But that is not your business as an application vendor, especially not when you are a one man show FOSS project, as I assume. It is an administrators task to set up a database, so let him do it. Just tell them what you need, maybe point out security concerns and any capable sysadmin will do his job and set up the environment.
There are some things you underestimate, however.
Applications, especially useful ones, tend to get used. MongoDB has many benefits, but being polite about resources isn't exactly one of them. So running on a surplus PC may work in a software development company or visual effects company, where every workstation has big mem, but in an accountant company your application will lack resources quite fast. Do not make promises like "will run on your surplus desktop" until you are absolutely, positively sure about it because you did extensive load tests to make sure you are right. Any sensible sysadmin will monitor the application anyway and scale resources up when necessary. But when you make such promises and you break them, you loose the single most important factor for software: the users trust. Once you loose it, it is very hard to get it back.
Developer
You really have to decide whether MongoDB is the right tool for the job. As soon as you have relations between your documents, in which the change of of document has to be reflected in others, you have to be really careful. Ask yourself if your decision is based on a rational, educated basis. I have seen some projects been implemented with NoSQL databases which would have been way better of with a relational database, just because NoSQL is some sort of everybody's darling.
It is a FAR way from node.js to Java EE. The concepts of Java EE are not necessarily easy to grasp, especially if you have little experience in application development in general and Java.
The Problem
Without knowing anything about the application, it is very hard to make a suggestion or give you advice. Why exactly has the mongodb to be local? Can't it be done with a VPC? Is it a webapp, desktop app or server app? Can the source ode be disclosed or not? How many concurrent users per installation can be expected? Do you want a modular or monolithic app? What are your communication needs? What is your experience in programming languages? It is all about what you want to accomplish and which services you want to provide with the app.
Simple and to the point: Chef (chef solo for vagrant) + Vagrant.
Vagrant provides a uniform environment that can be as closed to production as you want and Chef provides provisioning for those environments.
This repository is very close to what you want: https://github.com/TryGhost/Ghost-Vagrant
There are hundreds of thousands of chef recipes to install and configure pretty much anything in the market.
Background of the web application:
I am using java/spring-mvc/tomcat to provide my web service as well as exposing my restful API to mobile clients. I am happy with everything on the web surface right now. The problem is that my application has a really heavy computing process at its core, which invokes a separate Java program to process the images and return computed data back to the web service.
It sometime eats up lots of my EC2 instance memory, or causes an exception that shuts down my Tomcat7 server.
Question:
Right now everything is running under same tomcat7 container, and I am seeking a solution to decouple those two so that I can install them in different server, perhaps find a high memory server for computing program alone.
What are the options out there that allow me to decouple them and improve scalability and stability?
Update:
I can invoke computing engine programmatically or from command line.
Update2:
I have done some researches based on the answer. When I read on another post about What exactly is Apache Camel?, I feel I should probably learn a little more about EIP patterns. Hopefully, it is not overkill.
Solution based on suggestion
After reading through the EIP concept, camel in action, activemq, I finally come up with a solution. It might not be elegant, but it's working. Suggestion and comments would be appreciated!
I wrote a queue router based on apache-camel , connecting to activemq broker and running as standalone program in one server. The computing engine running in standalone container and the router is responsible to process jms requestor from my spring container in web server. Later on I just need to config load balance for computing engine from camel if further intensive computing is needed.
The one which are pointing right now is adding more hardware. You need to think through if this solves your problem. Eg: If you are using a 32 bit JVM there are limitations on how much heap size you can specify. If you are lucky to have a 64 bit JVM them then you will have a bigger room for memory. But there is always the possibility of using too much CPU where your application becomes unresponsive.
I prefer breaking the compute intensive tasks into jobs and work them out in a seperate JVM. Persist your jobs in a datastore/JMS so that they do not get lost. Be careful if you are doing DB updates from those jobs to avoid any locking.
If I understand correctly, it seems you need a load balancer.
Have a load balancer to route to one of multiple instances of your webservice/compute engine. You can achieve this using an esb, routing engine, clustered, master-slave, distributed-cache etc most of them interrelated.
And you can also spin up additional nodes realtime on EC2 based on load.
Else, if the task can be broken, then delegate it to multiple nodes/services. You will need some orchestration mechanism.
There are open source solutions that can address 1 and 2 above.
Does the backend work synchronously? I mean, when the mobile clients requests something do they have to wait for the backend to do a lot of processing?
If yes, you can grow horizontally, putting more worker nodes (backend webapps) and a front Nginx or any balancer. It's the fastest way.
Do you have reutilizable data? if yes, you can use something like memcached.
Hope it helps, if you give us more information I'm pretty sure that we will provide better advice.
I am building a complex HTML 5 application that takes advantage of Websockets. I am getting to the point where I have a lot of different types of data that gets updated in real time on the screen.
I want to know if it is going to be better for me to have fewer Websockets that are more complex, or a lot of simple Websockets open per page.
I added http://github.com/TooTallNate/Java-WebSocket web socket server to my Grails Application.
Right now I am going down the path of using a lot of simple web sockets for each task. I know using more sockets will use more memory on the server side but also more sockets means more concurrent processing.
Does anyone have any advice on how I can balance this.
Thanks for any tips in advance. Keith Blanchard
I think it is hard to make any reasonable statements about websockets without measuring the actual performance in specific browsers.
My inclination would be to have a single websocket per client.
There are some pretty hard limits on capacity server-side when doing IO ... relatively easily to saturate the channel when you have many connections (something that can bite heavily ajaxified systems as well).
Again, need to really measure to make intelligent statements about this.
Websocket-per-client would also make the application much more manageable ... depends on your actual use-case, but "more concurrency" is not necessarily better and can make managing state incredibly complex.
I personally did some benchmark on this one, and the results are:
10 websockets on a single page will cause page a little unresponsive when data coming in from each socket.
50 websockets on a single page will cause an unbearable freeze on the web.
So somewhere around 10 or less than 10 would be your upper limit.
I want to devlelop a chat website using JSP/Servlets and Tomcat. I have following questions:
Can the website handle load (1000 people at one time) without slowing down?
Will it cause the website to slow down? What is the ideal server configuration for this kind of website? Note that I don't have a huge budget to host.
How can I implement server push?
Will PHP or JSP be ideal for such website?
Depends entirely on hardware/software. It will obviously run faster on a Quadcore Xeon server from 2010 than an Octa Pentium Pro server from 2000. It will also obviously run and scale better if the code is written efficiently and the server is configured to an optimum.
See 1. I'd suggest to use the NIO connector in Tomcat.
You can use Comet for this. In Tomcat, it's available by AIO (Advanced IO).
Depends entirely on your own skillset. But technically, JSP/Servlet will likely scale better with this.
why re-invent the wheel? Just use an XMPP client. Here are some good clients and claros in particular is a good one.
I recently used a Java Web Start application. I launched it from my web browser using an embedded jnlp link in the page I was viewing. The application was downloaded, launched and worked just fine. It had access to my local file-system and remembered my preferences between restarting it.
What I want to know is why are Java Web Start applications not a more popular delivery format for complex applications on the web? Why do developers often spend considerable time & energy replicating desktop functionality in html/javascript when the power of a desktop application could be delivered more easily using Java & Java Web Start?
I know that in some corporate environments, e.g banking, they are relatively popular ways of delivering complex trading applications to clients, but why are they not pervasive across the web as a whole?
(For the sake of discussion let's assume a world where: download sources are "trusted" & applications are "signed" (i.e. no security concerns), download speeds are fast (load time is quick) and developers know Java (in the numbers they know html/js/php)).
I think the reason is not security nor startup time of the app. Let's understand what's behind the scene before we find out the root cause.
Java Control Panel has settings that allow users to use the default browser's proxy settings or to override them. In other words, infrastructure teams are able to customize the Windows or OS installation images to have JVM pre-installed with enterprise proxy settings. So I believe this is not an issue at all.
Java Web Start actually caches all apps with customizable settings in Java Control Panel. Once the app is cached, the app is "installed" just like other apps. Although first time execution may be slow, the second time will be fast due to JVM's smart memory allocation technique. So start up time could be an issue but a lot of web sites (even enterprise internal) are now migrated to portal. A web portal normally contains lots of unused libraries for development purposes due to the fact that the portal itself does not anticipate what kinds of portlets are built and deployed on a specific page. Therefore, downloading a single portal page could consume up to MBs and complete a page in more than 5 seconds; this is only one page and caching helps up to 30% but there are still lots of HTML/Javascript/CSS components required to download every time. With this, I am sure Java Web Start is an advantage here.
Java Web Start does not download again if it is cached as long as the server copy is NOT upgraded. Therefore, if, e.g. a project management software like MS Project, is completed using SmartClient (similar to JWS), the information exchange between the client and server would be purely data without presentation like browser's full page refresh. Even with the help of Ajax, it doesn't eliminate full page download entirely. Besides, a lot of companies consider Ajax to be immature and unsecured still. That is why Ajax is a hot topic in the circles of developers but not within enterprise software yet. With that in mind, JWS apps definitely have more advantages such as how JWS apps are deployed and executed in sandboxes, signed, and have much more interactive GUI.
Other advantages include faster development (easier to debug in code and performance), responsive user interface (does not require Comet Servers to provide PUSH functionality), and executing faster (for sure because client computers renders GUI without translation like HTML/Javascript/CSS, and less data processing).
After all these, I haven't touched the question yet, why JWS is not so famous?
My opinion is that it is the same as Brian Knoblauch's comment, it's without awareness.
IT folks are too attracted by the hype of Web Technologies, Ajax PUSH, GWT, and all those buzz words make them bias towards the fun of using different technologies or to resolve technical challenges instead of what's really working for the clients.
Take a look at Citrix. I think Citrix is actually a great idea. Citrix allows you to build your own app farms behind the scene. There are tons of upgrade and implementation strategies you can go for without impact to client experience. Citrix deployment is extremely easy, stable and secure. Enterprises are still using it. However, I think JWS is even better than Citrix. The idea of JWS is to run apps on client machines instead of hosting tons of server farms where client machines are capable of running these apps themselves. This saves a company a lot of money!!! With JWS, development team can still build business logic and data on server side. However, without the web processing unit and let the client computers do the rendering process, it greatly reduces the amount of network consumption and server processing power.
Another example of why JWS is an amazing idea is Blackberry MDS. Blackberry apps are actually Java apps translated from Javascript. With BB's MDS studio, you use the GUI tool to build BB app GUI, coding GUI logic in Javascript. Then apps are then translated and deployed on a BES server. Then the BES server will distribute these apps to BB. On each BB, it runs a thin Java App with GUI rendering and networking capability only. Whenever the app requires data, it communicates with the BES through web services to consume services from other servers. Isn't this just JWS BB version? It's been extremely successful.
Finally I think JWS is not popular because of how Sun advertises it. BB never advertises how good their BB Java apps are, they believe clients won't even care what is it. BB advertises the benefits of using MDS to develop apps: Fast, Cost Saving, Business Return.
Just my, a bit long, 2 cents... :)
A major roadblock for Java Webstart is probably that you still need to have a JVM installed before it can even attempt to download and start your application. Everyone has a browser. Not everyone has a JVM.
Edit:
I've since acquired some hands-on webstart experience and can now add these two points:
The Deployment Toolkit script and the modularized JVM released somewhere around Java 1.6u10 make the JVM requirement less problematic since it can automatically download a JVM and the API core and start the program wile downloading the rest.
Web Start is seriously buggy. Even among the Java 1.6 releases there was one which downloaded the entire app every time, and another which downloaded it and then failed with an obscure error message. All in all, I cannot really recommend relying on such a fragile system.
I think it's mostly due to a lack of awareness. It works very well. Quite seamless. App only downloads if it's the first time, there's been an upgrade, or if the end-user has cleared the cache. Great way to deploy full-blown desktop apps that user won't have to worry about manually upgrading!
The problem with Webstart is, that you actually have to 'start' something which isn't at all that fast even with a fast connection, while with a webapp you enter the URL and the app is there.
Also a lot of things can go wrong with webstart. Maybe the intended user doesn't have the privileges needed, or the proxy of webstart is configured wrong, or something went wrong with jre dependencies or there is simply no java installed in the first place. So for the average john doe in the internet it is not at all pleasent.
In controlled environments like a company it is a good and easy solution in many cases.
I've worked on a JWS-deployed application for a few years over a user base of a few thousands and its automatic upgrades are actually a huge pain.
On every update for some reason dozens of users get "stuck in the middle". All you get is the "class not found" exception (if you're lucky), or uninformative "unable to launch" from JWS before it even gets to your code. Looks like the update is half-downloaded. Or, in other words, it does not download and apply the update atomically AND has poor caching so that relaunching the app from the same URL does not fix anything.
There's no way to resolve it other than clearing JWS cache or providing a different URL (e.g. append ?dummyparam=jwssucks at the end). Even I as a developer hit it sometimes and don't see a way around.
When it works, it works. But too often it doesn't, and then it's a huge pain for you and your helpdesk. I would not recommend it for enterprise or mission-critical use.
There is a very big issue namely that it doesn't allow for "start the program instantly and THEN check for and download any updates in the background" deployments, which is what the defacto behaviour of applications are converging to.
I consider this personally so big an annoyance that we are actively looking for another technology which provides that.
From these posts it looks like when using Web start, it is important to make a good care about the server. The "huge pain" of downloading application on every startup may be caused by incorrect time stamp delivered from the server. Here not the application but the server must be configured to use caching properly and not just to disable it. About buggy start, I am not that much sure, but it seems to me that this also may be caused by unreliable connection.
Important advantage of Web start is that it works nicely with OpenJDK under Linux. Clients of some happy developers use Windows only but my clients do not.
HTML and JavaScript, mentioned in the initial question, are lighter approaches that work fine with smaller tasks like animated buttons or even interactive tables. Java niche seems around much more complex tasks.
Java Web Start is kind a successor of Java Applets, and applets got burned around the new millenium.
But, I still think Java Applets are way better than GWT or Javascript hell.
Java Web Start vs Embedded Java Applet