nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Anyone use TeamSite Search?

DevNetters -

Our configuration: two Linux VMs; one with TeamSite 7.3.2 / OpenDeploy Base, the other with OpenDeploy Admin and TeamSite Search.

Here's my question: does anyone successfully use TeamSite Search, at any release level on any platform?

Here's why I'm asking:
We worked for a couple of months with TeamSite Support to try to get the 7.3.1 version of Search working. That Support ticket ended up with pretty much the conclusion that 7.3.1 Search was unworkable for us and that we needed to upgrade to 7.3.2 Search.

So we did the upgrade to TeamSite and Search - we're now on the 7.3.2 version of both. The install / upgrade process went pretty smoothly.

Now, we're a month into another Support ticket trying to get the basic functionality of 7.3.2 Search working. We've gotten a lot further than we had with 7.3.1; occasionally we can successfully index a branch and perform a search on the indexed content.

However, we've run into a pile of other issues:
- When we try to stop and start the indexing process (iw.tsconnector it's called in 7.3.2), the indexing process doesn't seem to stop right away - it leaves the older process running in the job list for some indeterminate amount of time during which bringing the Indexer back creates an issue where it thinks we're already attached to Search. We need to wait a couple of hours to retry (the older versions of Indexer do eventually 'go away').

- In the Search UI, any query that takes over 30 seconds will time out and appear to fail to the user. In the background, that query still is processing and eventually is successful, but by then the session is no longer active and the user gets no results. We've messed with some config options to try to keep this communication open, but haven't been successful yet.

- If there's an error during the indexing process, sometimes we'll see a status of 'indexed' anyway. We see the results of this when we try to query a branch and get 'no results' when searching for either filenames or content that should have been indexed. In this case, we would like to be able to have some consistent process to 1) drop the index for the branch and 2) reindex the branch. Even after months of working with Support and testing this out, it still seems like a hit-and-miss process of guessing what processes need to be brought down and back up and what commands need to be executed at what particular time during this process.

And there's a handful more. You get the idea.

Given our experiences, I'm wondering if -anyone- has TeamSite Search running smoothly? Anybody? It would be good to have the peace of mind that it is possible to provide this functionality.

Find more posts tagged with

Comments

DevNetters -

Our configuration: two Linux VMs; one with TeamSite 7.3.2 / OpenDeploy Base, the other with OpenDeploy Admin and TeamSite Search.

Here's my question: does anyone successfully use TeamSite Search, at any release level on any platform?

Here's why I'm asking:
We worked for a couple of months with TeamSite Support to try to get the 7.3.1 version of Search working. That Support ticket ended up with pretty much the conclusion that 7.3.1 Search was unworkable for us and that we needed to upgrade to 7.3.2 Search.

So we did the upgrade to TeamSite and Search - we're now on the 7.3.2 version of both. The install / upgrade process went pretty smoothly.

Now, we're a month into another Support ticket trying to get the basic functionality of 7.3.2 Search working. We've gotten a lot further than we had with 7.3.1; occasionally we can successfully index a branch and perform a search on the indexed content.

However, we've run into a pile of other issues:
- When we try to stop and start the indexing process (iw.tsconnector it's called in 7.3.2), the indexing process doesn't seem to stop right away - it leaves the older process running in the job list for some indeterminate amount of time during which bringing the Indexer back creates an issue where it thinks we're already attached to Search. We need to wait a couple of hours to retry (the older versions of Indexer do eventually 'go away').

- In the Search UI, any query that takes over 30 seconds will time out and appear to fail to the user. In the background, that query still is processing and eventually is successful, but by then the session is no longer active and the user gets no results. We've messed with some config options to try to keep this communication open, but haven't been successful yet.

- If there's an error during the indexing process, sometimes we'll see a status of 'indexed' anyway. We see the results of this when we try to query a branch and get 'no results' when searching for either filenames or content that should have been indexed. In this case, we would like to be able to have some consistent process to 1) drop the index for the branch and 2) reindex the branch. Even after months of working with Support and testing this out, it still seems like a hit-and-miss process of guessing what processes need to be brought down and back up and what commands need to be executed at what particular time during this process.

And there's a handful more. You get the idea.

Given our experiences, I'm wondering if -anyone- has TeamSite Search running smoothly? Anybody? It would be good to have the peace of mind that it is possible to provide this functionality.

In a nutshell, no. We have gone through the same pains with Autonomy support just to learn that we need to migrate to 7.3.2. You may check out a post that i had put up a few months ago while trying to develop a custom application based on TS search and CSSDK. Some good insights into do's and donts...
http://devnet.interwoven.com/forums_vb/showthread.php?t=37997

In a nutshell, no. We have gone through the same pains with Autonomy support just to learn that we need to migrate to 7.3.2. You may check out a post that i had put up a few months ago while trying to develop a custom application based on TS search and CSSDK. Some good insights into do's and donts...
http://devnet.interwoven.com/forums_vb/showthread.php?t=37997

This thread you reference doesn't really have anything to do with Wally's issues in 7.3.2, which is a version of Search that Interwoven has hyped will be a significant improvement over all past Idol integrations with TeamSite. I've been working with Interwoven Support for over a year trying to get Search to work as anyone would expect it to - it's beyond shocking that it's taken this long for it to happen. We've been assured that 7.3.2 Search will be the solution to all of our problems, so it's really dismaying to see there are significant problems with the product.

I passed on Wally's post to my direct IW Support contact to get some answers. So far just crickets. I am planning an upgrade to 7.3.2 in the next few weeks and will share my experience with Search in this thread.

Cobra_Letters1.rptdesign

An update for you all:

We continue to work with Support on this 7.3.2 Search issue. The other day, we did a tape recovery test on our TeamSite repository (successful) and after that we couldn't get the indexing process to work any longer. Rather than beat the dead horse and figure that one out, I'm starting over fresh to try to get it to work.

Up until now on this ticket, it seems we've analyzed various issues without making much progress, so we've reorganized the ticket into 5 deliverables:

1) Start over.
By that I mean to clear out all indexing artifacts and start fresh. I just finished that today and so far, so good.

2) Perform an initial indexing of a set of branches in TeamSite.
In this step I want to -fully- control what branches are indexed by maintaining the list with the branches.cfg file - not via CLTs to individually add and remove branches. This is what I'm working on now.

3) Add a branch to the indexing process.
Once #2 is up and either processing or complete, I'd like to add a branch to the mix. Once again - I want to do this by adding an entry to branches.cfg and then having the processes pick up the entry.

4) Drop a branch from the indexing process.
Like #3, but based on removing an entry from branches.cfg.

5) Reindex a branch.
Speaks for itself.

If I can figure out the machinations of performing the above, I feel like we'll have a handle on managing the indexing process.

So far, I have failed over and over (and this is the crux of this work) with understanding what needs to be stopped and started in what order to get this to work.

If I just stop and start the idol, Indexer and Search processes in what I think is the logical order to pick up a change in branches.cfg, more often than not I'll end up with some connection issue between the 3 processes ('idol is not available, or Search is already connected). Sometimes there seems to be nothing to do but wait (sometimes several hours) before some timeout enables me to start again.

If indexing starts during one of these inconsistent states, sometimes it will fail to index a branch, yet report that it's indexed. This results in incorrect results being returned in a search by the users. As far as I can tell, this condition can only be detected by scanning logs.

A comment to Smitty77: When everything's lined up, 7.3.2 has enabled us to successfully index content that we couldn't with 7.3.1. So, in that regard, 7.3.2 is a big improvement.

We've had no luck with TeamSite search. I've disabled the service...

This thread you reference doesn't really have anything to do with Wally's issues in 7.3.2, which is a version of Search that Interwoven has hyped will be a significant improvement over all past Idol integrations with TeamSite. I've been working with Interwoven Support for over a year trying to get Search to work as anyone would expect it to - it's beyond shocking that it's taken this long for it to happen. We've been assured that 7.3.2 Search will be the solution to all of our problems, so it's really dismaying to see there are significant problems with the product.

I passed on Wally's post to my direct IW Support contact to get some answers. So far just crickets. I am planning an upgrade to 7.3.2 in the next few weeks and will share my experience with Search in this thread.

Right! Thanks~!

Hi Walib,

We are also going to use TeamSite Search 7.3.2 on windows platform. Please keep us posted here on the resolution of your search issues.

I wanted to keep this thread alive since upgrading to 7.3.2 Search has not been a trivial process for me and I assume others will have similar issues. Initially after upgrading and getting the Indexer to finish indexing a branch, we discovered that Search would not return any results, even for the simplest search criteria. After going back and forth with IW Support for about a week, and being given some significant (undocumented) recommendations for cleaning out old indexes after upgrading, I have finally been able to actually get results using Search.

After upgrading, the natural process for deleting old indexes and recreating them (using CLTs) does not really work. You have to manually delete your old indexes by deleting lots of folders and files from your Search server. Simply purging and adding branches while the old indexes are still there will not work.

Also our config files for Search/Indexer/IDOL needed to be tweaked very carefully. There were some things in the AutonomyContent.cfg file that we had to manually add as the upgrade itself did not seem to update this file properly.

There's also a new 7.3.2 Search patch that updates all the hunter_*.jar files for some other issue with indexing workareas that isn't in the Downloads section (yet).

It's all been very frustrating. My main branch is indexing now and hopefully all the Search problems from 7.2.1 that caused us to do this upgrade in the first place will be resolved.

We may have encountered a bug in 7.3.2 Search - IW is analyzing this behavior. What we've found is that after upgrading from 7.2.1 to 7.3.2, and re-indexing our branches in 7.3.2, if you run a Search from the UI, it will return results as long as those files were in the backing store when you performed the upgrade. It will not return any files in the resultset if those files were created (and indexed) after the upgrade. This is just how I'm seeing it, so the actual issue may or may not have anything to do with the timeframe of the upgrade, but this is the behavior we're seeing. The indexer claims it has indexed these new files. Search just can't find them.

The IW guy's theory was that if the branch has more than 5000 files, it wouldn't find any new files even though the indexer says they are indexed. But I disproved that theory by creating a couple new files in a branch that has 5 files and Search still couldn't find the new files.

I'll report more when I hear back.

Also, I am feeling the pain of what Wally reported in his OP regarding the built in timeout TeamSite has in place - if a Search takes longer than some very small number of seconds (30 according to Wally), it will time out. Even though Search still keeps going and returns results after the UI has timed out already. IW told me this timeout is on the TeamSite site and embedded in code, so it would take a patch to make the timeout larger. They are treating it as an enhancement rather than a bug - meaning they won't even look at it unless a few big name customers **** about it.

We've had no luck with TeamSite search. I've disabled the service...

Ditto. TeamSite search has been on my To Do list to enable for my users for many years. Never been able to get it to run properly.

Is this a Catch-22 situation? The bug won't get fixed unless enough folks complain that it isn't working, and no one will use it because it won't work?

Also - I find it interesting that there's not one response yet to this post in the affirmative of 'yes, we use Search'.

We are having the same issue. we migrated from 7.2.1 Unix to 7.3.2 Windows environment and we are not able to index. Also our custom code uses a lot of LCSC query so the preview is broken. According to the new design if the file are not indexed on the idol the LSCS queries will not work as well. We have a lot of files on folder and I can see that the site folder that have less files (200) the files are being indexed because I can search for them . The other folder that have more then 5000 files I cannot retrieve any of them on the search( new file or old one)

Look, I'm not trying to stir anything up, but.. how is this acceptable? This is a big-name, enterprise-level piece of software that we've all paid for the honor of being saddled with. Search is a piece of core functionality.

I'm having trouble understanding why most people's reactions to ongoing issues like these (there are many others - like LS not being able to differentiate between two matching relative alias URLS on two different sites) is to kinda shake their heads and go "that's our TeamSite!" like the end of an 80s sitcom.

Rant over, our team's had absolutely no luck with Search in 7.3.1. If anyone gets to the point where they're satisfied with the functionality, I would be very grateful with a postmortem or something, because obviously just opening a "support" ticket hasn't panned out for most of us.

Rant over, our team's had absolutely no luck with Search in 7.3.1. If anyone gets to the point where they're satisfied with the functionality, I would be very grateful with a postmortem or something, because obviously just opening a "support" ticket hasn't panned out for most of us.

From what we were told, 7.3.1 Search is junk. I think the whole reason for a 7.3.2 was to fix Search. And I use the term "fix" lightly.

Age Group.rptdesign

An update on this thread:
We'd reached a point at which we had 7.3.2 Search fairly stable (it was indexing content OK when I lined up all of the components correctly), but could not resolve the 30-second timeout issue between the Search UI in TeamSite and the Search / IDOL components; if we invoked a Search that took more than 30 seconds to complete, the UI times out, even though the back end successfully completes the query eventually.

We got some help to figure out exactly what TeamSite module was making the call and asked for some help to increase the 'stay alive' value so that we could see the results regardless of the time it took to resolve. The response from Engineering is that no query should ever take over 30 seconds and that they would work on optimizing the Search experience instead of enabling an increase of the timeout value. They also gave us some configuration options to regenerate our indexes in a more efficient way.

At this time, Search is generally functional when everything is up and running. We're going to test further.

Report Difference -- I see none.png

Report Difference -- I see none PDF.png

PDF from OS 372.pdf

PDF from OS450.pdf

They also gave us some configuration options to regenerate our indexes in a more efficient way.

Care to share what those are? Or were they too specific to your use cases?

cobra_letter.pdf

Sure:

1.) Modify search_home/idol/AutonomyContent.cfg. Add ",*/AreaRelativePath" to "PropertyFieldCSVs" in the [SetMatchFields] section. (leave the ones that are there already as is)

[SetMatchFields]
// Specify fields whose entire value is frequently used as a restriction in a search and are thus
// stored for optimised matching. NB Such fields cannot be numeric or parametric as well.
Property=MatchFields
PropertyFieldCSVs=*/TSMATCH_*,*/AreaRelativePath

2.) Modify search_home/idol/AutonomyContent.cfg. In [Server] section, add:

RegenerateMatchIndex=true

3.) Restart AutonomyContent service
4.) Check search_home/idol/application.log to make sure "RegenerateMatchIndex" action is 100% finished. The action could take some amount of time, depends on how large of the IDOL database.
5.) Comment out item added in step #2, so we don't regenerate match index during next start up.
// RegenerateMatchIndex=true

Walib, very helpful post, thanks. We've been struggling with various issues with Search in 7.3.2.

Can you detail what you did to line up all the components?

-Thanks

When I said "line up all the components" I meant that I started them in the correct order. I also waited a while between starting them up. I don't remember specifically what that order is, but I think it's:
- start IDOL
- start Connector
- start Search

Sure:

1.) Modify search_home/idol/AutonomyContent.cfg. Add ",*/AreaRelativePath" to "PropertyFieldCSVs" in the [SetMatchFields] section. (leave the ones that are there already as is)

[SetMatchFields]
// Specify fields whose entire value is frequently used as a restriction in a search and are thus
// stored for optimised matching. NB Such fields cannot be numeric or parametric as well.
Property=MatchFields
PropertyFieldCSVs=*/TSMATCH_*,*/AreaRelativePath

2.) Modify search_home/idol/AutonomyContent.cfg. In [Server] section, add:

RegenerateMatchIndex=true

3.) Restart AutonomyContent service
4.) Check search_home/idol/application.log to make sure "RegenerateMatchIndex" action is 100% finished. The action could take some amount of time, depends on how large of the IDOL database.
5.) Comment out item added in step #2, so we don't regenerate match index during next start up.
// RegenerateMatchIndex=true

hi walib
Is there anyway you can share the autonomycontent.cfg and search.properties? I did apply the same think that you sent over but im still having issues

After months of pain and anguish working with IW Support and the engineering team that works on Search, it looks like we'll finally be getting enough patches together to paper mache a working 7.3.2 Search server together. We have one more patch yet to receive, but the last patch they gave us is convincingly good enough to actually have some faith that Search will work.

Yes the last patches solve the problem. Make sure that the branches are purged !

Uhhh the patches we received are not publicly available as far as I know....not sure what he's referring to.

Nothing is Publicly available. QSU.