On 6/25/11 12:52 AM, Jason Lee wrote:
> It seems to me that the issue is with Jersey (and our configuration of
> it) and not with Grizzly, so I'm going to remove the Grizzly dev list
> from this thread before I make another update.
>
We do a
rc.getFeatures().put(ResourceConfig.FEATURE_DISABLE_WADL, Boolean.TRUE);
before the call.
Ludo
> On 6/24/11 5:38 PM, Jason Lee wrote:
>> I've been stepping through the code to see if I can find the hot
>> spot. It seems that this method might be where we're having issues:
>>
>> private void initWadlResource() {
>> if (!wadlFactory.isSupported())
>> return;
>>
>> final PathPattern p = new PathPattern(new
>> PathTemplate("application.wadl"));
>>
>> // If "application.wadl" is already defined to not add the
>> // default WADL resource
>> if (rules.containsKey(p))
>> return;
>>
>> // Configure meta-data
>> wa.initiateResource(WadlResource.class);
>>
>> rules.put(p, new RightHandPathRule(
>>
>> resourceConfig.getFeature(ResourceConfig.FEATURE_REDIRECT),
>> p.getTemplate().endsWithSlash(),
>> new ResourceClassRule(p.getTemplate(),
>> WadlResource.class)));
>> }
>>
>> I believe we have disabled WADL generation (Ludo can give the details
>> here), so it seems we shouldn't be running this method. Is there a
>> way we can avoid this method call? At they very least, should be look
>> at wadlFactory? Perhaps overriding it or somehow causing
>> isSupported() to return false?
>>
>> On 6/24/11 3:26 PM, Jason Lee wrote:
>>> The REST team is trying to track down the cause of slow startup
>>> performance. In looking at timings, the most expensive operation is
>>> this one:
>>>
>>> ClassLoader originalContextClassLoader =
>>> Thread.currentThread().getContextClassLoader();
>>> try {
>>> ClassLoader apiClassLoader = sc.getCommonClassLoader();
>>>
>>> Thread.currentThread().setContextClassLoader(apiClassLoader);
>>> httpHandler =
>>> ContainerFactory.createContainer(HttpHandler.class, rc); // <-- Here
>>> } finally {
>>>
>>> Thread.currentThread().setContextClassLoader(originalContextClassLoader);
>>> }
>>>
>>> where sc is the ServerContext.
>>>
>>> What we'd like some help on is determining why the call to
>>> createContainer() takes so long (about 6 seconds). Is there any
>>> sort of guidance you guys can offer us? Can you take a look at your
>>> respective pieces in this operation and see if there's anything that
>>> stands out as a hot spot? I know that's kind of vague, but that's
>>> all I know to ask at this point. Hopefully, my questioning will
>>> become more specific as the discussion progresses. :)
>>>
>>> Thanks!
>>>
>>> Jason Lee
>>
>