You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Enke, Michael" <mi...@wincor-nixdorf.com> on 2002/08/27 17:08:29 UTC
2: Please help! Caching or Threadproblem or what else?
I forgot one important detail:
This happens only if tomcat was restarted or if the xsp-file changed on disk.
The second and all follwing requests come out super fluid,
even if I use noncaching pipeline.
Regards,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: 2: Please help! Caching or Threadproblem or what else?
Posted by "Enke, Michael" <mi...@wincor-nixdorf.com>.
"Enke, Michael" wrote:
>
> "Enke, Michael" wrote:
> >
> > Vadim Gritsenko wrote:
> > >
> > > Enke, Michael wrote:
> > >
> > > >I tried it now under Windows ME:
> > > >The swap file C:\WINDOWS\WIN386.SWP
> > > >was growing until C:\ was full (swap file size about 500 MB) :-(
> > > >
> > >
> > > But this means that this is not related to Java - Java's total memory is
> > > limited to ... whatever you specify.
> > >
> > > Or this can be bug in JDK (less possible). What do you think?
I found this is a bug in pizza compiler. Now I have Javac configured in cocoon.xconf,
all is working well.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: 2: Please help! Caching or Threadproblem or what else?
Posted by "Enke, Michael" <mi...@wincor-nixdorf.com>.
"Enke, Michael" wrote:
>
> Vadim Gritsenko wrote:
> >
> > Enke, Michael wrote:
> >
> > >I tried it now under Windows ME:
> > >The swap file C:\WINDOWS\WIN386.SWP
> > >was growing until C:\ was full (swap file size about 500 MB) :-(
> > >
> >
> > But this means that this is not related to Java - Java's total memory is
> > limited to ... whatever you specify.
> >
> > Or this can be bug in JDK (less possible). What do you think?
here I post the problematic file. I let it run from command line after setting CLASSPATH:
java -Djdbc.drivers=$my_DB_driver_class org.apache.cocoon.Main -c . -u ERROR test801.xml
(no further transformation).
Interesting are only the last few lines where I produce the mass data
(for loop with createRow method). I print the rownumber to System.out.
1) I changed the namespace for esql logicsheet so that esql is not applied:
At line 1271 there is a one second delay,
after this it is going on. That's probably the gc? I don't know.
The memory consumption is ok (20 ... 25 percent).
2) With correct namespace, when esql is applied, it blocks at rowNumber 1271,
sometimes for one minute, sometimes forever.
I use only one sql statement: String SQL_QUERY="select 0,0" (I have postgres)
so you can easily change for other DB system, e.g. select 0 from dual (for Oracle)
I watch the memory usage with the command "top" (on linux), delay between updates
1 second, sort by memory usage. The percent MEM is: 20% ... 30% ... 40% ...
50% ... 82% ... 42% ... 60% ... 70% ... 80% ... 80% ... 80% ... always 80%
I have 320MB physical memory and 264MB swap space.
StoreJanitor settings are the default values from cocoon.xconf
If I cut some code before the for loop (which has no relevance to the loop),
the blocking disappears, than there is only delay of 1 second ... 1 minute,
depends how mutch code is removed.
Maybe this a problem of StoreJanitor?
I appreciate for any help.
Michael
Re: 2: Please help! Caching or Threadproblem or what else?
Posted by "Enke, Michael" <mi...@wincor-nixdorf.com>.
Vadim Gritsenko wrote:
>
> Enke, Michael wrote:
>
> >I tried it now under Windows ME:
> >The swap file C:\WINDOWS\WIN386.SWP
> >was growing until C:\ was full (swap file size about 500 MB) :-(
> >
>
> But this means that this is not related to Java - Java's total memory is
> limited to ... whatever you specify.
>
> Or this can be bug in JDK (less possible). What do you think?
I don't know. My second guess was that it is the virtual machine problem.
That's why I got the latest version 1.4.0_01
My setup:
Machine 1: Linux: postgresql Database
Machine 2: Windows ME: Tomcat 4.1.9 with Cocoon-2.1-dev
Machine 3: Windows NT: Browser. download xml produced from Machine 2
So I have no influence from the DB (only the JDBC driver) and no influence from
downloading the file. At this time I did not yet succeed in running Cocoon
standalone on Windows because I cann't see the missing jars because the
ClassNotFoundException in DOS-box scrolls out and I cann't redirect output to a file ...
But on a linux machine I have the same behaviour if I run java org.apache.cocoon.Main.
I will try at the weekend to remove all database dependent code so that I can post
my xsp on monday.
Nice weekend,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: 2: Please help! Caching or Threadproblem or what else?
Posted by Vadim Gritsenko <va...@verizon.net>.
Enke, Michael wrote:
>I tried it now under Windows ME:
>The swap file C:\WINDOWS\WIN386.SWP
>was growing until C:\ was full (swap file size about 500 MB) :-(
>
But this means that this is not related to Java - Java's total memory is
limited to ... whatever you specify.
Or this can be bug in JDK (less possible). What do you think?
Vadim
>Michael
>
>"Enke, Michael" wrote:
>
>
>>Klaus Bertram wrote:
>>
>>
>>>Michael wrote:
>>>
>>>
>>>>Vadim Gritsenko wrote:
>>>>
>>>>
>>>>>>It does also not help to call this xsp ones with small data amount
>>>>>>and the second time with large data amount (giving the amount as request value).
>>>>>>
>>>>>>I know the process ID (Linux) of the thread which stops the system.
>>>>>>Is there any way to know if this thread is the garbage collection thread?
>>>>>>
>>>>>>
>>>>>>
>>>>>Delay in small XSP can be explained as gc, but system hang-up... I
>>>>>doubt. StoreJanitor monitors memory state and logs everything to the log
>>>>>file - do you see any suspicious activity there? if not, it is not gc issue.
>>>>>
>>>>>
>>>>>
>>>>Nothing suspicious in the logfile:
>>>>DEBUG (2002-08-29) 16:23.49:350 [core.store.janitor] (Unknown-URI) Unknown-thread/StoreJanitorImpl: JVM total Memory: 49377280
>>>>DEBUG (2002-08-29) 16:23.49:351 [core.store.janitor] (Unknown-URI) Unknown-thread/StoreJanitorImpl: JVM free Memory: 12260168
>>>>DEBUG (2002-08-29) 16:23.49:351 [core.store.janitor] (Unknown-URI) Unknown-thread/StoreJanitorImpl: Memory is low = false
>>>>
>>>>
>>>>Michael
>>>>
>>>>
>>>Is your jdk is sun 1.3 ?
>>>they had with this problems by large memory and thread's Stand of jan 02
>>>
>>>
>>No, I have Sun 1.4.0_01
>>As I encountered this problem I got the latest available jdk.
>>
>>Michael
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: 2: Please help! Caching or Threadproblem or what else?
Posted by "Enke, Michael" <mi...@wincor-nixdorf.com>.
I tried it now under Windows ME:
The swap file C:\WINDOWS\WIN386.SWP
was growing until C:\ was full (swap file size about 500 MB) :-(
Michael
"Enke, Michael" wrote:
>
> Klaus Bertram wrote:
> >
> > Michael wrote:
> > >Vadim Gritsenko wrote:
> > >>
> > >> >It does also not help to call this xsp ones with small data amount
> > >> >and the second time with large data amount (giving the amount as request value).
> > >> >
> > >> >I know the process ID (Linux) of the thread which stops the system.
> > >> >Is there any way to know if this thread is the garbage collection thread?
> > >> >
> > >>
> > >> Delay in small XSP can be explained as gc, but system hang-up... I
> > >> doubt. StoreJanitor monitors memory state and logs everything to the log
> > >> file - do you see any suspicious activity there? if not, it is not gc issue.
> > >>
> > >
> > >Nothing suspicious in the logfile:
> > >DEBUG (2002-08-29) 16:23.49:350 [core.store.janitor] (Unknown-URI) Unknown-thread/StoreJanitorImpl: JVM total Memory: 49377280
> > >DEBUG (2002-08-29) 16:23.49:351 [core.store.janitor] (Unknown-URI) Unknown-thread/StoreJanitorImpl: JVM free Memory: 12260168
> > >DEBUG (2002-08-29) 16:23.49:351 [core.store.janitor] (Unknown-URI) Unknown-thread/StoreJanitorImpl: Memory is low = false
> > >
> > >
> > >Michael
> >
> > Is your jdk is sun 1.3 ?
> > they had with this problems by large memory and thread's Stand of jan 02
>
> No, I have Sun 1.4.0_01
> As I encountered this problem I got the latest available jdk.
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: 2: Please help! Caching or Threadproblem or what else?
Posted by "Enke, Michael" <mi...@wincor-nixdorf.com>.
Klaus Bertram wrote:
>
> Michael wrote:
> >Vadim Gritsenko wrote:
> >>
> >> >It does also not help to call this xsp ones with small data amount
> >> >and the second time with large data amount (giving the amount as request value).
> >> >
> >> >I know the process ID (Linux) of the thread which stops the system.
> >> >Is there any way to know if this thread is the garbage collection thread?
> >> >
> >>
> >> Delay in small XSP can be explained as gc, but system hang-up... I
> >> doubt. StoreJanitor monitors memory state and logs everything to the log
> >> file - do you see any suspicious activity there? if not, it is not gc issue.
> >>
> >
> >Nothing suspicious in the logfile:
> >DEBUG (2002-08-29) 16:23.49:350 [core.store.janitor] (Unknown-URI) Unknown-thread/StoreJanitorImpl: JVM total Memory: 49377280
> >DEBUG (2002-08-29) 16:23.49:351 [core.store.janitor] (Unknown-URI) Unknown-thread/StoreJanitorImpl: JVM free Memory: 12260168
> >DEBUG (2002-08-29) 16:23.49:351 [core.store.janitor] (Unknown-URI) Unknown-thread/StoreJanitorImpl: Memory is low = false
> >
> >
> >Michael
>
> Is your jdk is sun 1.3 ?
> they had with this problems by large memory and thread's Stand of jan 02
No, I have Sun 1.4.0_01
As I encountered this problem I got the latest available jdk.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: 2: Please help! Caching or Threadproblem or what else?
Posted by Klaus Bertram <k....@kbsm.de>.
Michael wrote:
>Vadim Gritsenko wrote:
>>
>> >It does also not help to call this xsp ones with small data amount
>> >and the second time with large data amount (giving the amount as request value).
>> >
>> >I know the process ID (Linux) of the thread which stops the system.
>> >Is there any way to know if this thread is the garbage collection thread?
>> >
>>
>> Delay in small XSP can be explained as gc, but system hang-up... I
>> doubt. StoreJanitor monitors memory state and logs everything to the log
>> file - do you see any suspicious activity there? if not, it is not gc issue.
>>
>
>Nothing suspicious in the logfile:
>DEBUG (2002-08-29) 16:23.49:350 [core.store.janitor] (Unknown-URI) Unknown-thread/StoreJanitorImpl: JVM total Memory: 49377280
>DEBUG (2002-08-29) 16:23.49:351 [core.store.janitor] (Unknown-URI) Unknown-thread/StoreJanitorImpl: JVM free Memory: 12260168
>DEBUG (2002-08-29) 16:23.49:351 [core.store.janitor] (Unknown-URI) Unknown-thread/StoreJanitorImpl: Memory is low = false
>
>
>Michael
Is your jdk is sun 1.3 ?
they had with this problems by large memory and thread's Stand of jan 02
Klaus
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: 2: Please help! Caching or Threadproblem or what else?
Posted by "Enke, Michael" <mi...@wincor-nixdorf.com>.
Vadim Gritsenko wrote:
>
> >It does also not help to call this xsp ones with small data amount
> >and the second time with large data amount (giving the amount as request value).
> >
> >I know the process ID (Linux) of the thread which stops the system.
> >Is there any way to know if this thread is the garbage collection thread?
> >
>
> Delay in small XSP can be explained as gc, but system hang-up... I
> doubt. StoreJanitor monitors memory state and logs everything to the log
> file - do you see any suspicious activity there? if not, it is not gc issue.
>
Nothing suspicious in the logfile:
DEBUG (2002-08-29) 16:23.49:350 [core.store.janitor] (Unknown-URI) Unknown-thread/StoreJanitorImpl: JVM total Memory: 49377280
DEBUG (2002-08-29) 16:23.49:351 [core.store.janitor] (Unknown-URI) Unknown-thread/StoreJanitorImpl: JVM free Memory: 12260168
DEBUG (2002-08-29) 16:23.49:351 [core.store.janitor] (Unknown-URI) Unknown-thread/StoreJanitorImpl: Memory is low = false
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: 2: Please help! Caching or Threadproblem or what else?
Posted by Vadim Gritsenko <va...@verizon.net>.
Enke, Michael wrote:
>Vadim Gritsenko wrote:
>
>
>>>That would mean cocoon cann't serve complex xsp's with more than
>>>
>>>
>>>
>>Why can't? You said that there is delay, that's it. So, it can, but with
>>delay, and only after XSP is modified (AFAIU). What's wrong with it,
>>especially if it is garbage collector cleaning up compilation trees and
>>variables?
>>
>>
>
>The delay I have only on this sample page I appended to my mail.
>My real xsp makes the system sometimes absolutely hanging, sometimes
>tomcat stops work but without any hint in the logs.
>
Ok, got you.
>It does also not help to call this xsp ones with small data amount
>and the second time with large data amount (giving the amount as request value).
>
>I know the process ID (Linux) of the thread which stops the system.
>Is there any way to know if this thread is the garbage collection thread?
>
Delay in small XSP can be explained as gc, but system hang-up... I
doubt. StoreJanitor monitors memory state and logs everything to the log
file - do you see any suspicious activity there? if not, it is not gc issue.
Vadim
>Michael
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: 2: Please help! Caching or Threadproblem or what else?
Posted by "Enke, Michael" <mi...@wincor-nixdorf.com>.
Vadim Gritsenko wrote:
> >That would mean cocoon cann't serve complex xsp's with more than
> >
>
> Why can't? You said that there is delay, that's it. So, it can, but with
> delay, and only after XSP is modified (AFAIU). What's wrong with it,
> especially if it is garbage collector cleaning up compilation trees and
> variables?
The delay I have only on this sample page I appended to my mail.
My real xsp makes the system sometimes absolutely hanging, sometimes
tomcat stops work but without any hint in the logs.
It does also not help to call this xsp ones with small data amount
and the second time with large data amount (giving the amount as request value).
I know the process ID (Linux) of the thread which stops the system.
Is there any way to know if this thread is the garbage collection thread?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: 2: Please help! Caching or Threadproblem or what else?
Posted by Vadim Gritsenko <va...@verizon.net>.
Enke, Michael wrote:
>Vadim Gritsenko wrote:
>
>
>>Enke, Michael wrote:
>>
>>
>>
>>>I forgot one important detail:
>>>This happens only if tomcat was restarted or if the xsp-file changed on disk.
>>>The second and all follwing requests come out super fluid,
>>>even if I use noncaching pipeline.
>>>
>>>
>>>
>>What makes you think this is not normal garbage collection cycle?
>>
>>
>
>That would mean cocoon cann't serve complex xsp's with more than
>
Why can't? You said that there is delay, that's it. So, it can, but with
delay, and only after XSP is modified (AFAIU). What's wrong with it,
especially if it is garbage collector cleaning up compilation trees and
variables?
Vadim
>10,000 elements generated!!! This would be bad.
>I also set <parameter name="threadpriority" value="5"/> to 1 or to 10,
>nothing different.
>
>Michael
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: 2: Please help! Caching or Threadproblem or what else?
Posted by "Enke, Michael" <mi...@wincor-nixdorf.com>.
Vadim Gritsenko wrote:
>
> Enke, Michael wrote:
>
> >I forgot one important detail:
> >This happens only if tomcat was restarted or if the xsp-file changed on disk.
> >The second and all follwing requests come out super fluid,
> >even if I use noncaching pipeline.
> >
>
> What makes you think this is not normal garbage collection cycle?
That would mean cocoon cann't serve complex xsp's with more than
10,000 elements generated!!! This would be bad.
I also set <parameter name="threadpriority" value="5"/> to 1 or to 10,
nothing different.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: 2: Please help! Caching or Threadproblem or what else?
Posted by Vadim Gritsenko <va...@verizon.net>.
Enke, Michael wrote:
>I forgot one important detail:
>This happens only if tomcat was restarted or if the xsp-file changed on disk.
>The second and all follwing requests come out super fluid,
>even if I use noncaching pipeline.
>
What makes you think this is not normal garbage collection cycle?
Vadim
>Regards,
>Michael
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org