I should think there wouldn't be out-and-out blocking of the jars, since both the JVM and the virus scanner would open them for reading. However, I've seen virus scanners take long periods of time to look at large jars, which at the very least could cause disk contention.
Don On Tue, Nov 12, 2013 at 10:38 AM, Jack Ding <hding...@yahoo.com> wrote: > Hi Hadrian, > > Thanks for the quick response of my questions. Your suggestion is helpful. > By checking this issue further, I noticed that I should have mentioned that > we are using the OSGI bundles / Karaf to run the camel. Besides OSGI > bundles/karaf, we also have a numerous translator file ( xslt ) for which > the File component is used to read them. I am wondering: > > 1) Could the antivirus scan affects the OSGI bundles ( I assume that the > Karaf dynamically scan the files to see if the files are upadated for hot > deployment); > > 2) Whether the translator files are cached by Camel's File > component without repeately re-open / read / close, for example: > <to uri="xslt://file: dir/sub_dir/sub_dir/translator_file.xslt" /> > > Theorectically, would you think the Antivirus scan could cause blockage of > the files and OSGI bundle (*.jar)? > > > BTW. I noticed a comment about OSGI / antivirus in the item #72 of the > following link: > http://kirkk.com/main/pdf/BiggestObstaclesResponse.pdf, which describes: > Item #72: The biggest problems with any enterprise environment revolve > around integration > issues. Leveraging OSGi's strengths in modularity and versioning to > simplify > integration of existing systems would be a major selling point. > Slow startup time in an enterprise environment can be a problem, though not > necessarily caused by OSGi itself. Rather, the delayed startup is often > due to > aggressive scanning of zip files by antivirus solutions. Since OSGi > environments > consist of many jar (zip) files, the delay caused by real-time virus > scanners for > each of the zip files can get out of hand quickly. > > Would you think the above description is true? > > In the meantime, I would be doing some testing to see how it works. > > Best regards > > Jack > > > From: Hadrian Zbarcea <hzbar...@gmail.com> > To: users@camel.apache.org > Sent: Tuesday, November 12, 2013 8:26 AM > Subject: Re: Exclude Camel from Antivirus Scan? > > > Hi Jack, > > This is a Windows specific issue (as other OSes do not lock files). That > aside, you have a conflict between two tools that perform automatic > processing of files. Unless you manage to provide some sort of > synchronization you cannot avoid the problem. One way is to eliminate > one of the tools (the antivirus, by telling IT to exclude the Camel > folder). This is usually not wrong, depending on the kind of files you > use. There is a more complex solution that I believe would work that > involves defining a custom error handler [1] to ignore the errors caused > by locked files and possibly a redelivery policy [2]. Knowing what kind > of files you process, you're in the best position to decide which path > is better. > > I hope this helps, > Hadrian > > [1] http://camel.apache.org/error-handler.html > [2] http://camel.apache.org/redeliverypolicy.html > > > > On 11/12/2013 08:49 AM, Jack Ding wrote: > > Hello, > > > > The IT department is asking if it is necessary to exclude any of the > camel related folders/files to be scanned to avoid any impact on > performance, malfunction, etc. Does anybody have experience / suggestion > on Antivirus related issues on Camel and how to avoid them? > > > > It seems that Camel 2.1.0 release has mentoned one of the fix: > > > > The File component handles renaming and deleting files on Windows better > as Windows could block files. Also Antivirus software could causes files to > be blocked. > > > > Not sure if it is a good idea by just telling IT to exclude the Camel > related folders. Could you advise? > > > > Camel: 2.10.0 > > OS: Windows 2008 > > Antivirus Software: Symantec Endpoint 12.1 > > > > Thanks > > > > Jack > > >
