|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 21
Messages: 21
Messages: 21
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Switching to Glassfish
Adam Bien and Glen Smith have blogged that they've switched to Glassfish ("Glassfish could become the killer appserver for Java EE 5..." and "Making the switch to Glassfish"), saying that Glassfish is "more interesting for production and so commercial use" and also commenting on the web console. They've found the server "rock solid." However, some of their comments call into question how many comparable app servers they've used. They focus on open source application servers, which limits the pool for most people to JBoss, JOnAS, Geronimo (and its IBM cousin, WebSphere Application Server Community Edition), and - of course - Glassfish (and its commercial offspring, Sun Java System Application Server 9, Platform Edition).
One of the primary focuses for both bloggers is the web console. From Adam Bien:Human-readible/usable admin console: for real world production environments it is often not enough to provide a JMX-console or a text/XML configuration file. Most of the administrators would like to work with more comfortable interface. Working direct with configuration files could even become dangerous in production. This seems like a point against, perhaps, JBoss and JOnAS; it should be noted that Geronimo, another open source application server, has a very useful web application for a console as well, and it's arguably faster and easier to use, although Geronimo is a J2EE 1.4 server and not a Java EE server as Glassfish is.
Glen Smith points out Glassfish' reputation for being rock solid, without pointing out specific sources for this reputation. One presumes he's referring to Glassfish V1 and not the active development tree in V2, which is not production-ready.
What are your experiences, if any, with Glassfish? What web application consoles have you found to be useful enough for complete management tasks, and why? Is Java EE enough to push you to Glassfish or the other available Java EE servers, most of which only implement parts of the Java EE specification?
|
|
|
Message #215662
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Switching to Glassfish
As long as "Commit option A is not supported for this Application Server release." I can't switch. :)
Regards,
Horia
|
|
|
Message #215703
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
relationshiop between Glassfish and tomcat
can anybody description the relationshiop between tomcat and glassfish?
|
|
|
Message #215756
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Web console not used in production
I would say the contrary, that for production use you don't want a web console that system admins can mess with. Also from security reasons it's better to not have a web console that probably have some vulnerabilities.
At least for the production use I have seen, the console is disabled, after the initial development phase when the application is stable.
Keeping the configuration in xml, under source control, is a better guarantee that arbitrary changes are not made to a functioning configuration. Changes in the production configuration are controlled and tested in a test environment before moved to production. Perhaps the test systems can benefit form a nice-to-use console, and the tested xml is then moved to production in a controlled way.
|
|
|
Message #215767
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: relationshiop between Glassfish and tomcat
The GlassFish web container supports the Java EE 5 Specs (Servlet 2.5, JSP 2.1 and JSF 1.2), while the Apache variants are supporting the J2EE 1.4 specs. The Servlet container was based on Tomcat (Sun was a long-time contributor to that effort) but it is now a separate code-base. Grizzly, the NIO-based connector is only available at GlassFish. The JSP compiler and Servlet container have continued to be improved along multiple lines while at GlassFish.
Hope this helps, - eduard/o
|
|
|
Message #215768
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Web console not used in production
GlassFish also has a very complete CLI administration interface. - eduard/o
|
|
|
Message #215774
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
rock solid ?
They've found the server "rock solid."
Are they using it on Linux server ? SJAS is not "rocket solid" at all, it's leaking file descriptors as a sieve. All versions 8.x are affected. We tried Glassfish as well, but it had the same problem. It's very easy to reproduce it - just install SJAS or Glassfish and open admin console. Every time a page is accessed the number of open file descriptors are increased. In production after some time the server drains all file descriptors and it fails with IO exception "too many file descriptors".
Therefore we couldn't use Glassfish in production.
The reason is a bug in JDK, NIO which is fixed in AFAIK Mustang only.
Some time ago I wrote a socket server using NIO and it had the same problem. But there is a workaround for JDK 1.5:
1) Socket needs to be shutdown and closed. Just close() won't work.
2) Also I had to register all Sockets in a concurrent hash map, so I can close them after some period of inactivity.
Regarding SJAS, this bug is listed as fixed in 8.2, but AFAIK it's still there. I tested SJAS 8.2 and I didn't notice any improvement.
So, please be aware of this issue.
|
|
|
Message #215782
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: rock solid ?
I have been runnging some SJAS verion 8 for over a year and have never seen this issue. From what you say, it should be easy to reproduce. I also search the Sun forums and Google, but didn't see anything about it.
I have not worked with verion 9, but 8 works pretty good. We also use WebSphere, but most (not all) of the people here think Sun's is better.
|
|
|
Message #215794
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Web console not used in production
I would say the contrary, that for production use you don't want a web console that system admins can mess with. Also from security reasons it's better to not have a web console that probably have some vulnerabilities.
At least for the production use I have seen, the console is disabled, after the initial development phase when the application is stable.
Keeping the configuration in xml, under source control, is a better guarantee that arbitrary changes are not made to a functioning configuration. Changes in the production configuration are controlled and tested in a test environment before moved to production. Perhaps the test systems can benefit form a nice-to-use console, and the tested xml is then moved to production in a controlled way.
I think that is true in many cases as well, however some consoles provide more than configuration options such as monitoring or diagnostics capabilities. And some products provide transactional change capabilities to limit the incidents of "accidental" changes. There are also of course configuration changes that fall under the category of tuning, requiring on the spot changes to parameters to keep things flowing, etc.
So I think consoles have their place in production as well.
Mike Jasnowski
BEA Systems
|
|
|
Message #215810
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: rock solid ?
I have been runnging some SJAS verion 8 for over a year and have never seen this issue.
I think it depends on your server load and on Linux settings. When we increased number of file descriptors a process can open (about 1000 by default) then the server was more or less stable.
|
|
|
Message #215840
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: relationshiop between Glassfish and tomcat
but it is now a separate code-base. Grizzly, the NIO-based connector is only available at GlassFish. The JSP compiler and Servlet container have continued to be improved along multiple lines while at GlassFish.
Hope this helps, - eduard/o
Does that mean it runs much faster than Tomcat5.5 for jsp and servlet? (since my application requires only jsp and servlet). Can it support 2000 concurrent request per second?
Thank you for the feedback.
|
|
|
Message #215860
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Switching to Glassfish
Has anybody seen any specific articles about switching from Tomcat to SJAS 9?
We are about to commit to doing this - guidelines of what we are in for would be great!
|
|
|
Message #215868
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Switching to Glassfish
Glassfish seems to be a strong project. Being one of the developers of the Jetty webcontainer, I have to qualify that by saying that my interest is focussed primarily on their web tier.
As Jetty 6 is a Servlet 2.5 container, we needed to move up to JSP 2.1. After some initial testing, we found that Glassfish's implementation of JSP 2.1 was reliable and well supported by an active team of developers, some of whom were key developers for earlier versions of Apache's Jasper on which Glassfish's JSP is based. Moreover, they were extremely supportive of my move to embed it in Jetty.
So, on the theme of "switching to Glassfish", Jetty has switched to use Glassfish's JSP 2.1 implementation, as I've blogged
about recently.
|
|
|
Message #215923
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Switching to Glassfish
Sun, a hardware company, finally comes out to compete with its Java licensees. Does that mark the beginning of the demise of Java EE?
|
|
|
Message #215969
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Switching to Glassfish
Actually, the adoption curve for Java EE 5 is *much* faster than for J2EE 1.4 (the previous release). I think that part of that is because Project GlassFish makes it easier for vendors to pick and choose newer implementations of specificiations and incorporate them into their products, and we are actively encouraging that cooperation.
It is a typical "coopetition" arrangement. We cooperate in some areas, compete in others.
- eduard/o
|
|
|
Message #215981
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Switching to Glassfish (from Tomcat)
Hi Steven.
Why don't you ask this at the USERS mailing list at Project GlassFish. I don't know if we have that info but we should. The best way to make it happen is to show customer (you) requests.
That would be "USERS@glassfish.dev.java.net".
Thanks,
- eduard/o
|
|
|
Message #215982
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: relationshiop between Glassfish and tomcat
but it is now a separate code-base. Grizzly, the NIO-based connector is only available at GlassFish. The JSP compiler and Servlet container have continued to be improved along multiple lines while at GlassFish.
Hope this helps, - eduard/o
Does that mean it runs much faster than Tomcat5.5 for jsp and servlet? (since my application requires only jsp and servlet). Can it support 2000 concurrent request per second?
Thank you for the feedback.
Yes, but as always, you mileage will vary.
Whether you can support the load is a question of the underlying hardware as well as any external resources (e.g. database) that you might be accessing. Those are as likely to bottleneck your throughput as anything. And whether your actual servlet/jsp application scales is another question. But grizzly will have no problem handling 2000 users (or even 10000s of users on big hardware).
You said "faster", but I think you're more concerned about "more scalable" since you're talking about the number of users/requests that can be supported. That's really the fundmental benefit of glassfish vs tomcat (or any tomcat-based appserver): the NIO architecture of the glassfish HTTP engine (grizzly) allows massive scalability. Tomcat is hampered by requiring one thread to handle every connection. We've gotten tomcat to limp along at up to 2000 users, but with that many threads, CPU contention and memory become severe constraints; glassfish will just hum along since it will need only a few threads for that many requests (again subject to the actual servlet/jsp code).
On the other hand, that benefit is most important when the HTTP clients in question use keep-alive. If you have 2000 users doing single requests and then closing the connection, then the OS-level TCP connection code will be your bottleneck no matter what.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
