Search function down?
Posted: Sat Jun 02, 2007 8:35 am
Haven't been able to connect during the last 10 hours or so.
it is up all the time.
check your firewall permissions, maybe it blocked UE access after you upgraded to v1.9.1?
Page 1 of 1
Posted: Sat Jun 02, 2007 9:12 am
Posted: Sat Jun 02, 2007 9:51 am
Problem solved, it took me hours to discover that I had put the name of a new server in the space of the UE search server by mistake.alex wrote:it is up all the time.
check your firewall permissions, maybe it blocked UE access after you upgraded to v1.9.1?
Posted: Wed Jun 20, 2007 6:07 pm
Is there a problem at this momemt?
The search seems to wait a very long time, then after about 7-10 minutes its breaks off with a time-out.
If not, it looks like i have to check something on my end...
The search seems to wait a very long time, then after about 7-10 minutes its breaks off with a time-out.
If not, it looks like i have to check something on my end...
Posted: Wed Jun 20, 2007 7:34 pm
I get an error "Search Failed. Too many users".
Posted: Wed Jun 20, 2007 8:03 pm
"Too many users", and "connection forcibly closed by remote host" errors, and the errors come after a very long wait (5 - 10 minutes).
Posted: Thu Jun 21, 2007 6:24 am
i missed to observe it in real time. it seems we are talking about 12 hours ago.
i see the "too many users" indication happened, but i see no problem with the server, also there is no sign of any prior trouble including the time we are talking about, if it happened i would see it.
i see at the time there was no problem with processing requests fast, but maybe a connection problem caused slow bandwidth when returning results, it can be the only explanation for "too many users" in conjunction with slow response time given no signs of trouble with the server itself.
right now i only have code to detect abnormalities with request processing times, i don't measure connection quality, if something like that will happen again i could add code to detect connection problems as well.
i see the "too many users" indication happened, but i see no problem with the server, also there is no sign of any prior trouble including the time we are talking about, if it happened i would see it.
i see at the time there was no problem with processing requests fast, but maybe a connection problem caused slow bandwidth when returning results, it can be the only explanation for "too many users" in conjunction with slow response time given no signs of trouble with the server itself.
right now i only have code to detect abnormalities with request processing times, i don't measure connection quality, if something like that will happen again i could add code to detect connection problems as well.
Posted: Thu Jun 21, 2007 11:50 am
Well, the problem is gone now so we can put this one to rest 
I think the server as formidable uptime so let's enjoy.
I think the server as formidable uptime so let's enjoy.
Posted: Thu Jun 21, 2007 2:20 pm
I analyzed it further, now for certain it was some selected connectivity issue.
1. I checked headers from all servers were downloaded normally at the time, there is some periodic process to optimize storage of last 3M headers, the periodicity at the time (as to this post 20-22 hours ago when the posts in the thread had place) was the same as usual.
2. If to take the number of hourly requests at the time interval (11am-2pm server time) on June 16 as 100% (from hourly point the distribution also appears to be uniform and there were no irregularities indicated):
Jun 16 100.00%
Jun 17 108.15%
Jun 18 107.26%
Jun 19 100.70%
Jun 20 70.85% - significant drop
So this is it then. It means only some routes were affected, the reason has nothing to do with the server or the server computer (for the non-affected routes users also could get "too many users" right away - without any delays at all - when the users from the affected routes occupied all task slots).
I had to think a little to figure out the exact cause
1. I checked headers from all servers were downloaded normally at the time, there is some periodic process to optimize storage of last 3M headers, the periodicity at the time (as to this post 20-22 hours ago when the posts in the thread had place) was the same as usual.
2. If to take the number of hourly requests at the time interval (11am-2pm server time) on June 16 as 100% (from hourly point the distribution also appears to be uniform and there were no irregularities indicated):
Jun 16 100.00%
Jun 17 108.15%
Jun 18 107.26%
Jun 19 100.70%
Jun 20 70.85% - significant drop
So this is it then. It means only some routes were affected, the reason has nothing to do with the server or the server computer (for the non-affected routes users also could get "too many users" right away - without any delays at all - when the users from the affected routes occupied all task slots).
I had to think a little to figure out the exact cause