Thread: [Ginp-developers] BUG :-(
Brought to you by:
burchbri,
dougculnane
Menu
▾
▴
ginp-developers
|
From: Doug C. <do...@cu...> - 2005-01-24 17:56:17
Attachments:
smime.p7s
|
I think I have another silly mistake in my code (or it is a URL EnCode
DeCode problem) :
2005-01-24 18:21:14 StandardWrapperValve[ginp Picture Servlet]: Servlet.service() for servlet ginp Picture Servlet threw exception
javax.servlet.ServletException: Servlet execution threw an exception
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:536)
----- Root Cause -----
java.lang.OutOfMemoryError
Generated by:
http://culnane.navidat.com/dc/moth/ginpservlet?cmd=showpicture&colid=0&path=%2FBoats+and+Builds%2F&name=DSC07655.JPG
I will try to fix this ASAP (and release again...) but I have to go now,
so I am posting this to the list to see if the magic fairies do it for me...
All the best,
Doug
--
Doug Culnane
do...@cu...
www.culnane.net
|
|
From: Doug C. <do...@cu...> - 2005-01-24 18:05:43
Attachments:
smime.p7s
|
Bug fixed by reloading Web Application! Very wired.... But forget it unless you get the same problem: It may have been a browser cache thing with some old link encodings....? Got to go. Doug Doug Culnane wrote: > I think I have another silly mistake in my code (or it is a URL EnCode > DeCode problem) : > > 2005-01-24 18:21:14 StandardWrapperValve[ginp Picture Servlet]: > Servlet.service() for servlet ginp Picture Servlet threw exception > javax.servlet.ServletException: Servlet execution threw an exception > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) > > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) > > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) > > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) > > at > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) > > at > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) > > at > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) > > at > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) > at > org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415) > > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) > > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) > > at > org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171) > > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) > > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) > > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) > > at > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) > > at > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) > > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) > > at > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) > > at > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) > at > org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594) > > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392) > > at > org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565) > > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619) > > at java.lang.Thread.run(Thread.java:536) > ----- Root Cause ----- > java.lang.OutOfMemoryError > > > > Generated by: > http://culnane.navidat.com/dc/moth/ginpservlet?cmd=showpicture&colid=0&path=%2FBoats+and+Builds%2F&name=DSC07655.JPG > > > I will try to fix this ASAP (and release again...) but I have to go > now, so I am posting this to the list to see if the magic fairies do > it for me... > > All the best, > > Doug > > -- Doug Culnane do...@cu... www.culnane.net |
|
From: Doug C. <do...@cu...> - 2005-01-24 18:08:33
Attachments:
smime.p7s
|
It is still there: http://culnane.navidat.com/dc/ginppic?path=%2FBoats+and+Builds%2F&name=DSC07655.JPG&height=647 -- Doug Culnane do...@cu... www.culnane.net |
|
From: Justin <ju...@sq...> - 2005-01-25 09:56:56
|
Doug Culnane wrote: > > It is still there: > http://culnane.navidat.com/dc/ginppic?path=%2FBoats+and+Builds%2F&name=DSC07655.JPG&height=647 > > > Doug, I think you're running out of memory because of the height parameter. If you remove it it runs fine. Just click on the link below to see what I mean. http://culnane.navidat.com/dc/ginppic?path=%2FBoats+and+Builds%2F&name=DSC07655.JPG I looked at the code and when the height is on you have to take a 500k compressed image, decompress it and make another copy of it transformed. This is a very memory intensive operation. When you don't put the height parameter on it you can just stream it off of the disk a byte at a time and this works fine. Regards, Justin |
|
From: Doug C. <do...@cu...> - 2005-01-25 18:07:59
Attachments:
smime.p7s
|
I could not reproduce this error locally only on my live webserver (which has been up 495 days). The tomcat server has been running a few months and so I stopped and started it. The problem was fixed once it started. Therefore I think that this is not really a ginp problem. The resizing of images is a big computing tasks but it is needed to make the application preform well (or at all) on low bandwidth connections. The resize is fast on a server and only one image is resized at a time. The thumbnails come from the disk and are made once by a background thread. Therefore a test gallery of 1000 pic will not make a big difference. I think that the culnane.navidat.com webserver just got in a bad state. If it happens again I will try to increase the memory tomcat used at start up. If you think I have missed something serious then let me know. All the best, Doug Justin wrote: > Doug Culnane wrote: > >> >> It is still there: >> http://culnane.navidat.com/dc/ginppic?path=%2FBoats+and+Builds%2F&name=DSC07655.JPG&height=647 >> >> >> > > Doug, > > I think you're running out of memory because of the height > parameter. If you remove it it runs fine. Just click on the link > below to see what I mean. > > http://culnane.navidat.com/dc/ginppic?path=%2FBoats+and+Builds%2F&name=DSC07655.JPG > > > I looked at the code and when the height is on you have to take a 500k > compressed image, decompress it and make another copy of it > transformed. This is a very memory intensive operation. When you > don't put the height parameter on it you can just stream it off of the > disk a byte at a time and this works fine. > > Regards, > > Justin > > > -- Doug Culnane do...@cu... www.culnane.net |
|
From: Justin <ju...@ww...> - 2005-01-25 20:08:58
|
I think making thumbnails is a good idea. However, this kind of per request image scaling is going to use a lot of memory and cpu and can be just as easily be done on the client at the cost of slightly more bandwidth. On Tue, 25 Jan 2005 10:01, Justin wrote: > I looked at the code and when the height is on you have to take a 500k > compressed image, decompress it and make another copy of it > transformed. This is a very memory intensive operation. When you > don't put the height parameter on it you can just stream it off of the > disk a byte at a time and this works fine. > > Regards, > > Justin > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Ginp-developers mailing list > Gin...@li... > https://lists.sourceforge.net/lists/listinfo/ginp-developers |
|
From: Doug C. <do...@cu...> - 2005-01-26 08:47:36
Attachments:
smime.p7s
|
Before you reply who has a 44kbps modem? I do. Also there is no reason why we can not do a style for mobile phones etc... that have a bandwidth problem..... Doug Doug Culnane wrote: > I used to do this in version 0.10 I think but it was madness. 4MB > over a 44kbps line to resize to 300px height is bad. Let the sever > work. We could store a middle size thumb and resize that which will > save bandwidth and cpu/mem. > Doug > > > Justin wrote: > >> >> I think making thumbnails is a good idea. However, this kind of per >> request image scaling is going to use a lot of memory and cpu and can >> be just as easily be done on the client at the cost of slightly more >> bandwidth. >> >> On Tue, 25 Jan 2005 10:01, Justin wrote: >> >>> I looked at the code and when the height is on you have to take a >>> 500k compressed image, decompress it and make another copy of it >>> transformed. This is a very memory intensive operation. When >>> you don't put the height parameter on it you can just stream it off >>> of the disk a byte at a time and this works fine. >>> >>> Regards, >>> >>> Justin >>> >>> >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >>> Tool for open source databases. Create drag-&-drop reports. Save time >>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl >>> _______________________________________________ >>> Ginp-developers mailing list >>> Gin...@li... >>> https://lists.sourceforge.net/lists/listinfo/ginp-developers >> >> >> > > -- Doug Culnane do...@cu... www.culnane.net |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X