|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 18
Messages: 18
Messages: 18
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Jetty 5 released and potential future mapped out
Greg Wilkins has announced the release of version 5.0 of the popular Jetty servlet container. He has also provided some valuable insight into the future of Jetty to take advantage of some of the new features of Java, such as NIO.JettyExperimental now implements most of HTTP/1.1 is a push-pull architecture that works with either bio or nio. When using nio, gather writes are used to combine header and content into a single write and static content is served directed from mapped file buffers. An advanced NIO scheduler avoid many of the NIO problems inherent with a producer/consumer model.
Thus JE is ready as a platform to experiment with the content API ideas introduced above. I plan to initially work toward a pure content based application API and thus to discover what cannot be easily and efficiently fitted into that model. Hopefully what will result is lots of great ideas for the next generation servlet API and a great HTTP infrastructure for Jetty6. What would you like to see in Jetty, or from the Servlet API itself?
Read more on Greg's blog
|
|
|
Message #139784
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jetty 5 relesased and potential future mapped out
From a "code perspective," Jetty is still my favorite. You can tell that Greg & co. really put a lot of love into making the code readable and well-done. Anyone who wants to learn about the non-complexities of a Servlet Container (i.e. how simple it really is) should look at Jetty.
Peace,
Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters
|
|
|
Message #139795
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
slightly odd thought
I've been pondering this question in my head for a while. Does it make sense to create a High Availability/High performance specification that uses SEDA style architecture? I've been thinking it's just too daunting to retrofit servlet specification to support an event driven approach using non-blocking IO and lots of resource sharing. Having read through SEDA and Haboob on several occasions to learn exactly how it works, I find it elegant and very powerful.
The servlet approach is easy for new programmers to pick up, but at a certain point, the servlet container just can't handle anymore connections. Most people don't actually need to support crazy loads or handle ten thousand concurrent connections. It's probably a crazy idea, but what do people think?
|
|
|
Message #140058
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jetty 5 relesased and potential future mapped out
From a "developers perspective" Jetty is great as well. Great for running your J(Web)Unit tests and debugging your web apps.
The Eclipse plugin JettyLauncher just moved to a seperate project: http://jettylauncher.sourceforge.net. Not only does the new version support Jetty 5, but it also supports Jetty Plus, which is great for people developing apps that use JNDI etc.
Eelco Hillenius
|
|
|
Message #140161
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
slightly odd thought
I think you are 100% spot on. Applicationsneed a rational scalable architecture.Servlets are just an entry point for requestsand responses, like RMI, SOAP, or whatever.More better stuff is needed underneath.For some of my thoughts take a look athttp://www.possibility.com/epowiki/Wiki.jsp?page=AppBackplane. thanks for the link. it's interesting. I'll have to read it more thoroughly and compare it to SEDA and other Event driven approaches :)
|
|
|
Message #140212
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jetty 5 released and potential future mapped out
I have a question.
Has/Is Jetty used in production apps ? Small small or medium ?
|
|
|
Message #140218
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jetty 5 released and potential future mapped out
Definitely, I know of at least one *large* deployment that uses Jetty as the webserver and servlet container. In the past, Jetty enjoyed better performace than it's competitors (mainly tomcat), but after large refactorings on the tomcat code base, the difference is less noticeable now.
Tomcat 5 is probably a reasonable competitor to Jetty 5, but older versions don't come close to the reliability and predictability of Jetty.
|
|
|
Message #140250
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jetty 5 released and potential future mapped out
Has/Is Jetty used in production apps ? Small small or medium ? I can't tell if you're joking or not, but Jetty's been used in production apps for years.
I've personally seen it being used in one very big cluster. (Coherence includes HttpSession and ServletContext clustering support for Jetty.)
Peace,
Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters
|
|
|
Message #140255
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jetty 5 released and potential future mapped out
Has/Is Jetty used in production apps ? Small small or medium ? I can't tell if you're joking or not, but Jetty's been used in production apps for years.I've personally seen it being used in one very big cluster. (Coherence includes HttpSession and ServletContext clustering support for Jetty.)Peace,Cameron PurdyTangosol, Inc.Coherence: Shared Memories for J2EE Clusters
I would add that tomcat and resin both get asked this question quite frequently. Unless it's from one of the top 5 commercial providers, many people still think it's not used in production or in large deployments.
I know of a few large sites getting 5million+ page views a day using one of the three servlet containers. An easy way to find out is to use jmeter to send a request to a site and look at the raw response and http header.
|
|
|
Message #140289
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is NIO the end of ThreadLocal and what's the alternative?
Just curious, but if you use a SEDA architecture or a push/pull architecture, don't you break with the common one thread per request scenario that us developers have come to depend on?
For example, take a framework like Spring (or JBoss, Struts, etc.). These frameworks will often use ThreadLocals to maintain context information regarding transactions, logging, security, you name it, to propogate the context throughout the framework. Heck, we use ThreadLocals in our application code to pass context.
So, won't switching to a non thread-based request process render all of these frameworks ineffective?
|
|
|
Message #140323
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
one thread per request is broken
>don't you break with the common one thread per request
> scenario that us developers have come to depend on?
It needs to be broken. These frameworks force
an application architecture. Your application architecture
shouldn't be determined by a servlet or a database or
anything but the needs of your application.
Sure, a single threaded approach may work fine for
a stateless web back end.
But what if you are doing a real application on the
backend like handling air traffic control or a
manufacturing process?
In these cases a single threaded approach makes
no sense because a web page is just one of a thousand
different events an application will be handling.
All events are not created equal. Threads, queues,
priorities, CPU limits, batching, etc are all tools
you can use to handle it all.
It took me a while to figure out why i was having problems
with certain frameworks. It is because they hard code a
threading architecture into your apps.
If i want an object to participate in transactions from
multiple threads, hibernate would barf saying an object
can't be in more than one session. Or an AOP approach would
just assume it knew my transaction scope.
That perplexed me until i saw that everything works that
way. It makes some sense as the default mode for
simple web apps.
If i have work to do that i want handle smartly,
you can't use the common frameworks.
Why different threads? Read the SEDA papers for a good
introduction.
It has a lot to do with viewing your application performance
as a whole, instead of a vertical slice in time. With
a multi threaded approach you can create the idea of
quality of service. You can have certain work done at
higher priorities. You can aggregate work together even
though it came in at different times. You can green light
high priority traffic. You can reschedule lower priority
traffic. You can drop duplicate work. You can limit the
CPU usage for work items so you don't starve other work.
You can do lots of things, none of which you can do with a
single task that runs until completion.
|
|
|
Message #140345
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
one thread per request is broken
>don't you break with the common one thread per request > scenario that us developers have come to depend on?
It needs to be broken. Need to be broken aside...
My point was relating to Jetty, the Servlet Container, and its redesign to a selector/event based approach. IMO this will cause a great deal of existing infrastructure to stop working.
I'm asking if this is true, or is there a work-around available?Read the SEDA papers for a good introduction. It has a lot to do with viewing your application performance as a whole, instead of a vertical slice in time. With a multi threaded approach you can create the idea of quality of service. <...snip...> You can do lots of things, none of which you can do with a single task that runs until completion. I have read Matt Welsh's SEDA documents a couple years ago. The concept of stages to perform a discrete task and interconnecting queues to propogate the request from stage to stage. All well and good, but most SEDA-type designs feature non-blocking I/O on the front-end. Not sure where multi-threaded comes into play here, typically these systems will have only one or two threads allocated per CPU.
Hence the question, in an asynchronous I/O implementation of a servlet container, how can frameworks or applications layered on top be able to leverage the ThreadLocal concept that so many of them depend on for basic context propogation?
|
|
|
Message #140354
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
one thread per request is broken
> I'm asking if this is true, or is there a work-around available?
I don't know.
>All well and good, but most SEDA-type designs feature non-blocking I/O on the >front-end. Not sure where multi-threaded comes into play here, typically these >systems will have only one or two threads allocated per CPU.
That doesn't really impact the backend, which is the processing
of the work. SEDA will add threads to stages if it needs to.
That's part of the adaptive part.
>Hence the question, in an asynchronous I/O implementation
>of a servlet container, how can frameworks or applications
>layered on top be able to leverage the ThreadLocal concept
>that so many of them depend on for basic context propogation?
From an app perspective an async IO implementation can
be transparent. You block. I do everything async behind
the scenes. I get a complete response. Give the the result
to you and unblock you. Nothing need change.
|
|
|
Message #140358
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
one thread per request is broken
From an app perspective an async IO implementation can be transparent. You block. I do everything async behind the scenes. I get a complete response. Give the the result to you and unblock you. Nothing need change. I understand what you're saying, but it seems very counterproductive to add NIO to a servlet container like Jetty, when you just have to resort to a thread-per-request blocking IO approach once the full request has been received.
Perhaps Greg can comment, but I would draw the conclusion that the performance impact of a NIO frontend is minimal in a servlet-based application because the thread-per-request paradigm probably still must exist. It's only been pushed back to the handling of the HTTPRequest instead of the socket communication.
|
|
|
Message #140359
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jetty 5 released and potential future mapped out
An easy way to find out is to use jmeter to send a request to a site and look at the raw response and http header. Sometimes .. but the site I'm thinking of re-writes those headers (actually, it strips them) to hide its implementation details. Other sites have apache (etc.) in front, but the content comes from a servlet container, so you cannot tell from "outside".
Peace,
Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters
|
|
|
Message #140365
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
one thread per request is broken
>I understand what you're saying, but it seems very
>counterproductive to add NIO to a servlet container
>like Jetty, when you just have to resort to a
>thread-per-request blocking IO approach once the full
>request has been received.
I guess it is an appliction stack.
You are still getting a win because jetty is more capable.
If you could extend that model all the way down into the apps then
their would be some win. But such a radical
change in application architecture makes it impossibile.
|
|
|
Message #140372
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jetty 5 released and potential future mapped out
An easy way to find out is to use jmeter to send a request to a site and look at the raw response and http header. Sometimes .. but the site I'm thinking of re-writes those headers (actually, it strips them) to hide its implementation details. Other sites have apache (etc.) in front, but the content comes from a servlet container, so you cannot tell from "outside".Peace,Cameron PurdyTangosol, Inc.Coherence: Shared Memories for J2EE Clusters
hehe, it's funny you mention that. I've had several people ask me, "how can we hide the fact we're using server X?" I've definitely come across the situation you describe where someone puts Apache infront to hide things, or use router to hide which server they're using.
when ever I see some one do that, I have to laugh. just because site X uses server X, doesn't someone else can magically achieve the same level of service. it's as if, server X is the secret sauce to great performance. Back in 99, a co-worker attended a talk given by one of the architects of MP3.com before they sold out. He took good notes and gave us a detailed summary of the talk. Although they were using apache, mysql and other OSS technologies, it was how they applied the technology that allowed them to scale rapidly and maintain fast response times.
|
|
|
Message #140379
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
one thread per request is broken
>I understand what you're saying, but it seems very >counterproductive to add NIO to a servlet container >like Jetty, when you just have to resort to a >thread-per-request blocking IO approach once the full >request has been received.I guess it is an appliction stack. You are still getting a win because jetty is more capable. If you could extend that model all the way down into the apps then their would be some win. But such a radical change in application architecture makes it impossibile. interesting discussion. my bias take on it is once the performance requirements increases dramatically, the best option might be to re-architect the performance sensitive pieces. If the problem is such that scaling horizontally is a real option, then whether or not a servlet container multi-plexes the network IO with NIO and events probably isn't going to be a huge win. At a previous job, we wrote a local cache for a well known servlet container, because the data changes once a month.
In cases like these, the benefit of breaking request parsing, data queries, page generation and writing the response into separate stages like SEDA definitely will scale better than a single threaded approach. A good example of this would be the /. effect when several thousand concurrent requests hits a small cluster of webservers. I think Matt Welsh had a good write up about this specific scenario for one of the talks he gave.
I've seen other people tackle this specific type of problem by building a system which periodically generate/re-generate the pages as static content. MP3.com used a similar approach, and wrote some custom scripts to propagate data from the main database out to the webservers. Of course this approach doesn't work for highly dynamic pages that are specific to a user and their context. Breaking an existing app that uses ThreadLocal is a tough call, but I don't see that as a Jetty problem. In my mind, each user has to make that decision and weigh the costs.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
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)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
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)
|
|
