Discussions

News: Switching to Glassfish

  1. Switching to Glassfish (21 messages)

    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?

    Threaded Messages (21)

  2. Re: Switching to Glassfish[ Go to top ]

    As long as "Commit option A is not supported for this Application Server release." I can't switch. :) Regards, Horia
  3. Re: Switching to Glassfish[ Go to top ]

    what does Coomit option A means please ?
  4. Re: Switching to Glassfish[ Go to top ]

    http://wiki.jboss.org/wiki/Wiki.jsp?page=CMPCaching Regards, Horia P.S. This term is not EJB 3.0/JPA specific. Hopefully, the same entity cache behaviour ( pessimistic-lock, between transactions cache ) will be available in major JPA providers even if it is not mandated by the specs.
  5. can anybody description the relationshiop between tomcat and glassfish?
  6. 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
  7. 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.
  8. 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.
  9. 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.
  10. GlassFish also has a very complete CLI administration interface. - eduard/o
  11. 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
  12. rock solid ?[ Go to top ]

    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.
  13. Re: rock solid ?[ Go to top ]

    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.
  14. Re: rock solid ?[ Go to top ]

    I also search the Sun forums and Google, but didn't see anything about it
    Here is the thread with our discussion. http://forum.java.sun.com/thread.jspa?threadID=665921 And bug reports: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6351373 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6215050 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6321777
  15. Re: rock solid ?[ Go to top ]

    All of the bug reports that you reference are "Closed, fixed".
  16. Re: rock solid ?[ Go to top ]

    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.
  17. Re: Switching to Glassfish[ Go to top ]

    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!
  18. 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 at glassfish dot dev dot java dot net". Thanks, - eduard/o
  19. Re: Switching to Glassfish[ Go to top ]

    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.
  20. 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 ...
    JOnAS Administration console is very usable and looks very nice. You can see it here : http://jonas.objectweb.org/current/doc/Admin.html#Admin-JonasAdminUse
  21. Re: Switching to Glassfish[ Go to top ]

    Sun, a hardware company, finally comes out to compete with its Java licensees. Does that mark the beginning of the demise of Java EE?
  22. 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