Surya Suravarapu's Blog

Ramblings on software and stuff related

Posts Tagged Java

JavaOne 2010 – My Impressions (Part 1)

Sep 29

Posted by Surya Suravarapu in General | 1 Comment

Bad

Let's start with the bad and everything else would be an improvement when compared with that. Yes, food at the conference is awful. I thought that's only me who is looking out for vegetarian options, but apparently many people I knew who eat mostly anything under the Sun (no disrespect) are also equally disappointed. There is a huge scope for improvement in this area.

Some other aspects that need some attention -- it was a huge effort for the first couple of days to find the right conference room in Hilton and in Parc55; folks sitting towards the back couldn't see the slides that well because of the placement of the screen and projector; Poor wifi, worked intermittently. I hope Oracle considers moving Java One to Mascone in the future.

Good

Now that we put the worst behind us I will go to the other extreme and explain what's the best. Yes, there are some good sessions that I attended which I will go over in a minute. But the best part is meeting people and exchanging ideas. I got an opportunity to meet a whole lot of people I know for a while, worked with them online or exchanged tweets but got a chance to meetup for the first time. What more? I have even found a childhood friend whom I lost contact for the last few years!

Sessions

I will summarize some of the sessions that I liked at the conference (and skipping the ones that didn't appeal to me much):

Script Bowl 2010: A Scripting Languages Shootout

Clojure, Groovy, JRuby and Scala are the contending languages this time. They were presented by Rich Hickey, Graeme Rocher, Nick Sieger and Dick Wall respectively. Roberto Chinnici of Oracle acted as a judge/coordinator. Two rounds of presentations took place -- first round dealing with the language features and the second one presenting community features. Liked what I saw about Spock.

It was all in a rapid fire mode as the time allotted is only one hour. I was actually thinking that to be a competition where a specific problem or two would be assigned to each person representing the language and then evaluate how each language approaches the problem. But apparently that's not the case.

The winner was announced based on the audience applause at the end, just for fun, I guess. Groovy topped followed by Scala as a close second.

Advanced Java API for RESTful Web Services (JAX-RS)

Paul Sandoz and Paul Chinnici started off with an overview of JAX-RS -- going over basic annotations (@Path, @Produces, etc.). Runtime resource resolution was dealt with in good detail. Middle part of the presentation was over integrating JAX-RS with EJBs and CDI (Yawn! I'm not much into it CDI).

Then they woke me up with some good discussion over content negotiation and conditional request support of JAX-RS. JAX-RS has got great content negotiation support covering media type, character set, language, and content encoding. Variant API is nice and flexible.

Equally nice is its support for conditional requests (GETs and PUTs) for caching representations and for concurrency control. They have demoed ETag validation and evaluatePrecondition flow.

"If you think you understand Java Generics than actually you don't understand it!" - a quote from the presenters that drew some laughs. The speakers went over how they had to deal with the type erasure issue and a work around of using GenericEntity to preserve type information at runtime. They finished the presentation discussing the pluggable exception handling mechanism of JAX-RS.

Overall, a nice presentation. I have expected them to discuss hypermedia support in Jersey but because of time constraint they couldn't get to it, as Paul Sandoz suggested after the talk when I asked him about it.

The Next Big Java Virtual Machine Language (NBJL)

Stephen Colebourne of OpenGamma is the speaker of this talk with potential controversy from the title itself. There are a lot of folks who swear by their language of choice, for what its worth, I thought it would be interesting to see what conclusion the presenter would arrive and based on what analysis. (There is also another section of people who completely denounce of the notion of NBJL. They consider polyglot programming is here to stay and there is not going to be one big successor, and you choose a language that best serves your task at hand. Let's leave that view point for another day!).

Colebourne defined what he thinks a next big language would be, one that's widely used (big job market) with supporting ecosystem and community. Examples: C, C++, Java, C#, Cobol, VB, Perl, PHP, Javascript, etc. So NBJL is one that challenges Java and eventually displaces it.

There are a lot of design decisions that were made at various points while Java was evolving. Many of them appeared to be right at that point and only after some experience people started to realize that there are better ways to approach. The speaker went over few items that are sore points in Java and what we have learnt from the real world experiences, from technology advancements, and from the other new breed of languages. Colebourne went over checked exceptions, primitives, arrays, 'everything is a monitor' concept, static methods, method overloading, and generics as some areas where NBJL could provide some solid alternatives.

Colebourne presented what can Java do to evolve still maintaining the "feel of Java". Bigger challenges for Java at this point are supporting -- Properties, Continuations, Control abstraction, Traits, Immutability, Design by Contract, and Reified generics. Another important point the speaker made was that the NBJL should be a "blue collar" language, a language of the masses. An average developer should be able to pick it up rather quickly and be productive in a reasonable time frame.

Towards that end the presenter looked at various languages: Clojure, Groovy, Scala, Fantom and discarded every one of them with some justification. Here is where it gets interesting. He concludes with a thought may be that Java should come up with a backward incompatible version and fix its warts. Regardless of how you respond to the concluding thought it was an excellent presentation overall covering a wide spectrum of concepts. If you are interested to hear from the presenter himself check this out.

NoSQL Alternatives: Principles and Patterns for Building Scalable Applications

Nati Shalom of GigaSpaces presented data scalability patterns that emerged out of various NoSQL projects. He compared the new breed of technology against the traditional database scaling approach in terms of consistency, transaction and query semantics.

Some of the factors that are affecting the scalability needs -- social networks changed the web experience in the recent years. Read-mostly applications transformed into read/write and mostly predictable traffic has become a viral one with huge spikes at certain time intervals triggered by the events. SaaS model and cloud is mentioned as a factor. The speaker suggests that the economic downturn has forced the corporates to work efficiently, and no more that throwing more expensive hardware at the problem is an appealing solution.

Another factor that the speaker suggested was that the disk failures are up and lot higher than what are actually reported by the vendors (3% actual vs 0.5% reported). With the advancements in technology memory can be 100 - 1000x more efficient than the disk. RAMClouds become much more attractive for applications with high throughput requirements. New hardware makes it possible to store the entire set of data in-memory.

The presenter went over various alternatives: In-memory (GigaSpaces), Key/Value. Column (BigTable, HBase), Document model (CouchDB), Graph (Neo4J).  Shalom discussed common principles behind the NoSQL alternatives like - design for failure;  scale through partitioning of the data; maintain reliability through replication; provide flexibility between consistency, availability and partition failure; dynamic scaling. Some other principles (not so common) discussed are - document model support, SQL query support, MapReduce, transaction management, and security.

To be continued ...

See here for part 2 of the series.

Tags: , , ,

Java’s HTTP Handler and Cache Validation Issues

Oct 8

Posted by Surya Suravarapu in Caching, Java, REST | 6 Comments

Background

A little while ago I've mentioned that I was working on client-side HTTP caching (using Ehcache) for REST clients. After a little hiatus, I'm back to complete the unfinished business, precisely dealing with cache validation support (using ETag, Last-Modified, If-None-Match, If-Modified-Since headers). I've also explained the approach I was taking to implement the solution, using Java's ResponseCache mechanism.

However, I think I've hit a dead end implementing the solution using that approach. I will try to explain it here and hope that smarter people out there provide their thoughts.

Overview

Let's start with a simple straightforward scenario. Quick control flow of the Java protocol handler approach:

  1. A client application gets an instance of sun.net.www.protocol.http.HttpUrlConnection, which extends java.net.HttpUrlConnection, via url.openConnection(). This hanlder instantiates a registered instance of java.net.ResponseCache, if there is one available.
  2. When a request is sent to the server via HttpUrlConnection, protocol handler first checks whether the representation is present in the cache by calling the get() method of the ResponseCache. If it is in the cache send it to the client, else send the request to the origin server.
  3. If the request is sent to the origin server, and if the response is any of 200, 301, or other "cache-able" statuses, the handler then calls the put() method of the ResponseCache to potentially cache the representation.
  4. ResponseCache would store the element in the cache. It uses Expires, Date, Cache-Control headers to determine time to live and set it on the element. Let's ignore expiration model for this post as the focus is on validation.

Note: You have to write your own concrete implementation for ResponseCache to store and retrieve elements from the cache. Java doesn't provide an out-of-the-box implementation for it, but it provides a framework for doing so.

Validating Cached Element

Now let’s look at a scenario that does cache validation. First, what is validation? There are two headers a server may send for validating the resource: a timestamp (Last-Modified) indicating when the resource was last changed, and an entity tag value (ETag). Server may choose to send only one of these headers, as both of them try to achieve the same purpose.

Responding to a request for resource X, a server sends along one or both these headers to the client along with X’s representation. On any subsequent request for resource X -- the client may honor these response headers, and sends two of its own headers: If-Modified-Since (with the value of the Last-Modified header) and If-None-Match (with the value of ETag header). Former requests the server to send the representation only if the resource is modified since the Last-Modified time it has got, and the latter asks to send the representation only on the change of ETag value that it supplied.

If there is a change in the resource, a server sends an updated representation, with new values for ETag and/or Last-Modified headers. This scenario works fine with no issues as you get a 200 response back, and the protocol handler handles this just fine (similar to the straightforward scenario mentioned above). The issue that I'm going to mention is with the case in which the server determines that there is no change with the resource, and sends back a status 304, NOT MODIFIED, with no body in the content.

See the following sequence of events that end up with a status code 304 from the server (click on the image to enlarge):

Conditional GET

Issues with Java's HTTP Handler

  • A client or client-side cache should first check whether a cached representation is available before sending a conditional GET of this sort. (There is no point sending Not-Modified-Since and/or If-None-Match headers if it doesn’t have a representation to fall back on). Java’s cache handler framework using HttpUrlConnection does not provide an option to do so.Let's see the relevant source code of sun.net.www.protocol.http.HttpUrlConnection, lines 399-410: 
    // Set modified since if necessary
long modTime = getIfModifiedSince();
if (modTime != 0) {
    Date date = new Date(modTime);
    //use the preferred date format according to RFC 2068(HTTP1.1),
    // RFC 822 and RFC 1123
    SimpleDateFormat fo = new SimpleDateFormat(
        "EEE, dd MMM yyyy HH:mm:ss 'GMT'", Locale.US);
    fo.setTimeZone(TimeZone.getTimeZone("GMT"));
    requests.setIfNotSet("If-Modified-Since", fo
        .format(date));
}

    The above block of code adds If-Modified-Since header but makes no checks whatsoever whether the representation is available in the cache.

  • I don't see a reference to If-None-Match header in the source. So if the client sends that header, it will be sent to the origin server without an availability check
  • In case, if there is no representation in the cache, the cache must have an ability to remove the validation headers from the request before sending the request to the origin server. I don't see this framework supporting such a behavior.

Thoughts??

// Set modified since if necessary
0400:                    long modTime = getIfModifiedSince();
0401:                    if (modTime != 0) {
0402:                        Date date = new Date(modTime);
0403:                        //use the preferred date format according to RFC 2068(HTTP1.1),
0404:                        // RFC 822 and RFC 1123
0405:                        SimpleDateFormat fo = new SimpleDateFormat(
0406:                                "EEE, dd MMM yyyy HH:mm:ss 'GMT'", Locale.US);
0407:                        fo.setTimeZone(TimeZone.getTimeZone("GMT"));
0408:                        requests.setIfNotSet("If-Modified-Since", fo
0409:                                .format(date));
0410:                    }

Tags: , ,

Thoughts on Class Reloading and JavaRebel

Jun 25

Posted by Surya Suravarapu in JavaUserGroup | 7 Comments

A couple of days ago, I've attended Philly JUG for a talk titled Non-stop Java Development, presented by Ivo Magi of Zero Turnaround. The focus was on their product JavaRebel and how it can speed up development by cutting down on deployment time and on server restarts.

So what problem is JavaRebel trying to solve?  When you make code changes in the application you go through the usual cycle of:

{make-a-change} -> {waitFor: build-deploy-serverRestart} -> {check-the-change}.

JavaRebel claims to eliminate the second step of waiting for build/deploy and the need for restarting application server for the code changes to take affect.

No need to mention that I'm a big fan of open source model, JavaRebel is not in that category, it is a commercial tool. The presenter discussed about the available non-commercial options and why this product is better than the existing tools. As far as the available options (or approaches) there are two major ones -- hot deploy and hot swap.

Hot deployment: When a class is changed build-deploy takes place without a need for a container restart. My experience with this so far has resulted in varied degrees of success. It works fine for a few times but had to restart the container/server after a few changes. (I also don't have enough confidence that it can work effectively in a clustered production environment, but that is not the concentration of this post, it is the development time and how to minimize the wait time). OSGi approach is perhaps very similar to hot deploy except that it works at granular level on individual bundles, as opposed to updating the entire application.

Hot swap: An ability to change the class while a JVM is running, without the application ever noticing that. This is useful for the quick reload of classes during the debug time. If you change some functionality in the existing methods that works fine, but if you add a new method to a class or if you add a new class the changes are not detected.

Another option is that you may try your luck with some class loader hacks -- loading the changed class in a different class loader, etc. I never tried it. Again, if anybody used this approach successfully please provide your comments. There are a few frameworks that were mentioned in the presentation that use this approach, I can only remember Tapestry at the moment.

As far as JavaRebel goes it extends the hot swap functionality.  It is implemeted as a JVM plugin (-javaagent). In simple terms an agent in JVM works like an interceptor in front of your main method. The -javaagent command line option is used to register custom instrumentation plugins. What I understood from the talk is that JavaRebel works at the class loader level, it doesn't create new ones but extend the functionality of the existing class loaders.

Saving the application state after class reloads saves quite a bit of time, especially if you are working on a work flow kind of application and you are testing some step 8 of 10.  You can continue your test from where you stopped and doesn't have to go back to step 1.

JavaRebel also seems to have some plugins to support popular web frameworks. I remember Spring, Guice and Struts were mentioned.

Obviously, I haven't tried the tool so I can not make any recommendations. Try it for yourself and see if it suits your needs.

Tags: ,

HTTP Response Cache Mechanism in Java

Apr 15

Posted by Surya Suravarapu in Caching, Java | Comments off

One of the tasks that I'm currently working on (albeit at a pace not to my liking) is to add a HTTP response cache implementation in ehcache's web module. This will be particularly useful for REST-based clients to optionally cache the responses of the GET requests.

Java has got a built-in mechanism for response caching. This was introduced in Java 5 by adding three abstract classes in java.net package: ResponseCache, CacheRequest, CacheResponse. You need to extend these classes for your own cache implementation.

The flow of events is something like the following:

  • A concrete class of ResponseCache registers with the system by using the static method ResponseCache.setDefault(ResponseCache).
  • There are two methods in the ResponseCache that are invoked by the protocol handlers. get() returns a CacheResponse and put() returns a CacheRequest.
  • When you create a URLConnection and attempt to read content the appropriate stream handler is created and it checks for the content in the cache by invoking ResponseCache.get().
  • If the content is found in the cache, it is returned. Otherwise a request is sent to the origin server, the received response is then passed on to ResponseCache.put() to see if the content is cacheable (based on the response headers) and possiblly store it in the cache.

Bulk of the work of cache-ability determination, placing the resource content in the cache, evicting the content based on the Expires or Date headers, and retrieving the resource will be done by your own cache implementation. Here is where I will be spending bulk of my time satisfying the intricacies of RFC-2616 (Chapter 13) that deals with Caching in HTTP.

This implementation works only for the clients using URLConnection to connect, as Java's response cache mechanism described above works only for URLConnection. But once a pattern is set hopefully we can extend or write adapters for the clients using other mechanisms like Apache Common's HttpClient.

Hope to elaborate more on this soon ...

Tags: ,