Tested r12326 in the "debug" configuration which did not change the behavior.
Spending quite some time on it a few corrections/remarks:
* It seems that the number of successful requests depends on the ooRexx
configuration, whether it
is "debug" or "release". The "debug" version has about 50 successful
(quickly served) requests
fewer than the "release" configuration that I used yesterday.
* There are crashes from time to time which tear down Tomcat 9 and systemd
restarts that service
such that after a short while the response is quick (up to 680-710 requests
when the crawling
down occurs).
* If there are no crashes, then the requests slow down to take a little bit
more than a second.
Looking at the Tomcat log files there are no traces from ooRexx there.
---rony
On 28.11.2021 20:39, Rony G. Flatscher wrote:
> Tested with today's r12325, slow-down to appr. one second per request still
> occurs, however, it
> seems that there are appr. 50 more instances (over r12317, now around 730 vs.
> 680) that can be
> created before slowing down and quickly dropping down to a little bit more
> than one second per
> request from that moment on. Restarting Tomcat will have quick responses
> again, before it dorps down
> after appr. 730 requests again.
>
> ---rony
>
> On 25.11.2021 13:58, Rony G. Flatscher wrote:
>> Tested with r12317, slow-down to appr. one second per request still occurs,
>> however, it seems that
>> there are appr. 30-40 more instances that can be created before slowing down
>> and quickly dropping
>> down to a little bit more than one second per request.
>>
>> Maybe one observation with regards to Tomcat 9: it usually uses the same
>> thread to service client
>> requests for the same JSP (which is the case in the test here).
>>
>> ---rony
>>
>> On 23.11.2021 16:12, Rony G. Flatscher wrote:
>>> Tested 64-bit Tomcat+ooRexx on Linux using the same Java 17LTS as on
>>> Windows and a debug build of
>>> ooRexx from trunk (r12316) and the same web application that uses ooRexx in
>>> JSPs as on the Windows
>>> Tomcat server.
>>>
>>> The test will request constantly the same ooRexx JSP page from the Linux
>>> server for ten seconds and
>>> repeat it once. Each request will cause a Rexx interpreter instance RII to
>>> be created in the Tomcat
>>> server to execute all Rexx scripts in the requested JSP. (This rii will
>>> also have its .output
>>> redirected to the 'out'-Java object for that JSP run, such that output of
>>> say statements will get
>>> sent back as normal text to the client.)
>>>
>>> After restarting Tomcat, the very first run of fetching as quickly as
>>> possible the ooRexx test JSP
>>> will be rather quick up (appr. 13 msecs/req) to request # 400 (sometimes up
>>> to # 600) after which
>>> the requests get visually slower and slower and then (after appr. 30 more
>>> requests) start to need a
>>> little bit more than a second for each request (e.g. 1179 msecs/req) to
>>> return as if something
>>> blocks ooRexx serving the JSP. From this point on each request will need a
>>> little bit more than a
>>> second (a timeout?) until Tomcat gets restarted.
>>>
>>> Not sure how to debug this, so any advice, ideas and hints very welcome!
>>>
>>> ---rony
>>>
>>> P.S.: Did test with three builds of ooRexx from trunk, release,
>>> relWithDebInfo, debug, all
>>> exhibiting the same behaviour.
>>> P.P.S.: There are no errors in the various Linux Tomcat log files.
>>> P.P.P.S.: Tomcat on the Windows server, since yesterday's fix, remains
>>> responsive no matter how many
>>> requests with ooRexx in JSPs get sent to it.
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
