Live reload in production?

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Live reload in production?

Adam Zimowski
> What I think should be discussed is what's the best default value for it: enabled or disabled?

That, to us makes no difference, as long as the option is there in 5.3 :-)

On Wed, Apr 20, 2011 at 12:11 PM, Thiago H. de Paula Figueiredo
<[hidden email]> wrote:

> On Wed, 20 Apr 2011 13:32:17 -0300, Mark <[hidden email]> wrote:
>
>> I understand the problems with giving people too many options.
>> However it can be really tricky to decide what should be configurable
>> and what need to be fixed.  I wouldn't want to use a word processor
>> that only allowed me to type in Times Roman because that was the only
>> font the developers used and they didn't see any reason others would
>> need to use anything different.
>
> Agreed. This is an option that is important for Tapestry users. What I think
> should be discussed is what's the best default value for it: enabled or
> disabled?
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
> instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Live reload in production?

lltyk
In reply to this post by Thiago H de Paula Figueiredo
Disabled, so you automatically get better performance. I don't think you
should have to tweak Tapestry options to get better performance.

--
View this message in context: http://tapestry-users.832.n2.nabble.com/Live-reload-in-production-tp6288037p6291747.html
Sent from the Tapestry Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Live reload in production?

Thiago H de Paula Figueiredo
On Wed, 20 Apr 2011 15:21:10 -0300, LLTYK <[hidden email]> wrote:

> Disabled, so you automatically get better performance. I don't think you
> should have to tweak Tapestry options to get better performance.

Good point. But a similar argument can be used: enabled, so you get a  
faster development environment without tweaking options. My gosh, these  
decisions are hard. :)

--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Live reload in production?

Mark
> Good point. But a similar argument can be used: enabled, so you get a faster
> development environment without tweaking options. My gosh, these decisions
> are hard. :)

Couldn't it be enabled by default in development mode and disabled by
default in production mode? Isn't that how HTTPS and some other things
are handled?

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Live reload in production?

Kalle Korhonen-2
In reply to this post by Thiago H de Paula Figueiredo
On Wed, Apr 20, 2011 at 10:03 PM, Thiago H. de Paula Figueiredo
<[hidden email]> wrote:
> On Wed, 20 Apr 2011 15:21:10 -0300, LLTYK <[hidden email]> wrote:
>> Disabled, so you automatically get better performance. I don't think you
>> should have to tweak Tapestry options to get better performance.
> Good point. But a similar argument can be used: enabled, so you get a faster
> development environment without tweaking options. My gosh, these decisions
> are hard. :)

Everybody wants better performance but only certain group of users
want/need reloading in production. For the whole discussion -
personally I think live reloading is the wrong way to solve the
application upgrade / patching problem, you give up too much for the
benefit. I've been doing skinny wars, deploying dependent libs
separately and auto-reloading of the web app for a few years, to
achieve production deployment and updates in less than two seconds.
Together with Tomcat 7's parallel deployment, you get a nice zero
downtime environment.

Kalle

>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
> instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Live reload in production?

Howard Lewis Ship
In reply to this post by Mark
On Wed, Apr 20, 2011 at 12:37 PM, Mark <[hidden email]> wrote:
>> Good point. But a similar argument can be used: enabled, so you get a faster
>> development environment without tweaking options. My gosh, these decisions
>> are hard. :)
>
> Couldn't it be enabled by default in development mode and disabled by
> default in production mode? Isn't that how HTTPS and some other things
> are handled?
>

That's my intention.  Live class reloading would be disabled in
production, and enable in development.

> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



--
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Live reload in production?

Nikla
In reply to this post by Kalle Korhonen-2

Hi,

In a busy live environment I would prefer disabled by default
but still doable programmatically for occasional critical patching.
This would allow reloading to be hooked for example to some
administrative web service and result in better atomicity if multiple
files need to be patched.

That said, I currently deploy entire app most of the times.

Cheers,
--Nikla


On 20.4.2011 22:43, Kalle Korhonen wrote:

> On Wed, Apr 20, 2011 at 10:03 PM, Thiago H. de Paula Figueiredo
> <[hidden email]>  wrote:
>> On Wed, 20 Apr 2011 15:21:10 -0300, LLTYK<[hidden email]>  wrote:
>>> Disabled, so you automatically get better performance. I don't think you
>>> should have to tweak Tapestry options to get better performance.
>> Good point. But a similar argument can be used: enabled, so you get a faster
>> development environment without tweaking options. My gosh, these decisions
>> are hard. :)
> Everybody wants better performance but only certain group of users
> want/need reloading in production. For the whole discussion -
> personally I think live reloading is the wrong way to solve the
> application upgrade / patching problem, you give up too much for the
> benefit. I've been doing skinny wars, deploying dependent libs
> separately and auto-reloading of the web app for a few years, to
> achieve production deployment and updates in less than two seconds.
> Together with Tomcat 7's parallel deployment, you get a nice zero
> downtime environment.
>
> Kalle
>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
>> instructor
>> Owner, Ars Machina Tecnologia da Informação Ltda.
>> http://www.arsmachina.com.br
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Live reload in production?

Michał Gruca
In reply to this post by Thiago H de Paula Figueiredo
my $0.02. If it was enabled till today then we should leave it that way.
In documentation there should be note that it is possible to speed up
significantly application by doing something and with cost of no live class
reloads in production.


Regards,
Michal

--
View this message in context: http://tapestry-users.832.n2.nabble.com/Live-reload-in-production-tp6288037p6293772.html
Sent from the Tapestry Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Live reload in production?

Mark
In reply to this post by Howard Lewis Ship
On Wed, Apr 20, 2011 at 4:07 PM, Howard Lewis Ship <[hidden email]> wrote:

> That's my intention.  Live class reloading would be disabled in
> production, and enable in development.
>
>
I think that is reasonable, but I think it should be treated similar to
tapestry.secure-enabled.  By default it is off in development and on in
production, but you can override it to turn it on if you need to use
security in development mode. That way the majority of users can benefit
from sensible defaults while allowing the flexibility for people who need
it.

I think this type of approach is ideal for handling the paradox of choice
issue--particularly in programming frameworks.  It keeps things simple for
the majority of users, but flexible for people whose needs are a bit
different.

Mark
Reply | Threaded
Open this post in threaded view
|

Re: Live reload in production?

Vangel V. Ajanovski
In reply to this post by Thiago H de Paula Figueiredo
On 20.04.2011 21:03, Thiago H. de Paula Figueiredo wrote:
> On Wed, 20 Apr 2011 15:21:10 -0300, LLTYK <[hidden email]> wrote:
>
>> Disabled, so you automatically get better performance. I don't think you
>> should have to tweak Tapestry options to get better performance.
>
> Good point. But a similar argument can be used: enabled, so you get a
> faster development environment without tweaking options. My gosh,
> these decisions are hard. :)

I would like to know what is truly the nature of the problem with live
reload (besides possibility to get the application in an inconsistent
state of which every developer is aware).

What is the range of the performance penalty? 0.01%, 1%, 5%, 20%, ... is
it raising exponentially on the number of all pages? Memory use? Permgen
filling too quickly?
Is it really only about performance, or does it have other problems too?
What other (under the hood) differences do production and development
modes have?

Howard started this discussion without really explaining the reasons for
not having it at all or even the reasons for not having an option that
would enable it in production.


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Live reload in production?

Magnus Kvalheim-3
Any update on this?

We're about to upgrade to T5.3, but conveniently use template reload in
production on rare occasions.
From prior discussions a symbol would/could be introduced, but don't seem
like it has..?

Any way of supporting reload(without production=false)? Or is the dynamic
component the way to go?

Not a showstopper - just want to know what my options are...

thanks
Magnus

On Fri, Apr 22, 2011 at 9:01 PM, Vangel V. Ajanovski <[hidden email]> wrote:

> On 20.04.2011 21:03, Thiago H. de Paula Figueiredo wrote:
> > On Wed, 20 Apr 2011 15:21:10 -0300, LLTYK <[hidden email]> wrote:
> >
> >> Disabled, so you automatically get better performance. I don't think you
> >> should have to tweak Tapestry options to get better performance.
> >
> > Good point. But a similar argument can be used: enabled, so you get a
> > faster development environment without tweaking options. My gosh,
> > these decisions are hard. :)
>
> I would like to know what is truly the nature of the problem with live
> reload (besides possibility to get the application in an inconsistent
> state of which every developer is aware).
>
> What is the range of the performance penalty? 0.01%, 1%, 5%, 20%, ... is
> it raising exponentially on the number of all pages? Memory use? Permgen
> filling too quickly?
> Is it really only about performance, or does it have other problems too?
> What other (under the hood) differences do production and development
> modes have?
>
> Howard started this discussion without really explaining the reasons for
> not having it at all or even the reasons for not having an option that
> would enable it in production.
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Live reload in production?

Howard Lewis Ship
On Mon, Dec 12, 2011 at 1:20 PM, Magnus Kvalheim <[hidden email]> wrote:
> Any update on this?
>
> We're about to upgrade to T5.3, but conveniently use template reload in
> production on rare occasions.
> From prior discussions a symbol would/could be introduced, but don't seem
> like it has..?
>
> Any way of supporting reload(without production=false)? Or is the dynamic
> component the way to go?

No real options for 5.3; the code simply is not present. I guess you
could run in development mode, and change the handling of the
exception report (if you are not always doing so). You may experience
some minor memory leak issues, as in development mode, component
fields with FieldConduits will write values into fields as the
FieldConduit's get() or set() method is invoked ... basically, this
means that per-thread state can get into a shared page instance and
will not be cleared (but will be rapidly overwritten by other
threads).  It doesn't affect class behavior, the fields are never
read, just written to, except in terms of dangling references to
otherwise unused objects.

For 5.4, we can introduce yet another level of indirection that
indicates that live reloading is desired in production mode; perhaps
an enum to define what gets reloaded.  Is there a JIRA issue yet?

>
> Not a showstopper - just want to know what my options are...
>
> thanks
> Magnus
>
> On Fri, Apr 22, 2011 at 9:01 PM, Vangel V. Ajanovski <[hidden email]> wrote:
>
>> On 20.04.2011 21:03, Thiago H. de Paula Figueiredo wrote:
>> > On Wed, 20 Apr 2011 15:21:10 -0300, LLTYK <[hidden email]> wrote:
>> >
>> >> Disabled, so you automatically get better performance. I don't think you
>> >> should have to tweak Tapestry options to get better performance.
>> >
>> > Good point. But a similar argument can be used: enabled, so you get a
>> > faster development environment without tweaking options. My gosh,
>> > these decisions are hard. :)
>>
>> I would like to know what is truly the nature of the problem with live
>> reload (besides possibility to get the application in an inconsistent
>> state of which every developer is aware).
>>
>> What is the range of the performance penalty? 0.01%, 1%, 5%, 20%, ... is
>> it raising exponentially on the number of all pages? Memory use? Permgen
>> filling too quickly?
>> Is it really only about performance, or does it have other problems too?
>> What other (under the hood) differences do production and development
>> modes have?
>>
>> Howard started this discussion without really explaining the reasons for
>> not having it at all or even the reasons for not having an option that
>> would enable it in production.
>>
>>



--
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Live reload in production?

trsvax
In reply to this post by Thiago H de Paula Figueiredo
Personally I like the latest project layout with AppModule, DevelopmentModule etc. I would think the default should be off and the value overridden in the DevelopmentModule to on.

I also think -Dtapestry.execution-mode=development should be documented on the Getting Started page.

Finally I think the sample app should have the values and the documentation for these kinds of settings on the Index page. The easiest way to do that would be to create a DisplayConfig component and put it in the sample Index.tml.

I think all the defaults should be set for production but it should be obvious what the recommendations for development are and how to change them.
Reply | Threaded
Open this post in threaded view
|

Re: Live reload in production?

Magnus Kvalheim-2
In reply to this post by Howard Lewis Ship
>
>
> For 5.4, we can introduce yet another level of indirection that
> indicates that live reloading is desired in production mode; perhaps
> an enum to define what gets reloaded.  Is there a JIRA issue yet?
>

Thanks Howard - that sounds great.
Created issue: https://issues.apache.org/jira/browse/TAP5-1789



>
> >
> > Not a showstopper - just want to know what my options are...
> >
> > thanks
> > Magnus
> >
> > On Fri, Apr 22, 2011 at 9:01 PM, Vangel V. Ajanovski <[hidden email]>
> wrote:
> >
> >> On 20.04.2011 21:03, Thiago H. de Paula Figueiredo wrote:
> >> > On Wed, 20 Apr 2011 15:21:10 -0300, LLTYK <[hidden email]>
> wrote:
> >> >
> >> >> Disabled, so you automatically get better performance. I don't think
> you
> >> >> should have to tweak Tapestry options to get better performance.
> >> >
> >> > Good point. But a similar argument can be used: enabled, so you get a
> >> > faster development environment without tweaking options. My gosh,
> >> > these decisions are hard. :)
> >>
> >> I would like to know what is truly the nature of the problem with live
> >> reload (besides possibility to get the application in an inconsistent
> >> state of which every developer is aware).
> >>
> >> What is the range of the performance penalty? 0.01%, 1%, 5%, 20%, ... is
> >> it raising exponentially on the number of all pages? Memory use? Permgen
> >> filling too quickly?
> >> Is it really only about performance, or does it have other problems too?
> >> What other (under the hood) differences do production and development
> >> modes have?
> >>
> >> Howard started this discussion without really explaining the reasons for
> >> not having it at all or even the reasons for not having an option that
> >> would enable it in production.
> >>
> >>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
12