JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 086 contents | All Javva's articles

The Helpdesk

I log a message to the Helpdesk - my virus scanner has suddenly started scanning all .class files on every recompile, and my machine jerks to a shuddering halt more than half the time. I don't have sufficient admin control to reconfigure the virus scanner, so I have to resort to the Helpdesk. The Helpdesk gets back to me and confirms that this has now been enabled for all desktops. The Helpdesk closes the help ticket with a "we hope you were satisfied with our response - please rate the adequacy of this response here". The email closing the ticket was sent an hour after the Helpdesk confirmed the new scanning policy. Nothing done.

Open ticket number two on the new virus scanning policy. After another hour the Helpdesk calls back. "Yes, we can confirm that this new policy has been enacted." I am cut off immediately. Another hour passes and I receive the email that the ticket is closed. My rating of the adequacy of the response is severely negative. Carefully judged sarcasm is applied - sufficient to annoy all but the most thick skinned evaluator, but calm enough to avoid me getting some sort of reprimand from HR. I open ticket number three.

A couple of hours later, I get a call from the Helpdesk, responding to ticket number three. "In response to a number of queries on this issue, the virus scanner has now been configured to ignore all .class files under the Q:\dev tree". It seems like a positive development - okay, it took a few hours, but that's not so bad in my experience. I change my project to write .class files to the Q:\dev tree. It seems to have problems. I discover I have no access Q:\dev tree. It is the end of the day. Tomorrow is another day. Hopefully that is. If it's another "today", I may find my will to live severely curtailed.

I get in the next day to find ticket number three is closed. I open ticket number four. A couple of hours later, the helpdesk contacts me: "That is correct, write access under Q:\dev is disabled for workstations, as otherwise a virus could write there and the virus checker would not catch it, as it is configured to ignore certain file types there." The inevitable close of the ticket follows later. The logic is crystal clear, accurate and inevitable. I consider setting fire to my desktop. I write an email setting out the lineage of the Helpdesk from its glorious start as pond scum. I send the email to my cat. I open ticket number five.

By ticket number nine, I have established the capability to write .clozz files to a J:\data\dev_dev_ path which I am able to map to an arbitrary location on the C: drive. My more savvy underlings have already switched to running all compiles on unix servers, but I'm not one for giving up.

After just two more days I have complete return to the previous situation. My .class files, albeit in a different location, are now ignored by the virus scanner. That afternoon, scanning of .class files by the virus scanner is switched off globally, as it is determined that there is no necessity to do so. Another productive week.

Back to newsletter 086 contents