[undertow-dev] Undertow development mode

Jason Greene jason.greene at redhat.com
Wed Jul 31 10:32:27 EDT 2013 

On Jul 31, 2013, at 9:17 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

> 
> 
>> 
>> I am really not a fan of this big global switch idea.
>> 
>> First off, a number of things that people enabled with "development" mode
>> should just work. For example, jsp redeployment should work in either case.
> 
> The problem is that this is slow, checking timestamps on files is a relatively expensive operation. Considering that the majority of people will not want to change JSP files in production it does not seem like a good idea to make them pay the performance cost. 

It's the same problem we have with file system deployment. We can just have a low priority background thread and it's only needed if its an exploded deployment. The cost is minimal.

> 
>> Being able to recycle sessions is actually useful in production as well.
> 
> I disagree. In production you would want to use infinispan clustering, or session passivation to offload sessions to disk when you have a lot of sessions. I do not think there would be much  demand for saving sessions across a single server restart (for one thing your site will be down while the restart is happening). 
> 
> The idea of this is to provide a simple, easy to use 'best effort' session persistence, for production grade session persistence customers should be using infinispan. 

If you need to perform simple maintenance (e.g you just installed a hot security fix), its own thing to display a "Sorry we are performing maintenance for a few minutes" page. It's quite another to do that and toss the user's session.

> 
>> 
>> Second, development will become an excuse to stick slow performing things in
>> it. You combine that with people hard coding the default, and it's not long
>> before benchmarks are comparing different app server's "development mode".
> 
> Development mode is always going to be massively slower. For example when serving straight HTML serving straight from a cache can be several times faster than performing a timestamp check and then serving from the cache. 

This is also something that should be a simple background thread. In production you are going to want to be able to update a static image without bouncing the server.

> 
> I really don't think we will have any issue with people benchmarking development mode, and I would like to think that 99%+ of developers are smart enough to realise that such a benchmark would be useless.  
> 
>> 
>> On the other hand I could totally see a "show stack traces option" or even
>> "extra diagnostics".
> 
> This relies on the user both knowing how to enable these options, and more importantly actually knowing that they are there to be enabled in the first place. With this switch when the user clicks 'start' in JBDS we can make sure they get the best development experience out of the box. 
> 
> Stuart
> 
>> 
>> 
>> On Jul 31, 2013, at 8:27 AM, Stuart Douglas <sdouglas at redhat.com> wrote:
>> 
>>> Maybe the system property thing I suggested earlier would be enough, so
>>> that we can just have in various places subsystems development mode
>>> controlled by the jboss.development.mode system property, defaulting to
>>> false.
>>> 
>>> Stuart
>>> 
>>> 
>>> ----- Original Message -----
>>>> From: "Tomaž Cerar" <tomaz.cerar at gmail.com>
>>>> To: "Pete Muir" <pmuir at redhat.com>
>>>> Cc: undertow-dev at lists.jboss.org, "Max Andersen" <manderse at redhat.com>,
>>>> "Burr Sutter" <bsutter at redhat.com>
>>>> Sent: Wednesday, 31 July, 2013 3:16:30 PM
>>>> Subject: Re: [undertow-dev] Undertow development mode
>>>> 
>>>> We need to add this development flag on higher level then just undertow
>>>> subsystem.
>>>> 
>>>> It should be server-wide configuration.
>>>> this would enable also other subsystems to behave differently, like the
>>>> jsf
>>>> about forcing jsf/facelets development.
>>>> 
>>>> maybe we can add this to top level element of server? aka <server
>>>> xmlns="urn:jboss:domain:2.0" development-mode="true">
>>>> 
>>>> Max for now this is mgmt configuration for servlet-container but we could
>>>> easily set default value to be passed from system property.
>>>> 
>>>> 
>>>> 
>>>> On Wed, Jul 31, 2013 at 2:46 PM, Pete Muir < pmuir at redhat.com > wrote:
>>>> 
>>>> 
>>>> Adding Burr.
>>>> 
>>>> One idea would be to alter the logging config to log DEBUG messages by
>>>> default in this mode?
>>>> 
>>>> On 31 Jul 2013, at 13:12, Max Andersen < manderse at redhat.com > wrote:
>>>> 
>>>>> First off Stuart - can I give you a hug ? This is awesome!
>>>>> 
>>>>> How is this flag set ? it should be do able via a startup flag and not
>>>>> require to invoke some management operation after the startup to be
>>>>> really
>>>>> useful.
>>>>> i.e. --dev command line flag.
>>>>> 
>>>>>> In Wildfly upstream I am introducing a 'development mode' flag (it is
>>>>>> actually in Alpha3 as well, but I am going to change how it is
>>>>>> represented in the model).
>>>>>> Basically the idea with this is that when this flag is set the server
>>>>>> behaves in a way that is much more developer friendly, but is not
>>>>>> suitable for production use. So far the changes are:
>>>>>> 
>>>>>> - Set JSP development mode
>>>>> 
>>>>> Great - so this means Wildfly will recompile .jsp files when changed,
>>>>> correct ? Anything else ?
>>>>> 
>>>>>> - Display stack traces in error pages. We do not do this by default for
>>>>>> security reasons.
>>>>> 
>>>>> Cool.
>>>>> 
>>>>>> - Disable caching so file changes are picked up straight away
>>>>> 
>>>>> Okey - haven't really noticed caching happening in the past though
>>>>> (except
>>>>> when VFS was put in front of seam ear's in AS5 days).
>>>>> 
>>>>>> - Optionally persist session information across redeployments (still
>>>>>> needs
>>>>>> a little bit of work), which should prevent a developer from having to
>>>>>> re-log in every time they redeploy.
>>>>> 
>>>>> AWESOME x infinity!
>>>>>> I was wondering if anyone had any ideas for other features we could add
>>>>>> to
>>>>>> make development easier?
>>>>> 
>>>>> JSF/facelets have a development mode too if I recall? maybe that makes
>>>>> sense too ?
>>>>> 
>>>>> /max
>>>> 
>>>> 
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>> 
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>> 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

More information about the undertow-dev mailing list