Dear Brian,
please take the time to read about Linux Kernel namespaces as the technical
base of containers. It's like two viewpoints to one thing. Take the network
namespace as an example: From the conceptual point of view it looks like you
have N indipended, functional identical "IP Stacks".
On 2020-03-31 15:34, Mark Thomas wrote:
> On 31/03/2020 13:49, Aditya Kumar wrote:
>> Hi Mark,
>>
>> Sorry I'm not familiar with what a Selector is? However on one system I've
>> noticed 28000 such connections. Are these caused by client connections? I'm
>> not saying the connection originates
Dear John, Hi Rainer,
Thank you for your hints. I leaned to used this features on Github locate the
commit - it's
https://github.com/apache/tomcat/commit/fd2abbb525660a9968694afd99a58f8c22cb54c6
and it was committed by Mark Thomas. I don't know about the Tomcat project
policies, but
Dear Mark,
thank you for comments and hints. I would say I have a wide knowledge about
hard and software. But as I'm not working as a software developer, I'm not
familiar with a lot of things in deep. I also don't have key-ready workbenches
or buildchains. But I'll try to locate the
Dear André,
ups - yes, I confused both.
FIN ;)
Guido
On 11.05.2017 13:37, André Warnier (tomcat) wrote:
> I believe that the explanation given below by Guido is incorrect and
> misleading, as it seems to confuse CLOSE_WAIT with TIME_WAIT.
> See : TCP/IP State Transition Diagram (RFC793)
>
>
On 22.07.2016 19:15, Berneburg, Cris J. - US wrote:
> The OutOfMemoryError in Tomcat Manager was caused by a memory leak when Log4J
> did not terminate properly. This was due to my mistake of neglecting to set
> up the necessary Log4J shutdown procedures.
>
> Adding Log4jServletContextListener
On 14.07.2016 22:09, Mark Thomas wrote:
> On 14/07/2016 21:14, Mark Thomas wrote:
>> On 14/07/2016 09:26, Jäkel, Guido wrote:
>
>
>
>>> So maybe there should be a special code path in case of an ongoing
>>> initialization on the top like the 'if(unloading)' clause. The note states,
>>> that
Dear Mark,
> We need to find out what is triggering the second, unwanted
> initialization. You'll need to add some logging to your app to capture
> the relevant stack trace. When you have it, post it here.
taking remote access, I was able to extract a (hope so) relevant stack trace
from the
On 13.07.2016 22:41, Mark Thomas wrote:
> I've been through the MBean descriptor for a web application and as far
> as I can tell, reading of all of the attributes is passive. It might
> return a few unexpected nulls or maybe thrown an exception but it
> shouldn't trigger any additional