On 05/12/2019 19:17, Tim K wrote:
> Was the fix for this added to 9.0.28 or 9.0.29 official releases?
9.0.28 but it triggered multiple regressions that will be fixed in 9.0.30.
Mark
-
To unsubscribe, e-mail:
Was the fix for this added to 9.0.28 or 9.0.29 official releases?
Thanks,
Tim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 11/7/19 11:43, Mark Thomas wrote:
>> Mark,
>>
>> On 11/7/19 06:40, Mark Thomas wrote:
>>> On 06/11/2019 20:04, Mark Thomas wrote:
I've found the root cause.
When checking the timestamps of JSPs, the JSP engine (because
On Thu, Nov 7, 2019, 1:58 PM Mark Thomas wrote:
> On 07/11/2019 18:04, Mark Thomas wrote:
> > On 07/11/2019 16:44, Mark Thomas wrote:
> >> On 07/11/2019 14:14, Tim K wrote:
> >>
> >>
> >>> I pulled the latest code from GitHub, I see the commit related to this
> >>> email thread in the log, I
On 07/11/2019 18:04, Mark Thomas wrote:
> On 07/11/2019 16:44, Mark Thomas wrote:
>> On 07/11/2019 14:14, Tim K wrote:
>>
>>
>>> I pulled the latest code from GitHub, I see the commit related to this
>>> email thread in the log, I built from master with ant (9.0.28-dev)
>>
>> Thanks. This is
On 07/11/2019 16:44, Mark Thomas wrote:
> On 07/11/2019 14:14, Tim K wrote:
>
>
>> I pulled the latest code from GitHub, I see the commit related to this
>> email thread in the log, I built from master with ant (9.0.28-dev)
>
> Thanks. This is really helpful.
>
>> and I'm
>> still experiencing
On 07/11/2019 14:14, Tim K wrote:
> I pulled the latest code from GitHub, I see the commit related to this
> email thread in the log, I built from master with ant (9.0.28-dev)
Thanks. This is really helpful.
> and I'm
> still experiencing the issue... I have a curl command executing every
>
> Mark,
>
> On 11/7/19 06:40, Mark Thomas wrote:
>> On 06/11/2019 20:04, Mark Thomas wrote:
>>> I've found the root cause.
>>>
>>> When checking the timestamps of JSPs, the JSP engine (because it
>>> has to access all resources via the Servlet API) requests a URL
>>> for the JSP, opens a
On Thu, Nov 7, 2019, 6:40 AM Mark Thomas wrote:
> On 06/11/2019 20:04, Mark Thomas wrote:
> > I've found the root cause.
> >
> > When checking the timestamps of JSPs, the JSP engine (because it has to
> > access all resources via the Servlet API) requests a URL for the JSP,
> > opens a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 11/7/19 06:40, Mark Thomas wrote:
> On 06/11/2019 20:04, Mark Thomas wrote:
>> I've found the root cause.
>>
>> When checking the timestamps of JSPs, the JSP engine (because it
>> has to access all resources via the Servlet API) requests
On 06/11/2019 20:04, Mark Thomas wrote:
> I've found the root cause.
>
> When checking the timestamps of JSPs, the JSP engine (because it has to
> access all resources via the Servlet API) requests a URL for the JSP,
> opens a connection to the URL and then checks the last modified time.
> This
I've found the root cause.
When checking the timestamps of JSPs, the JSP engine (because it has to
access all resources via the Servlet API) requests a URL for the JSP,
opens a connection to the URL and then checks the last modified time.
This goes directly to the on-disk file.
When reading the
On Tue, Nov 5, 2019 at 3:01 AM Mark Thomas wrote:
> This looks like some sort of concurrency issue. In your test
> environment, how likely is it that:
> - there are concurrent (or at least very close together) changes to a
> JSP
> - that there are concurrent requests for a modified JSP?
In my
On 05/11/2019 02:51, Tim K wrote:
> The cached JSP actually survives a tomcat restart because the work
> directory still contains the cached JSP content even though the timestamp
> of the class/java files appear to match that of the latest JSP file's
> content.
Ah. That is useful new
On Mon, Nov 4, 2019, 6:19 PM M. Manna wrote:
> I’m just trying to understand, is there really a plausible solution here ?
> Unless we have loadbalanced tomcat instances, can we truly ever stop such
> behaviour (or more importantly, does it make sense to do so)?
>
> For my use case, We do it in
I’m just trying to understand, is there really a plausible solution here ?
Unless we have loadbalanced tomcat instances, can we truly ever stop such
behaviour (or more importantly, does it make sense to do so)?
For my use case, We do it in production almost every other day for
patching, but we do
Sounds a lot like the issue I reported a few months ago
On Mon, Nov 4, 2019, 3:12 PM Tim K wrote:
> On Mon, Nov 4, 2019, 10:30 AM Mark Thomas wrote:
>
> >
> > Thanks. That helps as it means the issue should be reproducible on a
> > single, stand-alone instance.
> >
> > Mark
> >
>
> I was
On Mon, Nov 4, 2019, 10:30 AM Mark Thomas wrote:
>
> Thanks. That helps as it means the issue should be reproducible on a
> single, stand-alone instance.
>
> Mark
>
I was able to reproduce this behavior with a single server running a
vanilla 9.0.21 using the example hello.jsp file... I was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 11/4/19 11:56, Mark Thomas wrote:
> On 04/11/2019 15:30, Mark Thomas wrote:
>> On 04/11/2019 15:11, Tim K wrote:
>>> On Mon, Nov 4, 2019, 10:06 AM Mark Thomas
>>> wrote:
>>>
How are you distributing the updates to the JSP to
On 04/11/2019 15:30, Mark Thomas wrote:
> On 04/11/2019 15:11, Tim K wrote:
>> On Mon, Nov 4, 2019, 10:06 AM Mark Thomas wrote:
>>
>>>
>>> How are you distributing the updates to the JSP to all 4 servers?
>>>
>>> Is there a shared file system involved? If yes, exactly what is shared
>>> between
On 04/11/2019 15:11, Tim K wrote:
> On Mon, Nov 4, 2019, 10:06 AM Mark Thomas wrote:
>
>>
>> How are you distributing the updates to the JSP to all 4 servers?
>>
>> Is there a shared file system involved? If yes, exactly what is shared
>> between the instances?
>>
>> Mark
>>
>
> Common NFS
On Mon, Nov 4, 2019, 10:06 AM Mark Thomas wrote:
>
> How are you distributing the updates to the JSP to all 4 servers?
>
> Is there a shared file system involved? If yes, exactly what is shared
> between the instances?
>
> Mark
>
Common NFS storage included via (DirResourceSet) within the
of
On 04/11/2019 13:55, Tim K wrote:
>>
>> In my tests when hitting it every second, I make a few changes and it
>> works fine (all within the same min). Then I'll let it go for a few mins,
>> make a change and more often than not, one or more of the servers gets
>> stuck on the previous jsp
>
> In my tests when hitting it every second, I make a few changes and it
> works fine (all within the same min). Then I'll let it go for a few mins,
> make a change and more often than not, one or more of the servers gets
> stuck on the previous jsp change... I'm pretty sure the class/java
>
On Fri, Nov 1, 2019, 3:11 AM Mark Thomas wrote:
> On 31/10/2019 22:07, Mark Thomas wrote:
> >
> >
> > On 29/10/2019 14:31, Tim K wrote:
> >> I'm on Tomcat 9.0.21 on Linux. I have Jsps that get updated while
> >> Tomcat is running. I believe development mode is set to true by
> >> default, I do
On 31/10/2019 22:07, Mark Thomas wrote:
>
>
> On 29/10/2019 14:31, Tim K wrote:
>> I'm on Tomcat 9.0.21 on Linux. I have Jsps that get updated while
>> Tomcat is running. I believe development mode is set to true by
>> default, I do not have it set to true or false in the
>>
On 29/10/2019 14:31, Tim K wrote:
> I'm on Tomcat 9.0.21 on Linux. I have Jsps that get updated while
> Tomcat is running. I believe development mode is set to true by
> default, I do not have it set to true or false in the
> $CATALINA_BASE/conf/web.xml for the Jsp servlet init-params. I
I'm on Tomcat 9.0.21 on Linux. I have Jsps that get updated while
Tomcat is running. I believe development mode is set to true by
default, I do not have it set to true or false in the
$CATALINA_BASE/conf/web.xml for the Jsp servlet init-params. I have a
cluster of 4-8 servers across different
28 matches
Mail list logo
