Re: WebApp Caching Broken

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ken,

On 3/8/18 11:31 AM, Kenneth Taylor wrote:
> To clarify: We were making changes to our webapp and re-deploying
> and the changes were not showing up.  We think this was happening
> because of the shutdown problem I stated earlier.  There was more
> than one Tomcat running.  Also, there were some configuration
> issues that could have contributed to the problem, maybe, and it is
> also possible that our build system picked up an old config file
> that had the unpackWars flag set to false.  My use of the "caching"
> was simply a way of describing this problem.

Definitely make sure Tomcat is stopped. You can use the "jps" program
on most platforms to see what JVMs are running. The Tomcat processes
show with the name "Bootstrap" if you are using a traditional
(non-embedded) Tomcat.

> Also that JVM flag is supposed to disable connecting via a
> debugger, or any other application that uses the JVM Attach
> mechanism.  If that flag is not set then anyone who has network
> access can connect to any webapp in Tomcat, say with a debugger,
> and access sensitive information.

You have to have "host" access, not just network access. The Attach
API does not bind to any ports. Also, you either have to be the owner
of the process or have administrative access. For example, on a shared
server, I can't run "jstack -F [other users pid]" and get a thread
dump from their Java process. I can do it if I use "sudo", though.

Perhaps you are thinking of JMX? That requires a special
configuration, and *can* allow network access (though it's a real pain
IMO).

> If you run any JVM directly, with that flag set, you will not be
> able to connect to it, even if a debugger is configured. So if its
> not working with Tomcat then it is a potential security problem.

It does work. I just fired-up a Tomcat instance with that flag set on
the JVM:

$ $CATALINA_HOME/bin/catalina.sh start
$ jps
14491 Bootstrap
$ jstack 14491
14491: The VM does not support the attach mechanism
The -F option can be used when the target process is not responding
$ jstack -F 14491
Attaching to process ID 14491, please wait...
Error attaching to process:
sun.jvm.hotspot.debugger.DebuggerException: Can't attach symbolicator
to the process
sun.jvm.hotspot.debugger.DebuggerException:
sun.jvm.hotspot.debugger.DebuggerException: Can't attach symbolicator
to the process
at
sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal$BsdDebuggerLocalWorkerThre
ad.execute(BsdDebuggerLocal.java:169)
at
sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.attach(BsdDebuggerLocal.ja
va:287)
at sun.jvm.hotspot.HotSpotAgent.attachDebugger(HotSpotAgent.java:671)
at
sun.jvm.hotspot.HotSpotAgent.setupDebuggerDarwin(HotSpotAgent.java:659)
at sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:341)
at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:304)
at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:140)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:185)
at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
at sun.jvm.hotspot.tools.JStack.main(JStack.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.tools.jstack.JStack.runJStackTool(JStack.java:140)
at sun.tools.jstack.JStack.main(JStack.java:106)
Caused by: sun.jvm.hotspot.debugger.DebuggerException: Can't attach
symbolicator to the process
at sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.attach0(Native Method)
at
sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.access$100(BsdDebuggerLoca
l.java:65)
at
sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal$1AttachTask.doit(BsdDebugg
erLocal.java:278)
at
sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal$BsdDebuggerLocalWorkerThre
ad.run(BsdDebuggerLocal.java:144)

> Re-producing it is easy.  Simply set the flag and then run Tomcat
> and then connect with a debugger.
How are you setting that flag?

> Of course to use a debugger you also have to configure it in the 
> properties you start Tomcat with, but some JVM Attach apps may
> work without requiring that.
So... you are specifically configuring your JVM to allow debugging,
and you are upset that you can attach a debugger?

Are you sure the "attach" API is being used, here?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqhaaYdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjb1A/5Ad7eIPM1uLWjWt9O
naBVW0PJ2Y7wC3VDxmBbOB4Ya1/7wLwmcti5ltIWQ5ZvRmUMPVzwlewRo7P4hcZV
AqWKftcNQQW9OnVR9M+0Bgt/2te2vYyirFHIxRffW4w7uLkM5nOn0pryktm2zHpx

RE: WebApp Caching Broken

[Kenneth Taylor]

Thanks for the pointers.  I did not realize that I had setup Tomcat emails to 
go to a folder and didn't see people's responses.  Sorry about that.

To clarify: We were making changes to our webapp and re-deploying and the 
changes were not showing up.  We think this was happening because of the 
shutdown problem I stated earlier.  There was more than one Tomcat running.  
Also, there were some configuration issues that could have contributed to the 
problem, maybe, and it is also possible that our build system picked up an old 
config file that had the unpackWars flag set to false.  My use of the "caching" 
was simply a way of describing this problem.

Also that JVM flag is supposed to disable connecting via a debugger, or any 
other application that uses the JVM Attach mechanism.  If that flag is not set 
then anyone who has network access can connect to any webapp in Tomcat, say 
with a debugger, and access sensitive information.  If you run any JVM 
directly, with that flag set, you will not be able to connect to it, even if a 
debugger is configured.  So if its not working with Tomcat then it is a 
potential security problem.  Re-producing it is easy.  Simply set the flag and 
then run Tomcat and then connect with a debugger.  Of course to use a debugger 
you also have to configure it in the properties you start Tomcat with, but some 
JVM Attach apps may work without requiring that.

Thanks.
Ken

Disclaimer: This email from DMBGroup LLC, DMB Consulting Services LLC, or the 
personnel associated with either entity (collectively "DMB") and attachments, 
contain CONFIDENTIAL, PRIVILEGED AND PROPRIETARY information for exclusive use 
of the addressee individual(s) or entity. Unauthorized viewing, copying, 
disclosure, distribution or use of this e-mail or attachments may be subject to 
legal restriction or sanction. If received in error, notify sender immediately 
by return e-mail and delete original message and attachments. Nothing contained 
in this e-mail or attachments shall satisfy the requirements for a writing 
unless specifically stated. Nothing contained herein shall constitute a 
contract or electronic signature under the Electronic Signatures in Global and 
National Commerce Act, any version of the Uniform Electronic Transactions Act 
or any other statute governing electronic transactions. Opinions and statements 
expressed in this e-mail and any attachments are those of the individual sender 
and not necessarily of DMB. DMB does not guarantee this e-mail transmission is 
secured, error or virus-free. Neither DMB nor the sender of this e-mail accepts 
liability for errors or omissions in the contents of this e-mail, which arise 
as a result of e-mail transmission. .



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: WebApp Caching Broken

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ken,

On 3/6/18 9:09 AM, Kenneth Taylor wrote:
> More troubleshooting revealed that our root context xml had been
> copied from another installation and had a wrong path in it.

Do I smell another Darwin Award nomination?

> However, I don’t think this was the problem since it was only a
> path to a Log4J config. We re-installed Tomcat from scratch and it
> seems to have resolved it, but this is not good.  Why is Tomcat
> caching webapps?
Not sure what you mean. Please explain what YOU mean when you say
"caching". We probably have different definitions.

> Also determined that Tomcat was not shutting down properly.  Our 
> installation is deployed as a Windows Service.  Stopping the
> service did not stop Tomcat.  But the Service Console thinks it did
> stop, so when you restart it, another instance of Tomcat starts.
> We are using a Java Service Wrapper if that makes any difference.

Try taking a thread dump to see what threads are still running. My
guess is that your application starts some threads upon startup but
fails to shut them down on shutdown. Tomcat will not forcibly
shut-down the JVM for you; non-daemon threads can prevent the JVM stop
stopping even though Tomcat has shut-down cleanly.

> Also found another problem.  The “-XX:+DisableAttachMechanism” JVM 
> option does not work with Tomcat.  This is a security flaw.

Tomcat works perfectly fine with that option. There is no security
flaw, here. But it does mean that you won't be able to take a thread
dump of your application to find out what threads you left running,
sooo...

- -chris

> Disclaimer: This email from DMBGroup LLC, DMB Consulting Services
> LLC, or the personnel associated with either entity (collectively
> "*DMB*") and attachments, contain *CONFIDENTIAL, PRIVILEGED AND
> PROPRIETARY *information for exclusive use of the addressee
> individual(s) or entity.

OMG I had no idea!

> Unauthorized viewing, copying, disclosure, distribution or use of
> this e-mail or attachments may be subject to legal restriction or
> sanction.

Come at me, bro.

> If received in error, notify sender immediately by return e-mail
> and delete original message and attachments.

Obviously, both of these messages have been sent in error. It might be
difficult to remove them from the mailing list and archives and stuff.

> Nothing contained in this e-mail or attachments shall satisfy the 
> requirements for a writing unless specifically stated.
Hmm... writing isn't considered writing? Dogs and cats, living together.
..

> Nothing contained herein shall constitute a contract or electronic 
> signature under the Electronic Signatures in Global and National 
> Commerce Act, any version of the Uniform Electronic Transactions
> Act or any other statute governing electronic transactions.
Sorry, that's not how we roll here in Sealand. According to Article 6
Section 19 paragraph 49 sub-paragraph (e) of the Sealand Code, you are
now entered into a contract with all recipients of the list whereby
tyou agree not to be such a jerk. E Mare Libertas.

> Opinions and statements expressed in this e-mail and any
> attachments are those of the individual sender and not necessarily
> of DMB.

Good. But I still won't be contacting DMB for any consulting services
in the future, EVEN if they come out with another album as good as
Under the Table and Dreaming.

> DMB does not guarantee this e-mail transmission is secured, error
> or virus-free.
Or jerk-free. Time to update the disclaimer.

> Neither DMB nor the sender of this e-mail accepts liability for
> errors or omissions in the contents of this e-mail, which arise as
> a result of e-mail transmission.

How about sheer ignorance and lack of professional courtesy? I guess
that's not a technical problem.
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqe/2QdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFiGSQ/5AZGIqJE4u6IP3eab
ivudFF5yXl0a+hVea3ML24sgIRSX90awsadi9rOrE9pROYtRGMN/ffrRp1URyxMA
E9Tz0QZtiKx7WoZGvkefhe9wgG64m7itf8jTr0uQRIRp/J3xmTlhE2IwDIpXlAXI
yssqeWR7Gj/ywWDHD4WLLr2KbHcnZUvf+gWrQLpCNVUo4vf48s1aU0iR5jts4Z1x
XYRKozC4GfW974o7KRplb+CxQ3xoifO4E/I87H6roKG/XodMpWCIIFo9yx/6MuWF
UKBf/PP2Oj4uY13jG3DjqqrgcDeZF2bBCxWjNvItuTN52eR3iUSEiYAveDIGfCxB
gnYSFSPoOC34AsrreYtDyCxuEC/JhJMymDnZp8+JbPA2Y0JHbpXP10ij+0AcHtCt
MWF6ubybYEwynchhTMt78Fmn+gzLVwIo688SR/6xb0OKAt+LLjRy5Xjzm/+t6p0p
aGHsBU9HG8n9KQsQNaCvKR62A3U4O9n+aCik7e4ARUl/VriUWGBI/46tkUdcs7O9
AZs53WoTq54zoTZM+srN8amP+t+6dM7zjlm8ExeCchpwICK8m1aKnFCaZazNqDpU
dxvCTIdlEA5LgmwQ0L7or2cKpiK/4WLejVpMkOJcLGs1KnaECjrHfkMrS7kNg8nZ
qLxqDfGYQTKkJijFOKcc70ADRdI=
=B6jm
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: WebApp Caching Broken

[Olaf Kock]

Kenneth,


On 06.03.2018 15:09, Kenneth Taylor wrote:


More troubleshooting revealed that our root context xml had been 
copied from another installation and had a wrong path in it.  However, 
I don’t think this was the problem since it was only a path to a Log4J 
config.  We re-installed Tomcat from scratch and it seems to have 
resolved it, but this is not good.  Why is Tomcat caching webapps?




Tomcat loads webapps into memory, in order to execute them. It doesn't 
cache per se, as has been stated by others already.


Also determined that Tomcat was not shutting down properly.  Our 
installation is deployed as a Windows Service.  Stopping the service 
did not stop Tomcat.  But the Service Console thinks it did stop, so 
when you restart it, another instance of Tomcat starts.  We are using 
a Java Service Wrapper if that makes any difference.




Windows is known to sometimes keep file locks forever - in fact, I've 
been in trainings where students didn't just need to restart a server, 
but needed to reboot the OS in order to get rid of a locked file. Only 
on Windows.
Further, Tomcat does its best to shut down webapps. But if your webapps 
start their own non-daemon threads, the JVM doesn't shut down when 
Tomcat has long shut down. This, in turn, might keep file handles open, 
thus Windows-File-Locks (it's not always Windows that is to blame)


You'd have a point blaming tomcat for keeping references up, if you 
could reproduce your issues without custom webapps installed. I bet you 
can't, thus I'm seconding Mark with regards to the comment on your tone 
in your original post. And it doesn't really sound like you've read his 
reference.


Also found another problem.  The “-XX:+DisableAttachMechanism” JVM 
option does not work with Tomcat.  This is a security flaw.




please specify "does not work": Give steps to reproduce. Without them, 
this is just another rant assuming that you're perfect and all of the 
software around you is blamed for actively sabotaging your life


Olaf

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: WebApp Caching Broken

[M. Manna]

Kenneth,

As MarkT suggested earlier, there is no such "Cache". If you are using
Tag/Cotext Pooling - it's a separate issue and you need to check tomcat's
documentation to check what options you need/don't need.

"The “-XX:+DisableAttachMechanism” JVM option does not work with Tomcat" -
what do you mean? Did it work before, but doesn't work now? or it has
"Never" worked?  or "Ignored"? Please be precise.

Regards,


On 6 March 2018 at 14:09, Kenneth Taylor 
wrote:

> More troubleshooting revealed that our root context xml had been copied
> from another installation and had a wrong path in it.  However, I don’t
> think this was the problem since it was only a path to a Log4J config.  We
> re-installed Tomcat from scratch and it seems to have resolved it, but this
> is not good.  Why is Tomcat caching webapps?
>
>
>
> Also determined that Tomcat was not shutting down properly.  Our
> installation is deployed as a Windows Service.  Stopping the service did
> not stop Tomcat.  But the Service Console thinks it did stop, so when you
> restart it, another instance of Tomcat starts.  We are using a Java Service
> Wrapper if that makes any difference.
>
>
>
> Also found another problem.  The “-XX:+DisableAttachMechanism” JVM option
> does not work with Tomcat.  This is a security flaw.
>
>
>
> Thanks.
>
> Ken
>
> Disclaimer: This email from DMBGroup LLC, DMB Consulting Services LLC, or
> the personnel associated with either entity (collectively "*DMB*") and
> attachments, contain *CONFIDENTIAL, PRIVILEGED AND PROPRIETARY *information
> for exclusive use of the addressee individual(s) or entity. Unauthorized
> viewing, copying, disclosure, distribution or use of this e-mail or
> attachments may be subject to legal restriction or sanction. If received in
> error, notify sender immediately by return e-mail and delete original
> message and attachments. Nothing contained in this e-mail or attachments
> shall satisfy the requirements for a writing unless specifically stated.
> Nothing contained herein shall constitute a contract or electronic
> signature under the Electronic Signatures in Global and National Commerce
> Act, any version of the Uniform Electronic Transactions Act or any other
> statute governing electronic transactions. Opinions and statements
> expressed in this e-mail and any attachments are those of the individual
> sender and not necessarily of DMB. DMB does not guarantee this e-mail
> transmission is secured, error or virus-free. Neither DMB nor the sender of
> this e-mail accepts liability for errors or omissions in the contents of
> this e-mail, which arise as a result of e-mail transmission. .
>

RE: WebApp Caching Broken

[Kenneth Taylor]

More troubleshooting revealed that our root context xml had been copied from 
another installation and had a wrong path in it.  However, I don't think this 
was the problem since it was only a path to a Log4J config.  We re-installed 
Tomcat from scratch and it seems to have resolved it, but this is not good.  
Why is Tomcat caching webapps?

Also determined that Tomcat was not shutting down properly.  Our installation 
is deployed as a Windows Service.  Stopping the service did not stop Tomcat.  
But the Service Console thinks it did stop, so when you restart it, another 
instance of Tomcat starts.  We are using a Java Service Wrapper if that makes 
any difference.

Also found another problem.  The "-XX:+DisableAttachMechanism" JVM option does 
not work with Tomcat.  This is a security flaw.

Thanks.
Ken


Disclaimer: This email from DMBGroup LLC, DMB Consulting Services LLC, or the 
personnel associated with either entity (collectively "DMB") and attachments, 
contain CONFIDENTIAL, PRIVILEGED AND PROPRIETARY information for exclusive use 
of the addressee individual(s) or entity. Unauthorized viewing, copying, 
disclosure, distribution or use of this e-mail or attachments may be subject to 
legal restriction or sanction. If received in error, notify sender immediately 
by return e-mail and delete original message and attachments. Nothing contained 
in this e-mail or attachments shall satisfy the requirements for a writing 
unless specifically stated. Nothing contained herein shall constitute a 
contract or electronic signature under the Electronic Signatures in Global and 
National Commerce Act, any version of the Uniform Electronic Transactions Act 
or any other statute governing electronic transactions. Opinions and statements 
expressed in this e-mail and any attachments are those of the individual sender 
and not necessarily of DMB. DMB does not guarantee this e-mail transmission is 
secured, error or virus-free. Neither DMB nor the sender of this e-mail accepts 
liability for errors or omissions in the contents of this e-mail, which arise 
as a result of e-mail transmission. .

Re: WebApp Caching Broken

[Mark Thomas]

On 05/03/18 21:26, Kenneth Taylor wrote:
> We are having a serious problem with Tomcat (8.5).  Twice it has decided
> to PERMANENTLY cache one of our webapps.  We are unable to update that
> webapp.  We’ve tried everything imaginable, short of uninstalling
> Tomcat, which is the next step.
> 
> Where is this cache and how do we turn it off?

There is no such cache.

With so little information to go on it his difficult to provide useful
pointers. If the problem is that the application keeps re-deploying
after you thought you had deleted it then careful inspection of the logs
at start-up / deployment time along with this:
http://tomcat.apache.org/tomcat-8.5-doc/config/automatic-deployment.html

might help.

> Why in the world would anyone want Tomcat to work this way?  This is a
> fatal flaw worthy of a Darwin Award.

Suggesting that the people best placed to help you are so stupid they
deserve to be removed from the gene pool to benefit the human race is
not the best strategy to get people to help you. It is even less
effective when those people are volunteers who can choose which e-mails
to respond to and which to ignore.

It has been a while since I have provided a link to this excellent page
but I think a reminder is called for:

http://www.catb.org/esr/faqs/smart-questions.html

Mark


> Frustrated.
> 
>  
> 
> Ken
> 
>  
> 
> 
> Disclaimer: This email from DMBGroup LLC, DMB Consulting Services LLC,
> or the personnel associated with either entity (collectively "*DMB*")
> and attachments, contain *CONFIDENTIAL, PRIVILEGED AND PROPRIETARY
> *information for exclusive use of the addressee individual(s) or entity.
> Unauthorized viewing, copying, disclosure, distribution or use of this
> e-mail or attachments may be subject to legal restriction or sanction.
> If received in error, notify sender immediately by return e-mail and
> delete original message and attachments. Nothing contained in this
> e-mail or attachments shall satisfy the requirements for a writing
> unless specifically stated. Nothing contained herein shall constitute a
> contract or electronic signature under the Electronic Signatures in
> Global and National Commerce Act, any version of the Uniform Electronic
> Transactions Act or any other statute governing electronic transactions.
> Opinions and statements expressed in this e-mail and any attachments are
> those of the individual sender and not necessarily of DMB. DMB does not
> guarantee this e-mail transmission is secured, error or virus-free.
> Neither DMB nor the sender of this e-mail accepts liability for errors
> or omissions in the contents of this e-mail, which arise as a result of
> e-mail transmission. .
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: WebApp Caching Broken

[Dave Fisher]

I’m guessing that the OP’s configuration or user permissions are not allowing 
war unpacking to update the webapps directory to the new version of the webapps.

This has happened to me on some of my installations in the past when an admin 
starts as root vs. a special user like tomcat. This is often due to VM startup 
of Tomcat vs. restart script as a user.

For example:

If I originally deploy myapp.war as tomcat user but Tomcat is running as root 
it will create the myapp directory next to it with root ownership. Now I 
restart Tomcat and it is running as tomcat user. I replace myapp.war and Tomcat 
does not have permission to replace the old version owned by root.

Without the OP providing configuration details it is difficult to know, but 
this is what I have found.

Regards,
Dave

> On Mar 5, 2018, at 1:30 PM, Leon Rosenberg  wrote:
> 
> Hello,
> 
> can you explain what you mean by 'caching' ?
> 
> regards
> Leon
> 
> On Mon, Mar 5, 2018 at 10:26 PM, Kenneth Taylor <
> kenneth.tay...@dataexpress.com> wrote:
> 
>> We are having a serious problem with Tomcat (8.5).  Twice it has decided
>> to PERMANENTLY cache one of our webapps.  We are unable to update that
>> webapp.  We’ve tried everything imaginable, short of uninstalling Tomcat,
>> which is the next step.
>> 
>> 
>> 
>> Where is this cache and how do we turn it off?
>> 
>> 
>> 
>> Why in the world would anyone want Tomcat to work this way?  This is a
>> fatal flaw worthy of a Darwin Award.
>> 
>> 
>> 
>> Frustrated.
>> 
>> 
>> 
>> Ken
>> 
>> 
>> 
>> Disclaimer: This email from DMBGroup LLC, DMB Consulting Services LLC, or
>> the personnel associated with either entity (collectively "*DMB*") and
>> attachments, contain *CONFIDENTIAL, PRIVILEGED AND PROPRIETARY *information
>> for exclusive use of the addressee individual(s) or entity. Unauthorized
>> viewing, copying, disclosure, distribution or use of this e-mail or
>> attachments may be subject to legal restriction or sanction. If received in
>> error, notify sender immediately by return e-mail and delete original
>> message and attachments. Nothing contained in this e-mail or attachments
>> shall satisfy the requirements for a writing unless specifically stated.
>> Nothing contained herein shall constitute a contract or electronic
>> signature under the Electronic Signatures in Global and National Commerce
>> Act, any version of the Uniform Electronic Transactions Act or any other
>> statute governing electronic transactions. Opinions and statements
>> expressed in this e-mail and any attachments are those of the individual
>> sender and not necessarily of DMB. DMB does not guarantee this e-mail
>> transmission is secured, error or virus-free. Neither DMB nor the sender of
>> this e-mail accepts liability for errors or omissions in the contents of
>> this e-mail, which arise as a result of e-mail transmission. .
>> 



signature.asc
Description: Message signed with OpenPGP

Re: WebApp Caching Broken

[Leon Rosenberg]

Hello,

can you explain what you mean by 'caching' ?

regards
Leon

On Mon, Mar 5, 2018 at 10:26 PM, Kenneth Taylor <
kenneth.tay...@dataexpress.com> wrote:

> We are having a serious problem with Tomcat (8.5).  Twice it has decided
> to PERMANENTLY cache one of our webapps.  We are unable to update that
> webapp.  We’ve tried everything imaginable, short of uninstalling Tomcat,
> which is the next step.
>
>
>
> Where is this cache and how do we turn it off?
>
>
>
> Why in the world would anyone want Tomcat to work this way?  This is a
> fatal flaw worthy of a Darwin Award.
>
>
>
> Frustrated.
>
>
>
> Ken
>
>
>
> Disclaimer: This email from DMBGroup LLC, DMB Consulting Services LLC, or
> the personnel associated with either entity (collectively "*DMB*") and
> attachments, contain *CONFIDENTIAL, PRIVILEGED AND PROPRIETARY *information
> for exclusive use of the addressee individual(s) or entity. Unauthorized
> viewing, copying, disclosure, distribution or use of this e-mail or
> attachments may be subject to legal restriction or sanction. If received in
> error, notify sender immediately by return e-mail and delete original
> message and attachments. Nothing contained in this e-mail or attachments
> shall satisfy the requirements for a writing unless specifically stated.
> Nothing contained herein shall constitute a contract or electronic
> signature under the Electronic Signatures in Global and National Commerce
> Act, any version of the Uniform Electronic Transactions Act or any other
> statute governing electronic transactions. Opinions and statements
> expressed in this e-mail and any attachments are those of the individual
> sender and not necessarily of DMB. DMB does not guarantee this e-mail
> transmission is secured, error or virus-free. Neither DMB nor the sender of
> this e-mail accepts liability for errors or omissions in the contents of
> this e-mail, which arise as a result of e-mail transmission. .
>