Hi Paul,
I already disabled WADL that saves a bunch of time at start up. It's
true that start up of app engine is a bit slower in general, if I
compare it to my local dev server. It's at least ~2 secs for the vm to
spin up anyway, but in my case I'm seeing delays up to 15-20 secs
before the request gets served by Jersey at all. Not all of that delay
is caused by Jersey though :)
I also had jersey-json in my path while I don't require it so that
saves some little bit more time, but it would be nice if Jersey would
lazyload those to support the usecase of services that support
multiple representations for example. The first request would only
init what is needed for that request and if later a json request comes
along it could "update" the already warm instance by then and init the
json stuff. I guess this is pretty specific for appengine though (and
the appengine startup isn't a big deal if the app has enough load).
I tried to monkey patch the ServiceFinder already and it seems that
it's not the classpath scanning perse that causes the slower init, but
the amount of classes that are registered. It's hard to determine from
the logs. I didn't notice the api you mention, I'll look in that one
and report back. I'd suspect that hardcoding helps somewhat.
Thanks for the swift reply (despite JavaOne :))
Hugo
On Wed, Sep 22, 2010 at 11:51 PM, Paul Sandoz <Paul.Sandoz_at_oracle.com> wrote:
> Hi Hugo,
>
> On Sep 21, 2010, at 9:04 AM, Hugo Visser wrote:
>
>> Hi,
>>
>> I'm using Jersey (+Guice) in a few webapps on app engine and I love it.
>> The only downside is the initialization time that Jersey needs, around 2
>> seconds on my apps.
>
> Apart from jersey-core, jersey-server and jersey-guice are you using any
> other Jersey jars?
>
> I have heard of similar issues, with other non-Jersey app,s on
> initialization slowness when using GAE.
>
> One thing that might speed things up is disabling WADL generation:
>
> https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/api/core/ResourceConfig.html#FEATURE_DISABLE_WADL
>
> Otherwise it is currently not very easy to isolate or pick and choose the
> "system" components defined by Jersey. This is something i want to tackle in
> the next major release of Jersey.
>
> It is possible to register your own implementation of a service iterator
> provider:
>
> https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/spi/service/ServiceFinder.html#setIteratorProvider%28com.sun.jersey.spi.service.ServiceFinder.ServiceIteratorProvider%29
>
> where you limit the set by hardcoding the set of provider classes
> (registered in META-INF/service) files.
>
> Paul.
>
>> Unlike a normal container app engine instances are spun down once in a
>> while so start up time matters a lot.
>>
>> I noticed that Jersey is doing a lot of discovering and registering of
>> providers, some of which I most likely never use. Is there any way to hook
>> in to this mechanism to reduce the number of components that get registered?
>>
>> What would be the best approach for doing lazy initialization of resources
>> and providers and is this is feasible?
>>
>> Thanks,
>>
>> Hugo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>
>