Yep - otherwise it would be a nightmare - as have had other server issues - this show is MUCH bigger than our previous one and we are learning a lot about what you DO need in a server now.
Hope you sort it out. Cheers Sandy _____________________________ Sandy Sutherland Technical Supervisor [email protected] _____________________________ ________________________________ From: [email protected] [[email protected]] on behalf of Martin Chatterjee [[email protected]] Sent: 22 June 2012 15:40 To: [email protected] Subject: Re: workgroup access collisions - xsibatch displays graphical MessageBox waiting for user input... Sandy, yeah, the problem appears only appears on our farm nodes still running XP. Windows 7 seems to be fine and I'm quite confident that no linux executable will ever show such a bizarre behaviour... :-/ Nonetheless the chance of getting such a collision should be fairly small anyway (unless your workgroup lives on a file server that does not perform well with loads of read calls on loads of tiny files at the same time - and a lot of blades are starting to render more or less simultaniously...) Cheers, Martin -- Martin Chatterjee [ Freelance Technical Director ] [ http://www.chatterjee.de ] On Fri, Jun 22, 2012 at 1:50 PM, Sandy Sutherland <[email protected]<mailto:[email protected]>> wrote: We do not have this here - our setup is Win7 64 workstations with FC15 Farm nodes. S. _____________________________ Sandy Sutherland Technical Supervisor [email protected]<mailto:[email protected]> _____________________________ ________________________________ From: [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] on behalf of Martin Chatterjee [[email protected]<mailto:[email protected]>] Sent: 22 June 2012 13:36 To: [email protected]<mailto:[email protected]> Subject: Re: workgroup access collisions - xsibatch displays graphical MessageBox waiting for user input... Hi Stephen, thanks for confirming and bumping up the bug. Yeah, getting rid of the graphical messageBox would be key. Although personally I don't understand the reason for the whole locking mechanism in the first place - my tests indicate that self-installing scripted plugins living in Application/Plugins do not get locked that way, for instance... But I don't mind it at all as long as we can get rid of the messageBox(es). By the way, my gut feeling is that this might only an issue on XP 64 - I will try to repro on Windows 7 in a bit and will let you know. Thanks, Martin -- Martin Chatterjee [ Freelance Technical Director ] [ http://www.chatterjee.de ] On Fri, Jun 22, 2012 at 1:26 PM, Stephen Blair <[email protected]<mailto:[email protected]>> wrote: Hi Martin Yes, this has been reported and logged before. I repro it simply by starting many xsibatch sessions, eventually you'll get an Unable to access error. It could be for a compound, or for a toolbar, or some other file. I'll log it again to bump it back up. At the very least, xsibatch should not display a message requiring use interaction. Stephen Blair Softimage Support Specialist Premium Support Services Autodesk, Inc. Montreal, Quebec, Canada Blog: http://xsisupport.com From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Martin Chatterjee Sent: June-22-12 7:19 AM To: [email protected]<mailto:[email protected]> Subject: workgroup access collisions - xsibatch displays graphical MessageBox waiting for user input... Hi List, hi Support, we are experiencing a bit of an annoying issue regarding access collisions on workgroups. Bear with me - it'll take a few lines to explain: When a workgroup is loaded (or refreshed from within an open Softimage session) its subdirectories get scanned and all self-installing plugins, shaders and ICE compounds get registered accordingly. During this scan Softimage will take over exclusive access for every ICE compound in /Data/Compounds. It will do this by creating a .lock file (e.g. MyCompound.xsicompound.lock) to prevent collisions. Under normal circumstances this lock file will be deleted straight after file scan and this lock should only be present for a veeery short time ( < 1ms or so...). However if a second session of Softimage tries to access a locked compound the user will get prompted by a messageBox that the compound is not accessible. He can then choose to ignore it and proceed. Through a series of VERY annoying circumnstances (dont't get me started... ) these workgroup scans are quite slow on our side right now resulting in quite a few collisions on a regular basis. And here's our problem: Even an xsibatch session (!!!!) will display the same UI messagebox and will wait until eternity for a user to interact with it. (see attached screenshot) This is on our blades running Windows XP 64 (yeah, I know...) In my humble opinion this is a bug and should be solved - a headless command line application such as xsibatch should NEVER popup graphical messageboxes and wait for user interaction... To make matters worse a xsibatch process controlled through a Renderfarm management software that exists as a windows service will not even display the bloody messagebox (as windows services cannot have desktop UI interaction). Instead the process will sit there forever with 0% CPU load waiting for a mouse klick. Just a heads up to any other poor souls out there that might have experienced this as well... And please, if anybody from Autdoesk is still reading: I'd love to get feedback if you can repro and fix this. Thanks in advance. Thanks, Martin --- REPRO STEPS: ----------- (Softimage 2012 SAP x64 @ Windows XP 64 [latest Service Packs and patches] ) 1.) link a workgroup containing an .xsicompound file in /Data/Compounds 2.) close Softimage 3.) manually create a lock file and make sure the file handle is kept open ... thereby simulating the collision. (I did this using a few lines of python code in a shell (attached to this mail - please rename to 'lockFile.py' )) --> you should now have two files in /Data/Compounds: myWickedCompound.xsicompound myWickedCompound.xsicompound.lock 4.) Try to delete the lock file by hand in the Windows Explorer --> this should NOT work as the file handle is still in use. 5.) Now start an xsibatch session - simply executing 'xsibatch' in a softimage shell without arguments should be enough. 6.) There you are - after a few secs you will be get the graphical MessageBox waiting for a mouse klick (at least on Windows XP 64) -- Martin Chatterjee [ Freelance Technical Director ] [ http://www.chatterjee.de ]
