Re: is too quick to respond

2022-02-17 Thread Mark Thomas

On 17/02/2022 19:50, Christopher Schultz wrote:



This kind of thing could happen due to a number of different reasons, 
such as a slow disk or network share, etc. and ought to be 
protected-against.


I haven't looked at the code, but I would imagine it periodically reads 
all relevant files looking for anything that's been updated, but 
immediately acts the first time is finds someting worth triggering a 
reload.


It does. The periodic check is triggered by the background process.

It might make more sense to modify that logic so that *all* files are 
checked, but we cancel the reload if there are any files that are "too 
new". This would allow us to avoid a reload if some kind of copy is in 
progress. So we are looking for "anything newer than 
last_reload_timestamp but not if we find anything older than NOW - 10 
seconds".


Yes. We do something similar when checking for an update WAR file. Ten 
seconds might be a little on the high side.


Would you be interested in looking at the existing algorithm to see if 
it would be updated in this way?


WebappLoader.backgroundProcess() would be a good place to start.

Mark

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



Re: is too quick to respond

2022-02-17 Thread Christopher Schultz

John,

On 2/17/22 10:46, John Barrow wrote:

Hi,

I am now running Tomcat version 10.0.16 having just upgraded from
9.0.41. As a developer, I make use of the META-INF\context.xml feature
to detect changes within the classes folder WEB-INF\classes by



However, since moving to Tomcat 10.0.16, the reload keeps crashing
Tomcat due to the fact that Netbeans is recompiling multiple files and
as soon as the first file is completed, I believe that Tomcat triggers
its reload process and then fails as one of the listener classes is
still in the process of being rebuilt by Netbeans and so Tomcat can’t
access it for that split second to install the listener.

If I shut down Tomcat and re-open it again, all is well as Netbeans
has then had time to finish the re-compile.

If I make a change within the implementation of (say) one of the
listeners, so that Netbeans only has to re-compile that one .class
file, then Tomcat reloads the application perfectly.

Therefore, I was looking for the ability to add a delay to force
Tomcat, on having detected a change in one of the files, to wait a
moment to let Netbeans finish its job. I have researched the relevant
help files and read through
https://tomcat.apache.org/tomcat-8.0-doc/config/context.html and can’t
see any additional attribute that might handle this scenario.

If there isn’t an option, is it valid to raise it in the Bug Database?
I have searched the existing list and can’t see any previous mention
of it.

For some reason, I didn’t experience this while using Tomcat 9.0.41,
but it may have been slower to react to the .class files being change
and so did not have an issue with the files not being available while
they were being recompiled.

The relevant part of the log is as below

17-Feb-2022 14:47:54.861 SEVERE [Catalina-utility-2]
org.apache.catalina.core.StandardContext.listenerStart Error
configuring application listener of class [Listener.DataDictionary]
 java.lang.ClassNotFoundException: Listener.DataDictionary
 at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1444)
 at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1252)
 at
org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceManager.java:535)
 at
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:516)
 at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:150)
 at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4640)
 at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5179)
 at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
 at
org.apache.catalina.core.StandardContext.reload(StandardContext.java:3781)
 at
org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java:268)
 at
org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5562)
 at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1365)
 at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1369)
 at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1369)
 at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1347)
 at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
 at
java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
 at
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
 at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
 at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 at
java.base/java.lang.Thread.run(Thread.java:833)
17-Feb-2022 14:47:54.861 SEVERE [Catalina-utility-2]
org.apache.catalina.core.StandardContext.listenerStart Skipped
installing application listeners due to previous error(s)

Thanks in advance and here’s hoping to not have to have to 

Re: Tomcat 9.0.58 and OpenJDK 1.8.0_322

2022-02-17 Thread Robert Hicks
We think our java.security file is borked somehow. So going down that road
at the moment.

--
Bob

On Thu, Feb 17, 2022 at 12:49 PM Thad Humphries 
wrote:

> What is your use for SHA-1? Are you using it in your own code, like
> `MessageDigest.getInstance("SHA-1")` or do you have signed JARs? Or maybe
> certificates that use SHA-1? (though I don't think those have been a thing
> for quite some time)
>
> java.security.MessageDigest for Java 8 supposed to support MD5, SHA-1, and
> SHA-256 (see
> https://docs.oracle.com/javase/8/docs/api/java/security/MessageDigest.html
> ).
> I see references that SHA-1 has been disable for signed JARs (ex.,
> https://bugs-stage.openjdk.java.net/browse/JDK-8270610 and more
> https://adoptium.net/release_notes.html). However I do not see that SHA-1
> has been dropped from MessageDigest.
>
> Asking for a friend...
>
> On Wed, Feb 16, 2022 at 4:03 PM Noelette Stout 
> wrote:
>
> > Based on those errors, it sounds like SHA-1 has been desupported in the
> > newer OpenJDK version.
> >
> > On Wed, Feb 16, 2022 at 1:55 PM Robert Hicks 
> > wrote:
> >
> > > We are currently running Tomcat 9.0.40 and OpenJDK (Red Hat) 1.8.0_292
> > and
> > > have no issues.
> > >
> > > We upgrade to the ones in the subject line and Tomcat throws "SHA1PRNG
> > > SecureRandom not available" and "SHA MessageDigest not available" and
> > > "SHA-1 not available" and others.
> > >
> > > We downgrade to .40 and _292 and all is well again.
> > >
> > > Was there a change that could possibly cause that?
> > >
> > > Has anyone else seen this behavior?
> > >
> > > We are currently troubleshooting to see if we missed something on our
> end
> > > and can supply logs when that happens.
> > >
> > > Thanks!
> > >
> > > --
> > > Bob
> > >
> >
> >
> > --
> > Noelette Stout
> > ITS Enterprise Applications - Senior Application Administrator
> > Idaho State University
> > E-mail: stounoel "at" isu "dot" edu
> > Desk: 208-282-2554
> >
>
>
> --
> "Hell hath no limits, nor is circumscrib'd In one self-place; but where we
> are is hell, And where hell is, there must we ever be" --Christopher
> Marlowe, *Doctor Faustus* (v. 111-13)
>


Re: Tomcat 9.0.58 and OpenJDK 1.8.0_322

2022-02-17 Thread Thad Humphries
What is your use for SHA-1? Are you using it in your own code, like
`MessageDigest.getInstance("SHA-1")` or do you have signed JARs? Or maybe
certificates that use SHA-1? (though I don't think those have been a thing
for quite some time)

java.security.MessageDigest for Java 8 supposed to support MD5, SHA-1, and
SHA-256 (see
https://docs.oracle.com/javase/8/docs/api/java/security/MessageDigest.html).
I see references that SHA-1 has been disable for signed JARs (ex.,
https://bugs-stage.openjdk.java.net/browse/JDK-8270610 and more
https://adoptium.net/release_notes.html). However I do not see that SHA-1
has been dropped from MessageDigest.

Asking for a friend...

On Wed, Feb 16, 2022 at 4:03 PM Noelette Stout 
wrote:

> Based on those errors, it sounds like SHA-1 has been desupported in the
> newer OpenJDK version.
>
> On Wed, Feb 16, 2022 at 1:55 PM Robert Hicks 
> wrote:
>
> > We are currently running Tomcat 9.0.40 and OpenJDK (Red Hat) 1.8.0_292
> and
> > have no issues.
> >
> > We upgrade to the ones in the subject line and Tomcat throws "SHA1PRNG
> > SecureRandom not available" and "SHA MessageDigest not available" and
> > "SHA-1 not available" and others.
> >
> > We downgrade to .40 and _292 and all is well again.
> >
> > Was there a change that could possibly cause that?
> >
> > Has anyone else seen this behavior?
> >
> > We are currently troubleshooting to see if we missed something on our end
> > and can supply logs when that happens.
> >
> > Thanks!
> >
> > --
> > Bob
> >
>
>
> --
> Noelette Stout
> ITS Enterprise Applications - Senior Application Administrator
> Idaho State University
> E-mail: stounoel "at" isu "dot" edu
> Desk: 208-282-2554
>


-- 
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be" --Christopher
Marlowe, *Doctor Faustus* (v. 111-13)


is too quick to respond

2022-02-17 Thread John Barrow
Hi,

I am now running Tomcat version 10.0.16 having just upgraded from
9.0.41. As a developer, I make use of the META-INF\context.xml feature
to detect changes within the classes folder WEB-INF\classes by



However, since moving to Tomcat 10.0.16, the reload keeps crashing
Tomcat due to the fact that Netbeans is recompiling multiple files and
as soon as the first file is completed, I believe that Tomcat triggers
its reload process and then fails as one of the listener classes is
still in the process of being rebuilt by Netbeans and so Tomcat can’t
access it for that split second to install the listener.

If I shut down Tomcat and re-open it again, all is well as Netbeans
has then had time to finish the re-compile.

If I make a change within the implementation of (say) one of the
listeners, so that Netbeans only has to re-compile that one .class
file, then Tomcat reloads the application perfectly.

Therefore, I was looking for the ability to add a delay to force
Tomcat, on having detected a change in one of the files, to wait a
moment to let Netbeans finish its job. I have researched the relevant
help files and read through
https://tomcat.apache.org/tomcat-8.0-doc/config/context.html and can’t
see any additional attribute that might handle this scenario.

If there isn’t an option, is it valid to raise it in the Bug Database?
I have searched the existing list and can’t see any previous mention
of it.

For some reason, I didn’t experience this while using Tomcat 9.0.41,
but it may have been slower to react to the .class files being change
and so did not have an issue with the files not being available while
they were being recompiled.

The relevant part of the log is as below

17-Feb-2022 14:47:54.861 SEVERE [Catalina-utility-2]
org.apache.catalina.core.StandardContext.listenerStart Error
configuring application listener of class [Listener.DataDictionary]
java.lang.ClassNotFoundException: Listener.DataDictionary
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1444)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1252)
at
org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceManager.java:535)
at
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:516)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:150)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4640)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5179)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.StandardContext.reload(StandardContext.java:3781)
at
org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java:268)
at
org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5562)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1365)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1369)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1369)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1347)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at
java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
at
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at
java.base/java.lang.Thread.run(Thread.java:833)
17-Feb-2022 14:47:54.861 SEVERE [Catalina-utility-2]
org.apache.catalina.core.StandardContext.listenerStart Skipped
installing application listeners due to previous error(s)

Thanks in advance and here’s hoping to not have to have to keep
Stopping & Starting Tomcat for every development change.

John