NoSQL Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 492 posts at DZone. You can read more from them at their website. View Full User Profile

neo4j Unmanaged Extension: Creating gzipped streamed responses with Jetty

07.10.2013
| 3480 views |
  • submit to reddit

I recently wrote a blog post describing how we created a streamed response and the next thing we wanted to do was gzip the response to shrink it’s size a bit.

A bit of searching led to GZIPContentEncodingFilter popping up a lot of times but this is actually needed for a client processing a gripped response rather than helping us to gzip a response from the server.

I noticed that there was a question about this on the mailing list from about a year ago although Michaelpointed out that the repository has now moved and the example is available here instead.

I adapted the example a bit and ended up with the following lifecycle plugin:

package com.markandjim;
 
public class GZipInitialiser implements SPIPluginLifecycle {
    private WebServer webServer;
 
    @Override
    public Collection<Injectable<?>> start(NeoServer neoServer) {
        webServer = getWebServer(neoServer);
        GzipFilter filter = new GzipFilter();
 
        webServer.addFilter(filter, "/*");
        return Collections.emptyList();
 
    }
 
    private WebServer getWebServer(final NeoServer neoServer) {
        if (neoServer instanceof AbstractNeoServer) {
            return ((AbstractNeoServer) neoServer).getWebServer();
        }
        throw new IllegalArgumentException("expected AbstractNeoServer");
    }
 
    @Override
    public Collection<Injectable<?>> start(GraphDatabaseService graphDatabaseService, Configuration configuration) {
        throw new IllegalAccessError();
    }
 
    @Override
    public void stop() {
 
    }
}

I then added the following line to ‘resources/META-INF/services/org.neo4j.server.plugins.PluginLifecycle:

com.markandjim.GZipInitialiser

After compiling that and deploying the JAR to the ‘plugins’ I tried calling the end point using cURL:

$ curl -H "Accept-Encoding:gzip,deflate" -v  http://localhost:7474/unmanaged/subgraph/1000/1
* About to connect() to localhost port 7474 (#0)
*   Trying ::1...
* Connection refused
*   Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 7474 (#0)
> GET /unmanaged/subgraph/1000/1 HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5
> Host: localhost:7474
> Accept: */*
> Accept-Encoding:gzip,deflate
>
< HTTP/1.1 200 OK
< Content-Type: text/plain
< Access-Control-Allow-Origin: *
< Content-Encoding: gzip
< Transfer-Encoding: chunked
< Server: Jetty(6.1.25)
 
---
 
gibberish!

The GZIPContentEncodingFilter that I mentioned earlier comes in handy if we want to call the end point from a Jersey client:

public class Neo4jJerseyClient {
    public static void main(String[] args) {
        Client client = Client.create();
        client.addFilter(new GZIPContentEncodingFilter(false));
 
        WebResource webResource = client.resource("http://localhost:7474/unmanaged/subgraph/1000/1");
 
        ClientResponse response  = webResource.header("accept-encoding", "gzip,deflate").get(ClientResponse.class);
 
        System.out.println("response = " + response.getEntity(String.class));
    }
}

We could also call it using HTTParty from the land of Ruby:

response = HTTParty.get("http://localhost:7474/unmanaged/subgraph/1000/1", 
  :headers => { 'Accept-Encoding' => 'gzip,deflate' } )
 
p response






Published at DZone with permission of Mark Needham, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)