Re: error in html serialization
Please try it by yourself, be my guest. http://77.240.21.139/cocoon/asemakaavat/selitykset/A4/Karsamaki/Kirkonseutu/01.html Open it and refresh it over ten times. It should crash. Then refresh it over ten times again and suprise, it works again! Any ideas? mika Lehtonen, Mika kirjoitti: Hello, I have an application which uses html serializer. It is a little complicated system to describe in this. Anyway the pipeline works and of some xml and a bunch of gifs is parsed a working html, but then we come to the strange part. It works eleven times, crashes eleven times and continues doing that. I can verify that even with using refresh button on the browser. Cocoon is 2.1.11 and first I get this error and after that the latter one. Any ideas? mika - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error in html serialization
Hi Mika, I can confirm this, although it did not crash after 11 times, but about 15 ... whatever, can you please - provide the pipeline that generates this error - set pool-max and pool-min for all involved components to 1 in sitemap.xmap, restart cocoon and tell us what happens? Regards, Johannes Lehtonen, Mika wrote: Please try it by yourself, be my guest. http://77.240.21.139/cocoon/asemakaavat/selitykset/A4/Karsamaki/Kirkonseutu/01.html Open it and refresh it over ten times. It should crash. Then refresh it over ten times again and suprise, it works again! Any ideas? mika Lehtonen, Mika kirjoitti: Hello, I have an application which uses html serializer. It is a little complicated system to describe in this. Anyway the pipeline works and of some xml and a bunch of gifs is parsed a working html, but then we come to the strange part. It works eleven times, crashes eleven times and continues doing that. I can verify that even with using refresh button on the browser. Cocoon is 2.1.11 and first I get this error and after that the latter one. Any ideas? mika - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error in html serialization
Hi Johannes,
here is the pipeline. I set those parameters to
imagedirectory-generator, xslt-transformer and to html-serializer. I
found no change comparing to previous action.
mika
map:match pattern=selitykset/*/*/*/*.html
map:generate type=imagedirectory src=selitykset/{2}/{3}/{4}
map:parameter name=depth value=2/
map:parameter name=root value={2}/
/map:generate
map:transform src=selitykset/{2}/xml2html.xsl/
map:serialize type=html/
/map:match
Johannes Textor kirjoitti:
Hi Mika,
I can confirm this, although it did not crash after 11 times, but
about 15 ... whatever, can you please
- provide the pipeline that generates this error
- set pool-max and pool-min for all involved components to 1 in
sitemap.xmap, restart cocoon and tell us what happens?
Regards,
Johannes
Lehtonen, Mika wrote:
Please try it by yourself, be my guest.
http://77.240.21.139/cocoon/asemakaavat/selitykset/A4/Karsamaki/Kirkonseutu/01.html
Open it and refresh it over ten times. It should crash. Then refresh
it over ten times again and suprise, it works again! Any ideas?
mika
Lehtonen, Mika kirjoitti:
Hello,
I have an application which uses html serializer. It is a little
complicated system to describe in this. Anyway the pipeline works
and of some xml and a bunch of gifs is parsed a working html, but
then we come to the strange part. It works eleven times, crashes
eleven times and continues doing that. I can verify that even with
using refresh button on the browser. Cocoon is 2.1.11 and first I
get this error and after that the latter one. Any ideas?
mika
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: error in html serialization
Some further information:
I have also this pipeline which produces pdfs' out of the same material.
It has been functioning for a long time and still does, BUT if the html
producers crashes, this won't work either.
map:match pattern=selitykset/*/*/*/*.pdf
map:generate type=imagedirectory src=selitykset/{2}/{3}/{4}
map:parameter name=depth value=2/
map:parameter name=root value={2}/
/map:generate
map:transform src=selitykset/{2}/{1}-pdf.xsl/
map:serialize type=fo2pdf/
/map:match
You can try it out at:
http://77.240.21.139/cocoon/asemakaavat/selitykset/A4p/Karsamaki/Kirkonseutu/01.pdf
mika
Lehtonen, Mika kirjoitti:
Hi Johannes,
here is the pipeline. I set those parameters to
imagedirectory-generator, xslt-transformer and to html-serializer. I
found no change comparing to previous action.
mika
map:match pattern=selitykset/*/*/*/*.html
map:generate type=imagedirectory src=selitykset/{2}/{3}/{4}
map:parameter name=depth value=2/
map:parameter name=root value={2}/
/map:generate
map:transform src=selitykset/{2}/xml2html.xsl/
map:serialize type=html/
/map:match
Johannes Textor kirjoitti:
Hi Mika,
I can confirm this, although it did not crash after 11 times, but
about 15 ... whatever, can you please
- provide the pipeline that generates this error
- set pool-max and pool-min for all involved components to 1 in
sitemap.xmap, restart cocoon and tell us what happens?
Regards,
Johannes
Lehtonen, Mika wrote:
Please try it by yourself, be my guest.
http://77.240.21.139/cocoon/asemakaavat/selitykset/A4/Karsamaki/Kirkonseutu/01.html
Open it and refresh it over ten times. It should crash. Then refresh
it over ten times again and suprise, it works again! Any ideas?
mika
Lehtonen, Mika kirjoitti:
Hello,
I have an application which uses html serializer. It is a little
complicated system to describe in this. Anyway the pipeline works
and of some xml and a bunch of gifs is parsed a working html, but
then we come to the strange part. It works eleven times, crashes
eleven times and continues doing that. I can verify that even with
using refresh button on the browser. Cocoon is 2.1.11 and first I
get this error and after that the latter one. Any ideas?
mika
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: error in html serialization
Hi Johannes,
yep, Java is 1.6.0_04 (Java Hotspot 64-bit Server VM). OS is 64-bit
Centos 4.3.
I will still do the testing you recommended and report about them when
they done. Ok? I am not an expert on these programming and Java issues.
Do you mean that some earlier Java would do better or do I have to do
some tuning?
Thanks,
mika
Johannes Textor kirjoitti:
Hi Mika,
am I guessing right that you are using Java 1.6?
The NullPointerException means that This abstract pathname does not
denote a directory, or if an I/O error occurs (quote from Java spec).
Maybe you're running out of file handles ... which operating system are
you using?
Also, if you set up two minimal test pipeline like this:
map:match pattern=test.xml
map:generate type=imagedirectory src=some_dir /
map:serialize type=xml /
/map:match
and like this:
map:match pattern=test.xml
map:generate type=imagedirectory src=some_dir
map:parameter name=depth value=2 /
/map:generate
map:serialize type=xml /
/map:match
does the same error occur in both / one of these pipelines?
Regards,
Johannes
Lehtonen, Mika schrieb:
Some further information:
I have also this pipeline which produces pdfs' out of the same
material. It has been functioning for a long time and still does, BUT
if the html producers crashes, this won't work either.
map:match pattern=selitykset/*/*/*/*.pdf
map:generate type=imagedirectory src=selitykset/{2}/{3}/{4}
map:parameter name=depth value=2/
map:parameter name=root value={2}/
/map:generate
map:transform src=selitykset/{2}/{1}-pdf.xsl/
map:serialize type=fo2pdf/
/map:match
You can try it out at:
http://77.240.21.139/cocoon/asemakaavat/selitykset/A4p/Karsamaki/Kirkonseutu/01.pdf
mika
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: error in html serialization
Hi Mika,
am I guessing right that you are using Java 1.6?
The NullPointerException means that This abstract pathname does not
denote a directory, or if an I/O error occurs (quote from Java spec).
Maybe you're running out of file handles ... which operating system are
you using?
Also, if you set up two minimal test pipeline like this:
map:match pattern=test.xml
map:generate type=imagedirectory src=some_dir /
map:serialize type=xml /
/map:match
and like this:
map:match pattern=test.xml
map:generate type=imagedirectory src=some_dir
map:parameter name=depth value=2 /
/map:generate
map:serialize type=xml /
/map:match
does the same error occur in both / one of these pipelines?
Regards,
Johannes
Lehtonen, Mika schrieb:
Some further information:
I have also this pipeline which produces pdfs' out of the same
material. It has been functioning for a long time and still does, BUT
if the html producers crashes, this won't work either.
map:match pattern=selitykset/*/*/*/*.pdf
map:generate type=imagedirectory src=selitykset/{2}/{3}/{4}
map:parameter name=depth value=2/
map:parameter name=root value={2}/
/map:generate
map:transform src=selitykset/{2}/{1}-pdf.xsl/
map:serialize type=fo2pdf/
/map:match
You can try it out at:
http://77.240.21.139/cocoon/asemakaavat/selitykset/A4p/Karsamaki/Kirkonseutu/01.pdf
mika
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: error in html serialization
Hi Mika,
while trying again on your site, this time I got the following error:
/home/cocoon/tomcat/webapps/cocoon/stylesheets/system/exception2html.xslt
(Too many open files)
This I think confirms my theory that your application generates too many
file handles, or that file handles remain open too long after they are
used by Java. I think it is an issue specific to your OS/JVM
configuration, since I cannot reproduce this problem here (on 32 bit
Ubuntu using JVM 1.5). You can find out how many files are being kept
open by typing the following command:
lsof | grep java
or
lsof | grep java | grep selitykset
If I'm right, then the second command should reveal that (too) many file
handles are left open. Maybe it takes some time for the OS to close
them, or maybe the garbage collector needs to come around to close the
handles - unfortunately, I do not know too much about how Java deals
with file system specific file handles internally.
Of course you could try to increase the max. open files limit for the
tomcat user, but it would probably be nicer to know while so many files
are opened in the first place. Can you try to find out more by using the
commands above?
Regards,
Johannes
Lehtonen, Mika schrieb:
Hi Johannes,
yep, Java is 1.6.0_04 (Java Hotspot 64-bit Server VM). OS is 64-bit
Centos 4.3.
I will still do the testing you recommended and report about them when
they done. Ok? I am not an expert on these programming and Java
issues. Do you mean that some earlier Java would do better or do I
have to do some tuning?
Thanks,
mika
Johannes Textor kirjoitti:
Hi Mika,
am I guessing right that you are using Java 1.6?
The NullPointerException means that This abstract pathname does not
denote a directory, or if an I/O error occurs (quote from Java spec).
Maybe you're running out of file handles ... which operating system are
you using?
Also, if you set up two minimal test pipeline like this:
map:match pattern=test.xml
map:generate type=imagedirectory src=some_dir /
map:serialize type=xml /
/map:match
and like this:
map:match pattern=test.xml
map:generate type=imagedirectory src=some_dir
map:parameter name=depth value=2 /
/map:generate
map:serialize type=xml /
/map:match
does the same error occur in both / one of these pipelines?
Regards,
Johannes
Lehtonen, Mika schrieb:
Some further information:
I have also this pipeline which produces pdfs' out of the same
material. It has been functioning for a long time and still does, BUT
if the html producers crashes, this won't work either.
map:match pattern=selitykset/*/*/*/*.pdf
map:generate type=imagedirectory src=selitykset/{2}/{3}/{4}
map:parameter name=depth value=2/
map:parameter name=root value={2}/
/map:generate
map:transform src=selitykset/{2}/{1}-pdf.xsl/
map:serialize type=fo2pdf/
/map:match
You can try it out at:
http://77.240.21.139/cocoon/asemakaavat/selitykset/A4p/Karsamaki/Kirkonseutu/01.pdf
mika
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: error in html serialization
Sorry ... as I think of it, maybe you should use the less braindead command lsof -p [id] where [id] is the id of the process which actually runs cocoon. Johannes Textor schrieb: Hi Mika, while trying again on your site, this time I got the following error: /home/cocoon/tomcat/webapps/cocoon/stylesheets/system/exception2html.xslt (Too many open files) This I think confirms my theory that your application generates too many file handles, or that file handles remain open too long after they are used by Java. I think it is an issue specific to your OS/JVM configuration, since I cannot reproduce this problem here (on 32 bit Ubuntu using JVM 1.5). You can find out how many files are being kept open by typing the following command: lsof | grep java or lsof | grep java | grep selitykset If I'm right, then the second command should reveal that (too) many file handles are left open. Maybe it takes some time for the OS to close them, or maybe the garbage collector needs to come around to close the handles - unfortunately, I do not know too much about how Java deals with file system specific file handles internally. Of course you could try to increase the max. open files limit for the tomcat user, but it would probably be nicer to know while so many files are opened in the first place. Can you try to find out more by using the commands above? Regards, Johannes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error in html serialization
Johannes, after the crash, there are 1067 open files, and when you wait for a while, the amount drops into 113. Everything is then working. Or if I push 'refresh'-button so many times that the site works again, the amount of files drops into 196. Every time the page is loaded again, extra 82 files is opened until the 1000 limit is exceeded. So it seems that you're right, but what to do to it? If I do garbage collection manually, page starts to function. And it seems that the problem occurs only with xslt transformer and html serializer. Those test pipelines don't leave files open. Also my pdf pipeline works fine. Is it possible you to test pipelines with xslt transformer and html serializer? I mean if it would also left old files open after reloading. mika Johannes Textor kirjoitti: Sorry ... as I think of it, maybe you should use the less braindead command lsof -p [id] where [id] is the id of the process which actually runs cocoon. Johannes Textor schrieb: Hi Mika, while trying again on your site, this time I got the following error: /home/cocoon/tomcat/webapps/cocoon/stylesheets/system/exception2html.xslt (Too many open files) This I think confirms my theory that your application generates too many file handles, or that file handles remain open too long after they are used by Java. I think it is an issue specific to your OS/JVM configuration, since I cannot reproduce this problem here (on 32 bit Ubuntu using JVM 1.5). You can find out how many files are being kept open by typing the following command: lsof | grep java or lsof | grep java | grep selitykset If I'm right, then the second command should reveal that (too) many file handles are left open. Maybe it takes some time for the OS to close them, or maybe the garbage collector needs to come around to close the handles - unfortunately, I do not know too much about how Java deals with file system specific file handles internally. Of course you could try to increase the max. open files limit for the tomcat user, but it would probably be nicer to know while so many files are opened in the first place. Can you try to find out more by using the commands above? Regards, Johannes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error in html serialization
Thanks for your help Johannes! I believe I found the reason. I had type=noncaching definition in my pipeline. I removed it and now it seems to working without errors. Try it out yourself. mika Johannes Textor kirjoitti: Sorry ... as I think of it, maybe you should use the less braindead command lsof -p [id] where [id] is the id of the process which actually runs cocoon. Johannes Textor schrieb: Hi Mika, while trying again on your site, this time I got the following error: /home/cocoon/tomcat/webapps/cocoon/stylesheets/system/exception2html.xslt (Too many open files) This I think confirms my theory that your application generates too many file handles, or that file handles remain open too long after they are used by Java. I think it is an issue specific to your OS/JVM configuration, since I cannot reproduce this problem here (on 32 bit Ubuntu using JVM 1.5). You can find out how many files are being kept open by typing the following command: lsof | grep java or lsof | grep java | grep selitykset If I'm right, then the second command should reveal that (too) many file handles are left open. Maybe it takes some time for the OS to close them, or maybe the garbage collector needs to come around to close the handles - unfortunately, I do not know too much about how Java deals with file system specific file handles internally. Of course you could try to increase the max. open files limit for the tomcat user, but it would probably be nicer to know while so many files are opened in the first place. Can you try to find out more by using the commands above? Regards, Johannes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
