[wildfly-dev] question 2 sec boot time of WISE

[Brian Stansberry]

Jason, I’m going to cut-and-paste parts of your post and respond to them that way as it helps me have a logical flow.

> For example the GWT app could be mostly client side, with no GWT-RPC

That part is still involves a deployment though, right? Even if it’s just like HAL and just static files, making it downloadable means either a deployment or some custom integration into the undertow subsystem. The alternative is to make it a special context on the management http interace like we do for the HAL console. Or one way or the other make it part of HAL. But my impression of this app is despite the bit of integration into HAL, it’s not really a “management” app and is meant to be usable outside of HAL. A "dev-ops" admin may use it, hence the integration with HAL, or a “dev" may use it, but a classic “ops” admin is not going to use it and we don’t want to force the “dev” user to be given admin permissions in order to use it.

If the downloadable part is a deployment but also an patchable official part of the software we for sure don’t want it deployed via the deployments/ folder.

> 
> 2) The deployment being listed in the user’s view of deployments, which is only supposed to represent what the user interacts with

Agreed. If we keep it as a deployment installed by a subsystem we need a proper notion of a system-deployment or something like that. Roughly

a) separate tree in the management model; looks like the deployment tree in terms of child resources, e.g. /sysystem-deployment=foo.war/subsystem=undertow etc but it’s not mixed in with the normal deployments
b) Any API to add/remove/deploy/undeploy is private, not published in the read-resource-description output. Meant for internal use.
c) Handled in terms of deployment processing like a normal deployment, but the DeploymentUnit has a flag or attachment so DUPs can know it’s a system deployment. So, for example we don’t complain about use of private/unsupported/deprecated modules. The first integration of wise resulted in a bunch of log warns that for sure would need to be made to go away.

> 
> 1) EJB is required, but there is likely no error indicating that EJB isn’t present, the annotated class will just be ignored.

This can be mitigated with good use of capabilities and requirements; the resource that makes something available is a capability and it requires other things it needs.

I say “mitigated” not “solved” because it’s still possible that the detailed configs of required capabilitiles would not be compatible with the deployment’s needs.

> 
> 3) A mandatory port hand-off in the UI flow

Yeah, that’s kind of ugly. I think it’s the result of trying to integrate a more “dev” tool into a more “admin” tool.

> On Aug 31, 2016, at 1:51 PM, Jason Greene <jason.greene at redhat.com> wrote:
> 
> 
>> On Aug 30, 2016, at 11:15 AM, Rebecca Searls <rsearls at redhat.com> wrote:
>> 
>> 
>> Wise was pulled from wfly because it was adding 2 sec to boot time.  
>> Wise is a utility with a GWT interface.  It was added to wfly as an extension.  
>> It is provided as a WAR file.
>> 
>> Is there any more detail of the boot of this app?
> 
> Right, so the big issue is we have had a long standing policy to:
> 
> a) Avoid adding any significant time to boot, as that was a major goal of AS7+
> b) To not include shipped app server functionality in deployments. This is partly because of (a), since scanning and discovery and deployment chain processing has a cost that is unnecessary for code that is part of the server itself. However, it’s also because solutions that require deployments limit the integration quality of the system. 
> 
> Some examples of (b) include
> 
> 1) EJB is required, but there is likely no error indicating that EJB isn’t present, the annotated class will just be ignored.
> 
> 2) The deployment being listed in the user’s view of deployments, which is only supposed to represent what the user interacts with
> 
> 3) A mandatory port hand-off in the UI flow
> 
>> 
>> 
>> Here are a few options we have thought of.  
>> What would be the best way to address this so that the user can have access to this tool?
>> 
> 
> Another option to throw out there, is we could keep this as-is and put it into wildfly-extras.
> 
>> 1. lazy deployment of the utility
> 
> What did you have in mind? This sounds tricky. You could perhaps have the subsystem register an http handler that dynamically installs the server, but if you are going that far it’s best to just register the components directly as part of the subsystem than in a deployment.
> 
>> 2. Only provide it in standalone-full.xml
> 
> That would add 63% to the boot time so not really a good option.
> 
>> 3. Handle it the way xts subsystem was with a standalone-xis conf
> 
> That might be acceptable.
> 
> However, is there a reason it’s a deployment in the first place? I mean I can understand keeping it as a deployment to decouple it from the server, but once you are making it part of the server itself, why not integrate it that way. For example the GWT app could be mostly client side, with no GWT-RPC, and the backend debugging facilities could be extra components registered during web service deployment.
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat