Nate, We started in your configuration, but are currently configured per the document you attached and continue tweaking it per direction from BMC support. Our hope was it would improve performance AND clear the lock issue, but the lock problem seems more solid in this configuration. Now when the problem occurs, we have to restart arsystem on both servers to clear it. Before it only seemed to affect the secondary server.
On your questions, the account Remedy is running under is in the Administrators group on each server. Both servers have been restarted repeatedly as configurations change. I don't like having the primary as the single point of failure, but I'm not fond of performance issues either. Right now we're just trying to find something that works. Luckily we are still testing in QA and working towards an early July go-live so still have a little time to test. I just got off the phone with support and will be testing some changes tonight. More tomorrow... Thanks! Dennis Nathan Aker <nathan_a...@mcafee.com> Sent by: "Action Request System discussion list(ARSList)" <arslist@ARSLIST.ORG> 05/31/2012 10:22 AM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: 7.6.04 Full Text Search problems ** Dennis, we?re running 7.6.04 in a server group against a shared FTS collection directory. While we have had to do a lot of tuning related to plugin server performance, we?re not seeing the error you have below. A few things to validate: 1. Do you have the collection directories setup on a shared drive, with both servers pointed at the share? 2. Do you have Remedy running under a user account that also has full write access to the shared drive where the FTS collection directories are housed? 3. Did you restart both ARS servers after repointing to the share? This config is working for us, though we are facing some performance issues. We are currently evaluating the attached config changes document which effectively relocates the FTS plugin from each server in the server group to one primary server. While I?m not a fan of the fact that it basically creates a single point of failure and negates the benefits of the server group in regards to the FTS function, it is BMC?s latest recommendation to us and may get you past the locking issue as it would make all FTS plugins run on the same server. I?m happy to review any deeper configuration questions with you on this based on our experience. We?ve had to tinker a lot with FTS so I?m painfully aware of the details of our environment in this respect. Thanks. Nate. Nathan Aker ITSM Solution Architect McAfee, Inc. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Dennis Ruble Sent: Thursday, May 31, 2012 9:46 AM To: arslist@ARSLIST.ORG Subject: 7.6.04 Full Text Search problems ** Listers, We are trying to get 7.6.04 running and are having problems with Full Text Search(FTS). We have our arsystem servers(Windows 2008 R2) in a server group and are experiencing write lock errors: FTSPlugin::initializeSearchService - Error initializing the FTSService:com.bmc.arsys.fts.impl.lucene.LuceneFTSService getIndexWriter: Error getting index writer Root Exception: Lock obtain timed out: NativeFSLock@\\crntarsqa01\collection\write.lock: java (ARERR 875) We've been working this for many weeks with BMC and have tried several different configurations with no apparent progress. I've also read evidence of other customers reporting the same issue. My questions for you are: 1. Is anyone successfully running FTS in ITSM 7.6.04 on Windows 2008 R2 in a server group? (Works fine on single server) 2. If you experienced the same error we have, did you find a fix? Any help/suggestions would be appreciated. Regards, Dennis Ruble Rockwell Collins _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ [attachment "Configuring FTS for performance in a server group.docx" deleted by Dennis D Ruble/CedarRapids/RockwellCollins] _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
