[GLASSFISH-18633] Sniffers are getting loaded early Created: 16/Apr/12  Updated: 08/Mar/13  Resolved: 08/Mar/13

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 4.0_b32_ms1
Fix Version/s: 4.0_b80_EE7MS6

Type: Bug Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: Hong Zhang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: devx_web, spo

 Description   

I don't see any reason for this class to exist. We should defer initialization of sniffers to first application deployment.
/**

  • Optimization to force the loading of sniffers post deployment.
  • Sniffers can be slow to load and should not delay server statup when
  • no application is deployed.
    *
    */
    @Service
    @PostStartupRunLevel
    public class PostInitializer implements PostConstruct {

@Inject
SnifferManager sniffers;

public void postConstruct()

{ sniffers.getCompositeSniffers(); sniffers.getSniffers(); }

}



 Comments   
Comment by Hong Zhang [ 17/Apr/12 ]

From the svn log message, Jerome added this for performance improvement? Is this no longer applicable in the current code?

r32996 | dochez | 2009-10-20 13:06:15 -0400 (Tue, 20 Oct 2009) | 7 lines

Deployment performance improvement by reducing the sniffer loading time (reducin
g the imported bundle list)
moved WebServicesSniffer to a new module to avoid resolving the entire web servi
ces stack for any deployment
IT 10256 : hk2 lookup used on invocation path (reviewed by Ken Saks)
IT 10069 : incremental fix for app name registration in embedded mode
turned off autodeploy in embedded mode by default.

Comment by Sanjeeb Sahoo [ 18/Apr/12 ]

I can't see that improving performance except for first deployment. Instead of loading during first deployment, we are loading early defeating lazy initialization. So, pl. remove it.

Comment by Hong Zhang [ 08/Mar/13 ]

Remove PostInitializer as sugguested (checked with Scott/Tom also).

Generated at Wed May 27 07:02:38 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.