Re: Per EndPoint Threads???

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Owen,

Please do not top-post. I have re-ordered your post to be bottom-post.

On 8/11/17 10:12 PM, Owen Rubel wrote:
> On Fri, Aug 11, 2017 at 5:58 PM,  wrote:
> 
>>> Hi All,
>>> 
>>> I'm looking for a way (or a tool) in Tomcat to associate
>>> threads with endpoints.
>> 
>> It isn't clear to me why this would be necessary. Threads should
>> be allocated on demand to individual requests. If one route sees
>> more traffic, then it should automatically be allocated more
>> threads. This could starve some requests if the maximum number of
>> threads had been allocated to a lessor used route, while
>> available threads went unused for more commonly used route.
> 
> Absolutely but it could ramp up more threads as needed.
> 
> I base the logic on neuron and neuralTransmitters. When neurons
> talk to each other, they send back neural transmitters to enforce
> that pathway.
> 
> If we could do the same through threads by adding additional
> threads for endpoints that receive more traffic vs those which do
> not, it would enforce better and faster communication on those
> paths.> The current way Tomcat does it is not dynamic and it just
> applies to ALL pathways equally which is not efficient.
How would this improve efficiency at all?

There is nothing inherently "showy" or "edity" about a particular
thread; each request-processing thread is indistinguishable from any
other. I don't believe there is a way to improve the situation even if
"per-endpoint" (whatever that would mean) threads were a possibility.

What would you attach to a thread that would make it any better at
editing records? Or deleting them?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmOi2YACgkQHPApP6U8
pFh+ohAAkIDqAaZK3mmQsSAE100a4RMwCyAjT076eiEkqj3MVJHUBuYf2adNlRYe
jvcKJCmvu061mW+/kos0+YIrt6ao2j60+fryX1goMOXhBxxrSlioccOwLkBu4HIG
SB/AuFIYqIG6S1ICqVunCFJsrYnMuJEX6WfA8O7G+sQWFH54w9XadewabEduu3uO
PwoP14a7XFOC8RPp9HM9Rdx8EfADRXrFugN0E5YSjXN5cdMs8bxJcabo8vjVnfNH
JDCkvF0tDd+FWj4t/AqXugM6fc6EYb8sSxEifxkdbu701A4doe8n1d1zawd3+qd4
IBVR6jFDHGqRm6cHvmhI8G4Tlx6c5EX29ZGTTdKnPvNloyob0a3/LauPJMr/97Xv
eIsj0shEfbUOWgcBWHRMbXbmZRjOAU7wxXtm2KsLZpJ6ZVZe9c7wSRLThYjp0Yyx
jgpwHN4sVPGG821trGht29E3v1e2GN1A7nuYbM7A7BK1PHP3MmLozVxAMxAip1T4
hVaVDHc1hd/G79Jvugq/T7atKQfOetLD4vg9ZFGIukaPZwA+3BtMYTNWn/bX2u9d
hBsWCw5Abn1SABlQ4cl87OJF9jya4p/P3Kqejyg9jbDbUy9J21QFEP6n5qHy9/vy
Jg6cjWpho6s9Ajx690ZNsdudDPoRuBe2TRLkFTOnUXsgwHTmToY=
=tiO+
-END PGP SIGNATURE-

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

Re: Per EndPoint Threads???

[Owen Rubel]

Absolutely but it could ramp up more threads as needed.

I base the logic on neuron and neuralTransmitters. When neurons talk to
each other, they send back neural transmitters to enforce that pathway.

If we could do the same through threads by adding additional threads for
endpoints that receive more traffic vs those which do not, it would enforce
better and faster communication on those paths.

The current way Tomcat does it is not dynamic and it just applies to ALL
pathways equally which is not efficient.


Owen Rubel
oru...@gmail.com

On Fri, Aug 11, 2017 at 5:58 PM,  wrote:

> > Hi All,
> >
> > I'm looking for a way (or a tool) in Tomcat to associate threads with
> > endpoints.
>
> It isn't clear to me why this would be necessary. Threads should be
> allocated on demand to individual requests. If one route sees more
> traffic, then it should automatically be allocated more threads. This
> could starve some requests if the maximum number of threads had been
> allocated to a lessor used route, while available threads went unused
> for more commonly used route.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Per EndPoint Threads???

[christopher]

> Hi All,
> 
> I'm looking for a way (or a tool) in Tomcat to associate threads with
> endpoints.

It isn't clear to me why this would be necessary. Threads should be
allocated on demand to individual requests. If one route sees more
traffic, then it should automatically be allocated more threads. This
could starve some requests if the maximum number of threads had been
allocated to a lessor used route, while available threads went unused
for more commonly used route.


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

Re: Tomcat Jasper (Jspc) compilation - Excluding list of JSPs from Jasper Compilation

[M. Manna]

Hi Mark,

Thanks a lot for confirming this. I haven't looked at the source code yet,
but I guess if I just use a wild-carded entry for jspFiles e.g.

jspFiles="*.jsp,/pages/*.jsp"

it will probably not work, will it ?

Kindest Regards,

On 11 August 2017 at 16:09, Mark Thomas  wrote:

> On 11/08/17 13:57, M. Manna wrote:
> > Hello,
> >
> > i am not sure if Jasper (JSPC) currently supports excluding  a list of
> JSP
> > files using typical  or  directive.
> >
> > Jpsc is a directory based task so it does have pathname include/excudes
> but
> > i think those are classes and compile classpath options (for jars/libs
> > etc.). Could somepone please point me to the right direction?
> >
> > All I want is to exclude certain JSP files when I am pre-compiling JSPs.
> > But I am good when I deploy on tomcat (no need to exclude anything).
> >
> > I appreciate the help :)
>
> Hi,
>
> There is a jspFiles attribute which is a comma separated list of all the
> JSPs you want to compile (paths relative to the uriroot).
>
> That is going to ugly if you have a lot of JSPs to compile and only a
> few to exclude.
>
> A hack would probably to rename the files you don't want to compile to
> *.jsp_skip and then rename them back after the jspc task.
>
> A proper fix would be to patch JspC to do 'proper' include / exclude
> support. I've no idea how much work that would be or how much demand
> there would be for it. Generally, when pre-compiling folks want to
> pre-compile everything.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Per EndPoint Threads???

[Owen Rubel]

Hi All,

I'm looking for a way (or a tool) in Tomcat to associate threads with
endpoints.

The reason being is that on a whole, threads are used not by the whole
system but distributed dynamically to specific pieces. Tomcat repeats this
process over and over but never stores this knowledge of which pieces
endpoints continually have high volume and which have lower volume traffic.

Even at startup/restart, these individual endpoints in the system should
start with a higher number of threads by DEFAULT as a result of the
continual higher traffic.

Is there a way to assign/distribute much like 'load balancing' the number
of threads across available endpoints???

ie:
localhost/v0.1/user/show: 50%
localhost/v0.1/user/create: 10%
localhost/v0.1/user/edit: 5%
localhost/v0.1/user/delete: 2%

Owen Rubel
oru...@gmail.com

Re: [2xOT] Re: More (Solved!) Re: I've just installed Tomcat (7.0.67) on an old CentOS 5 box. It can't be reached from outside the box.

[James H. H. Lampert]

On 8/11/17, 2:08 AM, Kreuser, Peter wrote:

PPS: James: I still can't get over it, that you run Tomcat on AS400,
my first contact to production systems back in '90.


That's not difficult at all. As long as a sufficiently high level of 
Java (the JV1 Licensed Program) is installed, it runs beautifully; 
just use JAR to unZIP it, and it'll run practically straight out of the box.


--
JHHL

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

Re: Tomcat Jasper (Jspc) compilation - Excluding list of JSPs from Jasper Compilation

[Mark Thomas]

On 11/08/17 13:57, M. Manna wrote:
> Hello,
> 
> i am not sure if Jasper (JSPC) currently supports excluding  a list of JSP
> files using typical  or  directive.
> 
> Jpsc is a directory based task so it does have pathname include/excudes but
> i think those are classes and compile classpath options (for jars/libs
> etc.). Could somepone please point me to the right direction?
> 
> All I want is to exclude certain JSP files when I am pre-compiling JSPs.
> But I am good when I deploy on tomcat (no need to exclude anything).
> 
> I appreciate the help :)

Hi,

There is a jspFiles attribute which is a comma separated list of all the
JSPs you want to compile (paths relative to the uriroot).

That is going to ugly if you have a lot of JSPs to compile and only a
few to exclude.

A hack would probably to rename the files you don't want to compile to
*.jsp_skip and then rename them back after the jspc task.

A proper fix would be to patch JspC to do 'proper' include / exclude
support. I've no idea how much work that would be or how much demand
there would be for it. Generally, when pre-compiling folks want to
pre-compile everything.

Mark

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

Re: Tomcat 9: UpgradedServletOutputStream

[Mark Thomas]

On 11/08/17 15:14, Rémy Maucherat wrote:
> On Fri, Aug 11, 2017 at 3:14 PM, Sergey Mashkov <
> sergey.mash...@jetbrains.com> wrote:
> 
>> Hi everyone
>>
>> I am experiencing race condition: from time to time when I cann to
>> UpgradedServletOutputStream.setWriteListener(myCallback) servlet container
>> doesn't invoke neither myCallback.onWritePossible() nor .onError.
>>
>> I believe the reason is that setWriteListener() method implementation sets
>> listener reference _AFTER_ it schedules dispatch/registers write listener.
>> I've checked regular (non-upgraded) CoyoteOutput and I see it's
>> implementation does the same but in correct order. Also I see that
>> UpgradedServletInputStream.setWriteListener also has such a strange order:
>>
> Ok, I don't see why and if I place it in the sync above there's no
> testsuite issue. I'll wait for Mark to ack that though, just in case
> there's a trick.

I don't see any issue with moving "this.listener = listener;" above the
sync.

A similar change in UpgradeServletInputStream should be fine too.

Mark

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

Re: Tomcat 9: UpgradedServletOutputStream

[Rémy Maucherat]

On Fri, Aug 11, 2017 at 3:14 PM, Sergey Mashkov <
sergey.mash...@jetbrains.com> wrote:

> Hi everyone
>
> I am experiencing race condition: from time to time when I cann to
> UpgradedServletOutputStream.setWriteListener(myCallback) servlet container
> doesn't invoke neither myCallback.onWritePossible() nor .onError.
>
> I believe the reason is that setWriteListener() method implementation sets
> listener reference _AFTER_ it schedules dispatch/registers write listener.
> I've checked regular (non-upgraded) CoyoteOutput and I see it's
> implementation does the same but in correct order. Also I see that
> UpgradedServletInputStream.setWriteListener also has such a strange order:
>
> Ok, I don't see why and if I place it in the sync above there's no
testsuite issue. I'll wait for Mark to ack that though, just in case
there's a trick.

Rémy

Monitoring Tomcat with check_jmxproxy.pl

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Some of you may know that I've given a "Monitoring Tomcat via JMX"
presentation a few times at various ApacheCons. The slides are
available on the Tomcat website.

In that presentation, I introduce a tool called check_jmxproxy which
is a script appropriate for use with Nagios, Ichinga, or any other
script-plug-in-based monitoring tool. It's been hosted until now on
people.apache.org alongside a copy of the slides for each event.

I've now uploaded the script to GitHub if anyone would like to check
it out and possibly contribute back to the (small) project. It's a
single Perl script with a small number of required Perl packages.

You can find the project here:
https://github.com/ChristopherSchultz/check-jmxproxy

I'd love any feedback anyone would care to provide.

I'm not the greatest Perl hacker, so if anyone would like to "fix" all
of my bad Perl, I'd appreciate that as well.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmNslAACgkQHPApP6U8
pFjSoA/+M/EGQstigy7f7iyrWzF/xuigQTPKgDsbjmPMpvY6+q/d9oUlr1FnYYqJ
4zryElXzFA0McPwSaPXmJ/nu93ZkK26H8m23pdTqE4wfnLDiG6JZ+9o0mLS3PrUH
5bJJacsUe2U5hPb+nvFbZBE80Hxfa5kqy/AFcaZX7hpuVVzAjPmqZaITRU03lWTo
1bxs4OqZ1HYDpOL60/mEGrm5FnkUS/wamxppeVvK06gjJ1cObI+i51knNq3LSlSw
2Hm8SXdlHSww7xXsRznf4lUO4kVD8xrK9nyXwRasz+KTqA6Jkjf49HYWL7KB+DfA
5W4Uf/HxdSDjPaPVZssdU1qUuH3qi9uWXkEDQUUwTnkhRVn4tmf6PmYhUhD+hVZf
h85+zE5Ix9bBGer8jG2PVWebi24JcjdgerZSfZd+gjhibFddBtSMn5x7S2R+bhf7
Ut/GBYZVoO5BH00cMFLNA2TvvjeO90HHAJzBQJVzba3aq21+ofLM+LoDCJXisxu6
QfhUKVlltDcGiKg4Z4FydNQK0zQS1/xOeThZ9b4RnE1zpZd4y9oWFhqhmsZTx6P/
iGO/iIkkCWDiPm8hIReKBN1fkPRJqJ8pIYa1NB2AwLS5g1G6v9DQEUf/IVl1n6JJ
Qw4wGmdFWoqSfuStOCkvnmshG0jKxZBub+3Auys4n/5zlxz9O3g=
=dNIh
-END PGP SIGNATURE-

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

Tomcat 9: UpgradedServletOutputStream

[Sergey Mashkov]

Hi everyone

I am experiencing race condition: from time to time when I cann to
UpgradedServletOutputStream.setWriteListener(myCallback) servlet container
doesn't invoke neither myCallback.onWritePossible() nor .onError.

I believe the reason is that setWriteListener() method implementation sets
listener reference _AFTER_ it schedules dispatch/registers write listener.
I've checked regular (non-upgraded) CoyoteOutput and I see it's
implementation does the same but in correct order. Also I see that
UpgradedServletInputStream.setWriteListener also has such a strange order:

Kind regards

Tomcat Jasper (Jspc) compilation - Excluding list of JSPs from Jasper Compilation

[M. Manna]

Hello,

i am not sure if Jasper (JSPC) currently supports excluding  a list of JSP
files using typical  or  directive.

Jpsc is a directory based task so it does have pathname include/excudes but
i think those are classes and compile classpath options (for jars/libs
etc.). Could somepone please point me to the right direction?

All I want is to exclude certain JSP files when I am pre-compiling JSPs.
But I am good when I deploy on tomcat (no need to exclude anything).

I appreciate the help :)

Kindest Regards,
M. Manna

Should c3p0 and postgres libraries be in $CATALINA_HOME/lib or each application's classpath?

[Miguel Almeida]

I used to put both  libraries in CATALINA_HOME, as past experiences made me
suspect of memory leaks if any of these 2 dependencies was in each
application's classpath.

However, the most recent c3p0 version has a dependency to
mchange-commons-java-0.2.11.jar (which also needs to be in CATALINA_HOME),
which made me re-think if that is the most appropriate location.

I added more contextual information (namely, c3p0's configuration in
spring) to
https://stackoverflow.com/questions/45621073/where-to-put-c3p0-dependency-in-tomcat-container


Could you share your experience in defining the location of these two
dependencies?

Thank you!
Miguel

[2xOT] Re: More (Solved!) Re: I've just installed Tomcat (7.0.67) on an old CentOS 5 box. It can't be reached from outside the box.

[Kreuser, Peter]

I'm glad that we get so well over serious problems. Made my day :-) !

PS: André: Sorry for the top post.
PPS: James: I still can't get over it, that you run Tomcat on AS400, my first 
contact to production systems back in '90.

-Ursprüngliche Nachricht-
Von: André Warnier (tomcat) [mailto:a...@ice-sa.com] 
Gesendet: Freitag, 11. August 2017 10:45
An: users@tomcat.apache.org
Betreff: [OT] Re: More (Solved!) Re: I've just installed Tomcat (7.0.67) on an 
old CentOS 5 box. It can't be reached from outside the box.

On 11.08.2017 00:27, James H. H. Lampert wrote:
> After looking up the man page (and while I *know* where the term comes 
> from, I *still* think there ought to be "woman," "boy," and "girl" 
> pages [and maybe "cat" and "dog" pages] as well!)

Note that there may be no "woman" command, but that one can do "man | more".
Similarly, there is no "boy" command, but one can do "man | less".
There is no "girl" command, but the Linux developers have tried to ease the 
pain of that by providing "talk", "chat" and "nice" (and even "tee", for the 
mature generation).
As for the animal world, there is indeed a "cat" command. And there may not be 
any "dog" 
command, but there are  "tail" and "head", which might be seen as more generic.


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

[OT] Re: More (Solved!) Re: I've just installed Tomcat (7.0.67) on an old CentOS 5 box. It can't be reached from outside the box.

[tomcat]

On 11.08.2017 00:27, James H. H. Lampert wrote:

After looking up the man page (and while I *know* where the term comes from, I 
*still*
think there ought to be "woman," "boy," and "girl" pages [and maybe "cat" and 
"dog" pages]
as well!)


Note that there may be no "woman" command, but that one can do "man | more".
Similarly, there is no "boy" command, but one can do "man | less".
There is no "girl" command, but the Linux developers have tried to ease the pain of that 
by providing "talk", "chat" and "nice" (and even "tee", for the mature generation).
As for the animal world, there is indeed a "cat" command. And there may not be any "dog" 
command, but there are  "tail" and "head", which might be seen as more generic.



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