[ANN] New committer: Ognjen Blagojevic

[Mark Thomas]

On behalf of the Tomcat committers I am pleased to announce that
Ognjen Blagojevic (ognjen) has been voted in as a new Tomcat committer.

Please join me in welcoming him.

Regards,

Mark

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

Re: Monitoring Connections

[Aurélien Terrestris]

Chris,

I disagree in some way with you ;)

Instrumentation is difficult because you (as a developer ?) want to go
deep, but it is not necessary for a production team to go that deep to know
when something is going wrong. It's a developer challenge, and he could
choose to rely only on good logging. Whatever happens, there should be at
least some logs for the production team, then they can 'grep' for SEVERE or
Exceptions before asking more help to the N2 or N3 team.


"1. Java doesn't directly support SNMP;"

Sorry, but it does (
http://docs.oracle.com/javase/7/docs/technotes/guides/management/snmp.html
) and we use it with good results (deltas on GCs for example). Maybe are
you confusing with the fact that Java has no built-in API for SNMP software
developers.


"2. If the JVM is braindead, the SNMP agent can't announce any state
   to the managers."

The SNMP server will be unable to check the JVM, it will raise an alert.
Easy, cheap, and in most cases enough ;)


best regards
A.T.






2015-10-24 14:18 GMT+02:00 Christopher Schultz :

> Aurélien,
>
> On 10/23/15 6:47 PM, Aurélien Terrestris wrote:
> > "Live monitoring is the only way to go, unless you want your customers
> > to surprise you with performance problems on your own site. :)"
> >
> > Monitoring, ok, but alerting is critical for large scale production
> > environments.
>
> Apologies... I already considered "alerting" to be a critical component
> of "monitoring", so I didn't mention it specifically. Instrumentation is
> the hard part; alerting is relatively easy once instrumentation has been
> done.
>
> > You mention JMX callbacks for alerting, but it would be worth
> > that you mention SNMP since it's very easy to set up and efficient.
>
> SNMP is great, but there are a few problems with using it with Java:
>
> 1. Java doesn't directly support SNMP; instead, you have to use
>a 3rd-party library (which isn't difficult to find). This may be
>a barrier for certain organizations who only want to use their
>own code in their own applications.
>
> 2. If the JVM is braindead, the SNMP agent can't announce any state
>to the managers. This requires the use of probe-based instrumentation
>(active probing from the outside of the application), unless you want
>to have an agent send a heartbeat for every status change.
>
> > We also can raise alerts on deltas with this method, and see a
> > problem before the CPU says something bad is going to happen.
>
> There's nothing stopping you from doing deltas with other techniques. My
> presentation even includes a tool that allows you to do deltas.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: servlet filter not working over virtual directories in tomcat

[tomcat]

On 24.10.2015 05:11, Pradyut Bhattacharya wrote:


The URL

pattern therefore needs to be "/*"


Could not do anything with the above statement. May be an example could suffice.


Then maybe try this :

Instead of :

 
 dir_filter
 /web/*


try :

 
 dir_filter
 /*


Explanation : in  and , the  is *relative to 
the webapp context*. In your case, because of the way you have configured this, the webapp 
has a context of "/TestApp/web". Therefore, if you want the filter to apply to everything 
under "/TestApp/web", you have to map it to "/*".

So that, in URL-space, it will apply to "/TestApp/web/*".

The way you originally mapped it above, it would apply to "/TestApp/web/web/*", which is 
why it seemed not to be working.  The filter was there, but never invoked, because there 
was never any request URL matching "/TestApp/web/web/*".


Clearer ?

Note that this is the same as what Mark was saying, only in many more words.




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

Re: Tomcat answers on port 80, not on 443

[Christopher Schultz]

André,

On 10/23/15 4:16 PM, André Warnier (tomcat) wrote:
> On 23.10.2015 16:53, Beyer, Gregory L wrote:
> ...
> ##
> # Inbound SSL Settings
> ##
> 
> org.apache.felix.https.enable=true
> org.osgi.service.http.port.secure=443
>  org.apache.felix.https.keystore=E:\\Program
> Files\\Connector\\.keystore
>  org.apache.felix.https.keystore.password=REDACTED
>  org.apache.felix.https.keystore.key.password= REDACTED
>  org.apache.felix.https.truststore=C:\\Program
> Files\\Java\\jre1.8.0_60\\lib\\security\\cacerts
>  org.apache.felix.https.truststore.password= REDACTED
>>
>> Question  -- Does anyone think " Program Files"  (space) above is
>> contributing to the problem?
>>
> 
> Maybe, maybe not.  It would depend on how "Felix" parses its
> configuration files.
> 
> 
> But in any case, admitting spaces in file names is certainly one of the
> stupidest and most costly ideas in the history of computing.
> A close second would be making this a standard program installation
> directory in some widely-distributed operating systems.
> A close third would be using the same thing in the standard installation
> path of some popular open-source software.
> oh well..
> 
> 
> Getting back on-topic however : I do not know anything about Felix, and
> I have not really followed this thread.  But assuming that this Felix is
> a web application running under Tomcat, the fact that it has the above
> in its own configuration file, rather than in some Tomcat configuration
> file, would tend to make one suspect that Felix is opening its own
> listening socket, of which Tomcat knows nothing. No ?
> 
> And in such a case, there would be some conflict if one simultaneously
> to deploying this web application, would try to open a Tomcat Connector
> on the same port.
> One of them is bound to fail.

Felix is an OSGi thingy, which means it can ... do all kinds of things
you didn't expect it to do. Like turning a server daemon (Tomcat) into a
small component in a larger system in a single JVM where the daemon is
no longer completely in charge of the process.

So it's plausible that Felix would be configuring the  even
if it had never been configured through server.xml.

-chris

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

Re: Monitoring Connections

[Christopher Schultz]

Aurélien,

On 10/23/15 6:47 PM, Aurélien Terrestris wrote:
> "Live monitoring is the only way to go, unless you want your customers
> to surprise you with performance problems on your own site. :)"
> 
> Monitoring, ok, but alerting is critical for large scale production
> environments.

Apologies... I already considered "alerting" to be a critical component
of "monitoring", so I didn't mention it specifically. Instrumentation is
the hard part; alerting is relatively easy once instrumentation has been
done.

> You mention JMX callbacks for alerting, but it would be worth
> that you mention SNMP since it's very easy to set up and efficient.

SNMP is great, but there are a few problems with using it with Java:

1. Java doesn't directly support SNMP; instead, you have to use
   a 3rd-party library (which isn't difficult to find). This may be
   a barrier for certain organizations who only want to use their
   own code in their own applications.

2. If the JVM is braindead, the SNMP agent can't announce any state
   to the managers. This requires the use of probe-based instrumentation
   (active probing from the outside of the application), unless you want
   to have an agent send a heartbeat for every status change.

> We also can raise alerts on deltas with this method, and see a
> problem before the CPU says something bad is going to happen.

There's nothing stopping you from doing deltas with other techniques. My
presentation even includes a tool that allows you to do deltas.

-chris

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