From: Whitney S. <wso...@gm...> - 2010-02-23 20:41:53
|
Thanks Jacob -- You might consider putting that information on your site as well. The reason I asked the question, Bernhard, is for performance reasons. Does your recommendation to "never change a running system" apply if the system is running (too) slowly? In any case, if the documentation on JMagick vs im4java were to be expanded to include the information in this thread, it may also be helpful to know what sort of performance gains can actually be expected. -Whitney On Tue, Feb 23, 2010 at 2:48 PM, Jacob Nordfalk <jac...@gm...>wrote: > First, let me stress that JMagick itself IS well tested and usable on a > server application. > > Of course there might be memory leaks (Ive asked 2 times on this list for > someone who knows IM internals better to check some calls that potentially > leaks memory, but noone reacted) but they are negligible for normal use. > > The real 'hazard' here is not JMagick. The hazard is keeping ImageMagick > and the libraries that it depends on as long-running processes. > > To give a concrete example, I have on my server application a problem > reading TIFF images. Evry 3 months or so the process crashes, I get a crash > report and the server app is automatically restarted. Its not cool, but its > bearable. Besides, the bug is not appearing in the Windows version, which is > used for 70 % of our servers. These servers are running rock stable and we > prefer to use the same versions on both platforms. > > This particular problem is not in JMagic, not even in ImageMagick, its a > memory bug in the Linux version of libtiff, which IM internally uses to read > TIFF files. The bug has been fixed years ago, but others have probably > appeared, an the app is running fine so I prefer to stay with this > well-known bug. > > ImageMagick is primarily used as a command line tool, not a long running > process. Same goes for the libraries it uses. libjpeg, libtiff and whatever > you compile in. Memory leaks are of course searched for, but its not > priority one. > > Depending on your usage pattern you might run into problems and you might > not. And it depends on evry library compiled into your binary and on IM > itself, of course. If I should throw out a number I'd say the chances are > 25% that you are unlucky (and this has nothing to do with the quality of > JMagick). If you have some simple and fixed pattern usage (f.ex you > generate PNG thumbnails out of TIFF and JPGs) Id say the risk is lower, > perhaps 10% of being unlucky. > > > The "JNI hazard" here is that if something you use (f.ex libtiff for > reading TIFF files) has a memory bug then it can make your whole JVM crash. > Thats of course frustrating and therefore its great to have im4java > around, which starts IM as an external process, so JVM crashes are avoided. > * * > Coolest thing would be if JMagick and im4java could have the same API so > it was easy to switch depending on luckyness. Ive asked the author > of im4java to attemt to be as compatible as possible, but as im4java is very > much different internally its limited how much can be done in that > direction. > > If you don't like the risk, stick to im4java. If your want optimal > performance give JMagick a try. > > And, its not JMagick that is buggy, its what it depends on (hereunder IM) > that is not always (memory) bug free on long running processes. > I also have never seen a mismatch between JMagick binary and ImageMagick > binaries leading to crashes. > > Maintainer of im4java, could you copy or link to this post to your > documentation, please? > > Yours, > Jacob Nordfalk > maintainer of JMagick > > > > 2010/2/23 Bob Friesenhahn <bfr...@si...> > > On Tue, 23 Feb 2010, Whitney Sorenson wrote: >> >> > Right, so at any point will this project hit a maturity level at >> > which this isn't considered a likely hazard? >> >> Given JMagick maturity, there are several primary hazards to consider >> >> - ImageMagick bugs. >> >> - Mismatch between JMagick binary and ImageMagick binaries. >> >> - Intentionally maligned image files which attempt to corrupt memory, >> or even inject executable code and cause it to be executed in the >> context of the Java runtime. >> >> The im4java approach avoids the risk of the Java runtime environment >> becoming corrupted, but ImageMagick itself could still be susceptible >> to bugs or attack. >> >> Bob >> -- >> Bob Friesenhahn >> bfr...@si..., >> http://www.simplesystems.org/users/bfriesen/ >> GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Jmagick-users mailing list >> Jma...@li... >> https://lists.sourceforge.net/lists/listinfo/jmagick-users >> > > > > -- > Jacob Nordfalk > एस्पेरान्तो के हो? http://www.esperanto.org.np/. > Memoraĵoj de KEF -. http://kef.saluton.dk/memorajoj/ > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Jmagick-users mailing list > Jma...@li... > https://lists.sourceforge.net/lists/listinfo/jmagick-users > > |