Discussions

News: Sun Java System Application Server PE 8.2 has been released

  1. Sun has announced the release of the Sun Java System Application Server PE 8.2, an update to their production J2EE 1.4 application server. Improvements include better multicore support, Fast Infoset for webservices, JMS connections to MQSeries and Sun's MQ Server, and the inclusion of Apache Derby for database support. SJSAS is available for download at no cost from Sun.

    SJSAS is the reference implementation for J2EE 1.4, and is included (as one of many possible downloads) in Netbeans as the default container for J2EE.

    For full details on updates included in SJSAS 8.2, see the release notes.

    Threaded Messages (34)

  2. So what???
  3. *sigh*[ Go to top ]

    Ah, the joy of editing TSS. See the opposite of your post in the thread on Spring today: Bob Lee: I Don't Get Spring by Steve Zara, who's silent in THIS thread. :)
  4. One feature that jumps out from the original posting is the support for Fast Infoset. Have any TSS readers had any experiences (good or bad) with Fast Infoset yet? It's an intriguing idea and could potentially yield significant performance improvements in WS / SOA apps but I expect interoperability will be enough of any issue to prevent widescale adoption.

    Keen to hear if anyone has tried Fast Infoset in real applications.

    Cheers,

    Andy Grove
    FireStorm/DAO 3.0 Generates Java code from relational schemas
  5. Fast Infoset[ Go to top ]

    Coincidentally I posted some activity on FastInfoset this morning in TheAquarium. Check http://blogs.sun.com/roller/page/theaquarium?entry=technical_discussions_in_glassfish_implementation

    Fast Infoset is also available through JAX-WS 2.0 in the new JWSDP 2.0. See http://blogs.sun.com/roller/page/theaquarium?anchor=jwsdp_2_0_is_out
  6. documentation[ Go to top ]

    Sun one 8 appserver has the worst documentation.

    Sun has to learn to document things before they come out with nice things.

    Sun One Studio 8 E is great but no documentation, all they say is its built on netbeans and refer to netbeans documentation in bits and peices...

    Wake up guys and look around.. documentation is the need of the hour
  7. documentation[ Go to top ]

    Sun one 8 appserver has the worst documentation.Sun has to learn to document things before they come out with nice things.Sun One Studio 8 E is great but no documentation, all they say is its built on netbeans and refer to netbeans documentation in bits and peices...Wake up guys and look around.. documentation is the need of the hour

    Nithya, I'd be interested in knowing exactly what is broken so we can fix it. You say the App Server documentation is the "worst" but you actually use Sun java Studio Enterprise 8 (I think) as an example. That's a different product but important to me nonetheless.

    Could you elaborate on the issues you've hit - on this forum or via direct email - sharps at sun do com.

    Thanks, Rich

    Rich Sharples
    Sun Microsystems
    http://blogs.sun.com/theaquarium
  8. SJSAS is the reference implementation for J2EE 1.4, and is included (as one of many possible downloads) in Netbeans as the default container for J2EE.

    Small question about the use of "reference implementation" here. I thought reference implementation meant "do not use in production, good for learning though". Is this still the case or is SJSAS 8.2 a full J2EE web application server that can fully compete with WebLogic, Websphere and JBoss in a deployed production environment? And what exactly does "reference implementation" mean anyway?
  9. It's both.

    As the reference implementation, it's basic role is if you want to know how the specification is supposed to work, the reference implementation works "correctly".

    But that doesn't mean that the RI can't be a reliable or performant server.

    Obviously, given a choice between correct behavior and performance and/or stability, then the RI should lean towards correctness. But one can argue that if the "correct" behavior is not performant, or stable, then that behavior may well just be flat out questionable.

    On the other hand, production servers may well offer options or configurations that may, perhaps, sacrifice comapatability for performance. The RI may well not offer those kind of choices.

    Rich can no doubt comment better on this, but the SJAS has demonstrated performance (through SPEC benchmarks), and folks are using it in production.

    So, SJAS is "all of the above".
  10. It's both.As the reference implementation, it's basic role is if you want to know how the specification is supposed to work, the reference implementation works "correctly".But that doesn't mean that the RI can't be a reliable or performant server.

    What Will said + a bit of background / history :

    Up to the J2EE 1.3 SDK there was an explicit clause in the license inhibiting use in production. People complained and were deploying anyway so we changed the license to allow production use. We also tarted the RI up a fair bit to make it more accessible and useful - the original RI was pretty basic and wasn't exactly built for speed. So, the publically available thing became the Platform Edition - a basic App Server intended to promote J2EE that was based on the Reference Implementation.

    The "RI" still exists - it's the barebones thing that is made available only to licencees along with the compatibility kit (TCK).

    Today you won't see all the features you'd expect to see in an enterprise product (ie. clustering, HA, multi-machine management, etc) - those feature would make the product less accessible (ie. more complex) and would hinder adoption of J2EE. For production deployments - I'd say the sweet-spot is probably a single, dual-CPU machine serving a couple of hundred concurrent users - we achieved some pretty decent SPECjAppServer numbers to demonstrate that.

    If you are doing this kind of thing with Tomcat and need more than a servlet engine you should take a look.

    Rich Sharples
    Sun Microsystems
    http://blogs.sun.com/theaquarium
  11. SJSAS is the reference implementation for J2EE 1.4, and is included (as one of many possible downloads) in Netbeans as the default container for J2EE.
    Small question about the use of "reference implementation" here. I thought reference implementation meant "do not use in production, good for learning though". Is this still the case or is SJSAS 8.2 a full J2EE web application server that can fully compete with WebLogic, Websphere and JBoss in a deployed production environment? And what exactly does "reference implementation" mean anyway?

    Originally the RI was to show a potential way to implement the spec but Sun has turned it into a seeding vehicle where they hope you will use it and "graduate" to their commercial product. Any other explanation is pure salesmanship...
  12. Originally the RI was to show a potential way to implement the spec but Sun has turned it into a seeding vehicle where they hope you will use it and "graduate" to their commercial product. Any other explanation is pure salesmanship...

    Reference Implementation is a technical term in the context of a JCP specification. It means an implementation that is compliant with that specification and passes the TCK tests. There is a wide range of RIs out there, in some cases they are just showing that the spec is feasible, in others they are fully featured products.

    The old J2EE RI from Sun was indeed based on a separate code base than Sun's product. That was quite a while ago. For the last few releases the Reference Implementation for the J2EE platform has been based on the exact same code base as Sun's commercial products. Nothing else would make sense for Sun, specially since Sun's AppServer products are free for use.

    The GlassFish project is where the next version (Java EE 5-compliant) of the AppServer is being created. Project home is at http://glassfish.dev.java.net. A good source of news from the community is http://blogs.sun.com/theaquarium

    Hope this helps - eduard/o
  13. All versions are free now[ Go to top ]

    All of the versions of Sun App Server are free now. That happened in late 2005. They are all free and open source.

    As for the service on the Platform Edition, Appendex A of the admin guide will show you how to do it. I have done it to a couple of servers.
  14. All versions are free now[ Go to top ]

    All of the versions of Sun App Server are free now. That happened in late 2005. They are all free and open source.

    Take a look at Solaris Enterprise System. The audiocast explains the details.

    "...Sun builds on success of the Solaris OS by announcing Java Enterprise System, developer tools and N1 Software are now available at no cost."
  15. All versions are free now[ Go to top ]

    All of the versions of Sun App Server are free now. That happened in late 2005. They are all free and open source.
    Take a look at Solaris Enterprise System. The audiocast explains the details. "...Sun builds on success of the Solaris OS by announcing Java Enterprise System, developer tools and N1 Software are now available at no cost."
    <br><br>
    Note all Sun sw is now free to download, but if you want support, you will need to buy that separately. As Eduardo pointed out, Sun App Server from the next version (9) is available as open source. No previous versions have been, or are planned to be, open sourced. You can get the open source Java EE 5 implementation at the Open GlassFish Community java.sun.com/javaee/glassfish. It is this implementation that will serve as the basis of App Server 9.
  16. Memory leaks[ Go to top ]

    The same story as for 8.1 version. Try several deployment/undeployment of J2EE applications. You'll be soon out of memory. Tis are an academic implementations, both Netbeans and SJS AS. Oy can play, you can educate, but you can't seriously develop.
  17. SJAS on Linux[ Go to top ]

    Is anybody using SUN AS PE or Glassfish on Linux in production ? It would be very interesting to know.

    We wrote a system for online payments consolidation using NetBeans and SUN AS. So we decided to use SUN AS on production server as well. However we experienced several problems:
    1) It seems that there is a resource leakage - AS opens Linux pipes quite often and doesn't close them. So number of open file descriptors grows until it reaches about one thousand.
    2) Sometimes SUN AS stops responding to HTTPS requests. There are no error messages and AS is still working, other HTTP listeners are working and it's possible, for example, to open admin console.

    Other people have had those problems as well. And it's possible to reproduce first problem without any application deployed. Just install SUN AS and open admin console. SUN AS will open 180 file descriptors.

    Both problems happen on Redhat Enterprise Linux 3.0, 4.0 and SUSE, both for SUN AS and Glassfish. So after we tried all those configurations (including JDK update) we had no choice but to migrate to JBoss. It was not a pleasent process either, but our system is rock stable on JBoss.
  18. Glassfish[ Go to top ]

    Is anybody using SUN AS PE or Glassfish on Linux in production ?

    Glassfish is just approaching beta quality, so there should not be too many production users..

    Peter

    Glassfish news:
    http://blogs.sun.com/theaquarium
  19. Yes, I've had the same problem on Windows with Sun App Server 7. I had to restart the server once in a while for that reason. This was quite annoying, and I was hoping it has been fixed...
  20. SJAS on Linux[ Go to top ]

    You might face this problem:

    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6313023

    A possible workaround is to increase PermSize=128m

    But I'm puzzled about the file descriptor problem you are seeing. I'm developping GlassFish (the Grizzly Http Connector, which is a good candidate for fd leak) on Fedora 4, and I'm not getting the 180 fd, for both 8.2 and GlassFish. They share the same HTTP connector BTW.

    Info on the HTTPS problem would also be usefull if you are able to reproduce the problem (a thread dump will be perfect).

    Thanks

    -- Jeanfrancois
  21. I also suspect you may face a VM bug on Linux where socket stay BOUND forever. See the forum thread for a possible workaround.

    -- Jeanfrancois
  22. thank you, we will try this workaround when we will do a new installation of our app.
  23. SJAS on Linux[ Go to top ]

    Info on the HTTPS problem would also be usefull if you are able to reproduce the problem (a thread dump will be perfect).Thanks-- Jeanfrancois

    I have posted a stack trace in this forum.
    this thread

    It's not easy to reproduce this problem, because with our system it happened once a week at indeterminate time.
  24. Windows service[ Go to top ]

    Can it now be installed as a Windows service? This was possible Sun ONE AppServer 7, but for some strange reason not in 8.0 or 8.1.
  25. Windows service[ Go to top ]

    Can it now be installed as a Windows service? This was possible Sun ONE AppServer 7, but for some strange reason not in 8.0 or 8.1.

    I never tested it, but try this suggestion:
    http://squid.hit.bme.hu/wa/pro/sjsas/sjsas.html

    Peter
  26. Windows service[ Go to top ]

    Yes, I know about this solution, thanks. Still this is a workaround. I would prefer the Sun's native implementation -- the one found in Sun App Server 7. This is quite simple but important feature for this kind of software -- why Sun decided to drop it?
  27. Out of memory with deploy/undeploy?[ Go to top ]

    I have a large scale production installation of SJAS 7 EE on Solaris 9 and have never experienced "out of memory" exceptions in regards to application deployment. The applications deployed range in size and initial resource usage from the very small to the very large. I am interested in the size of the applications you are deploying as well as the resource usage you are incurring (i.e.:data caching in memory on app start-up).

    What I do find problematic is the way the connection pool mechanism is implemented. Apparently if a DB connection is left open, the connection will not be closed, even if the object that created the connection is GC'ed. Obviously this is not a problem if you are closing your connections, but in the event of programmer error connections will continue to open until the pool max is reached and then we are left with the all to familiar 'wait time expired' exception. Since this behavior is continued in SJAS 8, I must assume that this is a purposeful implementation intended to make developers keep their code 'tight'. This would not be problem if I did not have a gaggle of consultants that claim this behavior is exhibited in no other application server.

    Does anyone else have any experience with this issue?
  28. Out of memory with deploy/undeploy?[ Go to top ]

    Well, if application does not close connection, then that is bad anyway. So, I wont blame appserver for that.

    In any case, GlassFish has some interesting features to help you out, even if some developers have done some mistakes.

    https://glassfish.dev.java.net/javaee5/integration-tech/glassfish_connpooling.html

    Look for lazy connection association and lazy connection enlistment.
  29. Out of memory with deploy/undeploy?[ Go to top ]

    Well, if application does not close connection, then that is bad anyway. So, I wont blame appserver for that.In any case, GlassFish has some interesting features to help you out, even if some developers have done some mistakes.https://glassfish.dev.java.net/javaee5/integration-tech/glassfish_connpooling.htmlLook for lazy connection association and lazy connection enlistment.

    Well stated. It would seem apparent that the pooling issue is addressed post GlassFish. So in summary, for those of us using SJAS versions prior to GlassFish, just close your connections.
  30. this behavior is exhibited in no other application server.

    You can have the appserver configured to clean up rogue connections in the connection pool (and monitor them using admin console) in weblogic 9.0, websphere 6.0, tomcat5.1 etc.,

    Sun one doesn't have this feature although you can monitor the connection pool using the CLI utility (on 7.x) and admin gui in 8.0.
  31. handling rogue connections[ Go to top ]

    Nithya,

    It depends on what you meant by Rogue connection.

    - If a connection in the pool goes bad, Sun app Server can detect it (validates connection before giving one to client from pool, there is a configurable policy for this) it can re-establish it before giving it to the requestor. This has existed since 7.0 release. It can also pro-actively look at the rest of the connections and clean them up too. This continues in all releases 8.x and in 9.0 as well. This is automatic. No manual administrator intevention is even reqd. If this is what you mean by handling rogue connection, I think we handle it nicely.

    - If there is a bad or rogue application that is creating connections and does not close them, it is going to run out of connections eventually. It all depends on how quickly it is leaking the connections. If the abandoned connection is not involved in a transaction and appears to be idle for too long, it may be possible to switch or recycle the connection. This can keep a bad application going for longer. We do plan to support this sort of thing in a forthcoming enterprise edition release of the product (slated for a Java EE 5 synch).

    - A new self management framework has been introduced in project GlassFish (see: https://glassfish.dev.java.net/javaee5/selfmanagement/selfmanagementhome.html)
    in many cases it may be possible for you to write a little MBean that looks out for your favorite bad scenario and do what is appropriate for your environment.

    If you have any feature suggestions, we would love to hear more from you.

    Thanks

    Sreeram Duvur
    Lead, J2EE High Availability
    Sun Microsystems
  32. We use 8 PE in production[ Go to top ]

    I work for an organization that uses 8 PE in production. We have it running on some pretty old servers. I have not noticed any major memory issues.

    Also, I think that the documentation is pretty good. We also do WebSphere and we can find things in the Sun documentation a lot faster then in the RedBooks of IBM.

    Mike
  33. SJS as open source[ Go to top ]

    This seems to be a pretty rumour running round the world regarding SJS as open source. Can someone point us, where the SJS 8.1 or 8.2 source code can be downloaded? I don't see anywhere this code...
  34. SJS as open source[ Go to top ]

    This seems to be a pretty rumour running round the world regarding SJS as open source. Can someone point us, where the SJS 8.1 or 8.2 source code can be downloaded? I don't see anywhere this code...

    Appserver.next with J2EE 1.5 support called Glassfish is opensource, see:
    https://glassfish.dev.java.net/

    The Aquarium is the good starting point for Glassfish related infos:
    http://blogs.sun.com/theaquarium
  35. SJS as open source[ Go to top ]

    This seems to be a pretty rumour running round the world regarding SJS as open source. Can someone point us, where the SJS 8.1 or 8.2 source code can be downloaded? I don't see anywhere this code...

    What was open sourced was the code base for 9.x. To get those, check http://wiki.java.net/bin/view/Projects/GlassFishSources or http://blogs.sun.com/roller/page/theaquarium?entry=sources_for_glassfish_builds

    8.1 and 8.2 were not open sourced, just because we would have to do all the due diligence on IP and all of that, and because we thought people really were interested in the future.

     - eduard/o