Re: Weirdest Tomcat Behavior Ever?
Mark, On 11/26/20 05:14, Mark Thomas wrote: On 26/11/2020 04:57, Christopher Schultz wrote: After a normal clean-up the parent then calls close on the two file descriptors associated with the pipe for a second time." So the child cleans them up AND the parent cleans them up? Or the parent cleans when up twice? The child should be able to call close() as many times as it wants and only poison itself. Does the child process ever exit()? With the caveat that some of the below is educated guess work because the strace was configured to look at the events we were interested in so I am having to fill in some of the gaps. The parent "process" is a Java thread currently in native code in a 3rd party library. The parent creates a pipe which comes with two file descriptors. One for the read end, one for the write end. The parent process then forks. The child process now has copies of the two file descriptors. (see man fork for more details). The parent closes its fd for the write end of the pipe. The child closes its fd for the read end of the pipe. The child writes to the pipe and the parent reads from it. The child exits and closes its fd for the write end of the pipe. The parent closes its fd for the read end of the pipe. At this point all is good. All the closes completely cleanly. Everything has been shutdown properly. +1 The two fds allocated to the parent are back in the pool any may be reused by other threads in the JVM. The parent then attempts to close the fds associated with the pipe again. For each fd, if it has not been reallocated an EBADF error occurs. If it has been reallocated, it is closed thereby breaking whatever was using it legitimately. Thanks for clarifying this. I was confused and thinking you were saying that the child process was the one breaking things, but it's the parent process. Since the parent is the JVM (the long-running process), all hell breaks loose. The parent process must be the JVM process, right? And the parent process (this native library, running within the JVM process) double-closes file descriptors, with some measurable delay? Correct. In the instance where I did most of the log analysis the delay was about 0.1 seconds. In other logs I did observe longer delays with what looked like a very different failure mode. That's the only way this could make sense. And of course it mess mess everything up in really *really* unpredictable ways. Yep. Fascinating. Thanks for the wild ride, Eric and Mark :) -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [EXTERNAL] Re: Bouncy Castle FIPS on RHEL 7.3
Stefan, On 11/30/20 19:17, Stefan Mayr wrote: Hi, Am 30.11.2020 um 17:09 schrieb Amit Pande: I guess I will have to investigate the RHEL 7.3 entropy issue separately (possibly as hobby project) and look for other options to make progress. I still find it odd that something related to randomness (entropy generation) is so consistent (the slowness is equally slow or more on multiple RHEL 7.3 systems I have, maybe I need to look for machines from different data center or a physical 7.3 server). And yes, the 10 year certificate validity is just for testing purposes. 😊 Thank you for your inputs. Indeed helpful in evaluating our choices. Thanks, Amit you might have a look at rng-tools (rngd) or haveged to boost your entropy pool. We use haveged in a VMware virtualized environment and this reduces a plain tomcat startup from multiple minutes to just a few secondes. I think Red Hat preferes rngd but there should be some articles on access.redhat.com to help you depending on the used hypervisor. I would think long and hard about whether or not you want to use any of these tools. There are already ways to get "a lot of entropy really quickly" from the Linux kernel; specifically, /dev/urandom. The whole point of both /dev/random and /dev/urandom existing side by side is so that the application can pick whether it wants "high quality entropy" (by using /dev/random) or "good enough randomness" (by using /dev/urandom). Tools like haveged and rngd basically make /dev/random behave like /dev/urandom so the application can never have "high quality entropy" even when it asks for it. Have a look at this discussion on security.stackexchange to get you started down the path to paranoia: https://security.stackexchange.com/questions/34523 My question has always been "if these things are both safe and a good idea, why does the Linux kernel not implement them directly?" There must be a reason why the kernel devs have decided not to "speed up" /dev/random using the techniques used by both haveged and rngd. Maybe their argument is essentially "you can always just use haveged/rngd" but my guess is there is a more fundamental reason for not adopting these techniques directly in the kernel. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
embedded tomcat and context.xml
I'm old and easily confused: does an embedded tomcat server read (any)
context.xml file? I find conflicting answers /out there./
Using tomcat 9.0.40
embeddedTomcat =new Tomcat();
embeddedTomcat.setPort(tomcatPort);
embeddedTomcat.enableNaming();
embeddedTomcat.getConnector();// an init, really String contextRootPath
=System.getenv("CATALINA_HOME");
Context contextTomcat =embeddedTomcat.addContext("",new File(contextRootPath
+"/sgs").getAbsolutePath());
I know it is finding WEB-INF/web.xml (under "sgs") and finds all my
servlets, none of which are not named in the web.xml.
Re: embedded tomcat and context.xml
typo: should read "none of which are named in the web.xml" (not "which
are NOT" as below)
On 12/2/20 11:31 AM, Rob Sargent wrote:
I'm old and easily confused: does an embedded tomcat server read (any)
context.xml file? I find conflicting answers /out there./
Using tomcat 9.0.40
  embeddedTomcat =new Tomcat();
  embeddedTomcat.setPort(tomcatPort);
  embeddedTomcat.enableNaming();
  embeddedTomcat.getConnector();// an init, really String
contextRootPath =System.getenv("CATALINA_HOME");
  Context contextTomcat =embeddedTomcat.addContext("",new
File(contextRootPath +"/sgs").getAbsolutePath());
I know it is finding WEB-INF/web.xml (under "sgs") and finds all my
servlets, none of which are not named in the web.xml.
