Hi Ed,

there will be a release by end of October, that contains the fix.
Is it possible for you to test against a pretty recent snapshot of 1.2.10 ?
(or against 1.1.10 if you are on the JSF 1.1 side):

http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trinidad/trinidad-api/1.2.10-SNAPSHOT/
http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trinidad/trinidad-impl/1.2.10-SNAPSHOT/

-Matthias

On Mon, Sep 29, 2008 at 5:26 PM, Edward Dowgiallo <[EMAIL PROTECTED]> wrote:
> It's been about a month since I posted the previous message, any
> thoughts on the questions?
>
> Is there a workaround for Trinidad-73?  Currently, it doesn't take too
> many users to crash Tomcat when we hit the maximum open files per
> process limit in z-Linux.
>
> Thank you,
> Ed
>
> On 8/25/08, Edward Dowgiallo <[EMAIL PROTECTED]> wrote:
>> We've been using a lot of include files in our JSF pages to sort of
>> simulate tiles.  The open file handle issue is a show stopper for us.
>> When we tried a beta test with a relatively small group of people, we
>> overran the 1000 file handle limit on our OS process very quickly.
>> After hitting the limit, the Tomcat server crashed.  We aren't really
>> effected in development, but just upping the file handles per process
>> isn't going to help us in production.  Our user base is 10000+.
>>
>> Is the group aware of any Trinidad deployments involving large numbers
>> of users?  Is Trinidad on Tomcat a viable environment for larger
>> numbers of users?  Has any performance testing been done to see how
>> well the library scales?
>>
>> Ed
>>
>> On 8/25/08, Harald Kuhn (JIRA) <[email protected]> wrote:
>>>
>>>     [
>>> https://issues.apache.org/jira/browse/TRINIDAD-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625333#action_12625333
>>> ]
>>>
>>> Harald Kuhn commented on TRINIDAD-73:
>>> -------------------------------------
>>>
>>> Thanks.
>>> This fix reduces the used file handles on first request from about 50 to
>>> 2.
>>> That's great.
>>>
>>> But I want to share two points I have noticed:
>>> 1) this fix seems to be useless if your webapp is deployed to Tomcat
>>> (Version 5.5.25) with option antiJARLocking="true".
>>>      This might be a Tomcat issue.
>>>
>>> 2) There are still multiple file handles for the generated css files
>>> (Output of lsof)
>>> java      30914 tomcat    4r   REG        8,2    90191    833043
>>> /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css
>>> java      30914 tomcat   15r   REG        8,2    90191    833043
>>> /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css
>>> java      30914 tomcat   43r   REG        8,2    90191    833043
>>> /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css
>>> java      30914 tomcat   54r   REG        8,2    90191    833043
>>> /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css
>>> java      30914 tomcat   58r   REG        8,2    90191    833043
>>> /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css
>>> java      30914 tomcat   61r   REG        8,2    90191    833043
>>> /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css
>>> java      30914 tomcat   86r   REG        8,2    90191    833043
>>> /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css
>>> java      30914 tomcat   88r   REG        8,2    90191    833043
>>> /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css
>>> java      30914 tomcat   97r   REG        8,2    90191    833043
>>> /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css
>>>
>>>> trinidad-impl.jar file is left open during execution
>>>> ----------------------------------------------------
>>>>
>>>>                 Key: TRINIDAD-73
>>>>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-73
>>>>             Project: MyFaces Trinidad
>>>>          Issue Type: Bug
>>>>    Affects Versions: 1.0.1-core
>>>>            Reporter: Adam Winer
>>>>            Assignee: Matthias Weßendorf
>>>>             Fix For: 1.2.10-core, 1.0.10-core
>>>>
>>>>         Attachments: AggregatingResourceLoader-patch-on-547038.txt,
>>>> CachingResourceLoader-patch-on-549615.txt,
>>>> ProxyResourceLoader-patch-on-518820.txt,
>>>> ResourceServlet-patch-on-549620.txt,
>>>> URLInputStreamProvider-patch-on-549615.txt, URLUtils-patch-on-660215.txt,
>>>> URLUtils.java
>>>>
>>>>
>>>> When running a Trinidad application, trinidad-impl.jar is getting locked
>>>> with open FileInputStream objects.  When GC occurs, the FileInputStreams
>>>> are getting cleared, but as new FileInputStreams are opened on each
>>>> request, the file is eternally locked.  Other files are likely getting
>>>> locked too.
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue online.
>>>
>>>
>>
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Reply via email to