Thank you for your thoughtful and helpful comments and suggestions.
We have updated the ticket at http://mantis.tokeek.de/view.php?id=492#bugnotes
We have upgraded both servers to today's available ver 1.81/9130
While both are apparently stable,
>>> No change in observed systems behavior.
>>>NO SEARCH RESULTS DISPLAY when searches are made. Only the page header details including the search button, when using a template provided with the kit.
>>> errors of 500 type lists are still showing, as detailed previously, in administration pages
This condition persists despite that we have applied -2- updates since the incident began on both servers, as a result of applying ( 1.81/9116 ), sequentially to each cloud in the scope of ~10 min.
Good idea...we know the clicking back trick and have tried it, but it doesn't give us any joy, unfortunately. But thanks!
The some 700+ mostly custom RSS crawls are divided between the presently two servers.
This would tend to indicate a somewhat lower loading than you suggest, however, due to some things, among which the loading in "rush hours," it can become heavy and at those times, the engines are visibly running very quickly - depending upon the remote sources being addressed.
While the crawls are typically once ( 1X ) a day, there are some important characteristics which define system loading.
Each RSS can include a long secondary list of hundreds of external addresses of URLs that have been pre-retrieved by another toolset, and then those results must be crawled and locally indexed. The list of each one can be over 1000 entries long, upon occasion ( i.e., frequently ).
There are also time of day issues. Typically evening and late night until very early morning (in the night) are especially busy times due to the availability of "fresh data" to harvest. Then a few hours later in the mornings, for another large but shorter block of high traffic times.
Thanks for your thoughts. I will pm.
Our #1 issue now is to remove the persistent condition where the The Key Error Message still displayed is:
on page: / Status.html?noforward=
The peer must go online to get a peer address.
Note: These was never in peer mode. These are stand alone Robinson Servers that read each other to fulfill search requests, but do not write to each other.
Both servers were knocked offline, disconnected by the version update applied, at the start of this ticket ( 1.81/9116 ). They were NOT Reconnected by the -2- two subsequent updates we have applied since our first report.
Therefore it appears a manual re-connection is needed. What & Where and what is the correct Syntax are the questions to answer, please. We suspect that restoring this manually may have a beneficent effect on the whole environment in each cloud, but it is only a theory.
Thank You Very, Very Kindly, Everybody...