users@jersey.java.net

Re: [Jersey] Looking for "best practices"

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 19 Jan 2010 13:25:32 +0000

On Jan 19, 2010, at 12:18 PM, Felipe Gaúcho wrote:

> Against DoS you should use an apache as entry point to your
> application..
>
> these read-only resources should be cached in the client side, never
> in the server side.. (unles operations to retrieve them are really
> heavyweight, then you have other problems than your http layer....)
>

Think of 10000 clients accessing the same resource. It makes a lot of
sense in this scenario to cache closer to the server to avoid
reproduce the work 10000 times.

There are no definitive rules here. It depends on the application.

Paul.

> On Tue, Jan 19, 2010 at 12:41 PM, Casper Bang
> <casper.bang_at_gmail.com> wrote:
>> Could you expand on that a little and perhaps provide a reference?
>> I can
>> not remember having met such guidelines anywhere.
>>
>> I use ehcache (specifically a subclass of
>> SimpleCachingHeadersPageCachingFilter) with a short lifespan in
>> order to
>> transparently cache responses from read-only resources. It not only
>> improves performance, but also would appear to add a certain level of
>> security against DoS.
>>
>> /Casper
>>
>> Felipe Gaúcho wrote:
>>> humm.. no problem to cache server resources (memcache) for
>>> performance
>>> reasons.. and other tricks...., but just keep in mind that in REST
>>> you
>>> should never cache "http responses payload" in the server
>>> side.... it
>>> always should be cached in the client side (one of principles of
>>> rest).....
>>>
>>>
>>> On Tue, Jan 19, 2010 at 12:07 PM, Paul Sandoz
>>> <Paul.Sandoz_at_sun.com> wrote:
>>>
>>>> On Jan 14, 2010, at 3:16 PM, Comerford, Sean wrote:
>>>>
>>>> So I’m slowly working through a prototype application and have a
>>>> couple of
>>>> high level newbie questions.
>>>>
>>>> Q1) How to best provide a “light” XML/JSON feed?
>>>>
>>>> Initial testing has shown that (due to performance
>>>> considerations) I need to
>>>> slim down the markup I’m outputting. Un/marshalling costs are
>>>> just too high
>>>> if I output all the fields we have in our POJOs.
>>>>
>>>> I can easily accomplish that by marking a lot of stuff
>>>> @XmlTransient so it’s
>>>> omitted.
>>>>
>>>> But the problem with that is there are SOME cases where I really
>>>> do need
>>>> want those fields in the markup.
>>>>
>>>> So what I’m looking to do is develop a “light” and “full” version
>>>> of my
>>>> output. Short of basic coding conventions (i.e. gving multiple
>>>> classes
>>>> representing the same underlying data but with differing JAXB
>>>> annotations),
>>>> does jersey or JAXB provide anything in this respect?
>>>>
>>>>
>>>> No, currently the application developer has to do that when using
>>>> JAXB.
>>>>
>>>> Creating resource “views” is one possible solution I guess but
>>>> I’m not sure
>>>> that feels right and it certainly loses some of the “automagic”
>>>> benefit of
>>>> the Jersey+JAXB framework but perhaps I’m missing something.
>>>>
>>>> Q2) Controlling the Jersey life cycle... I could have sworn I saw
>>>> an example
>>>> of this but can’t seem to find now. Let’s say for the sake of
>>>> argument I
>>>> want to marshal my Java objects to XML myself (maybe to cache the
>>>> JAXB
>>>> generated markup) and have my @GET method return that instead of
>>>> a JAXB
>>>> annotated POJO instance.... How do I do that / can someone point
>>>> me to an
>>>> example?
>>>>
>>>>
>>>> You could make the resource class a singleton and cache in a
>>>> field of byte[]
>>>> of the serialization on the first request.
>>>> @Singleton
>>>> public class MyResource {
>>>> byte[] xyz;
>>>> @GET
>>>> public byte[] get() {
>>>> synchronized(this) {
>>>> if (xyz == null) {
>>>> // cache
>>>> }
>>>> return xyz;
>>>> }
>>>> }
>>>> }
>>>>
>>>> I think there may be more general solutions using etags and
>>>> ehcache or using
>>>> a web proxy with appropriate cache-control headers.
>>>> Paul.
>>>>
>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>
>
>
> --
> ------------------------------------------
> Felipe Gaúcho
> 10+ Java Programmer
> CEJUG Senior Advisor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>