The geocoder does not write images to the filestore. However, if the calls to the geocoder fail, the Add* operations fail causing the image file mess-up you are seeing. Can you look in your summary report and see if the Add operations are being recorded as failed ? I'm wondering if there is some bug that is causing the transaction not to be rolled back cleanly.
Configure the geocoder as documented. You need an instance of Tomcat running. We typically use one of the driver systems itself to run the geocoder. Seeing connections in TIME_WAIT itself is not a problem. It becomes a problem only if you're trying to create a very large number of connections. The default time_wait_interval is too large for benchmarks. You can reduce this at the OS level. Shanti On Wed, Jul 21, 2010 at 12:51 AM, ZD Yu <[email protected]> wrote: > I have found this error was caused by the communication between the > webserver and geocoder server. > > In my setup, I installed the geocoder server on db system (a separate > system from web server). During the workload is running, I observed a lot of > TCP connections to db:8080 with TIME_WAIT status on the web server. I guess > the response from geocoder is too slow, so that some operations were not > executed (like writing image file to filestore). > > To verify it, I changed the /etc/hosts file on web server, to point > GEOCODER_HOST to 127.0.0.1 (i.e, the web server itself, on which there is NO > geocoder server running). After the change, all the error messages were > gone. > > The question is: How should I configure the geocoder server properly to > avoid this error? > > > On Wed, Jul 21, 2010 at 8:03 AM, ZD Yu <[email protected]> wrote: > >> Intel Xeon dual-processor server with RedHat EL5.4 x86_64. >> >> >> On Tue, Jul 20, 2010 at 11:06 PM, Shanti Subramanyam < >> [email protected]> wrote: >> >>> What platform (OS) are you testing on ? >>> >>> Shanti >>> >>> >>> On Tue, Jul 20, 2010 at 2:41 AM, ZD Yu <[email protected]> wrote: >>> >>>> > But running "select imagethumburl from SOCIALEVENT" on Olio database >>>> did not return any image file name with upper case. >>>> >>>> The above statement is not correct. What I wanted to say is: >>>> - searching filestore did NOT return any image file with upper case >>>> name. >>>> - running SQL "select imagethumburl from SOCIALEVENT" did return the >>>> upper case file name. >>>> >>>> >>>> On Tue, Jul 20, 2010 at 5:23 PM, ZD Yu <[email protected]> wrote: >>>> >>>>> I ran into the exact same problem as described in an earlier thread: >>>>> >>>>> http://mail-archives.apache.org/mod_mbox/incubator-olio-user/200905.mbox/%[email protected]%3e >>>>> >>>>> The client reported a lot of errors like: (note the image file name >>>>> with upper case E and T) >>>>> Image at >>>>> http://sut/fileService.php?cache=false&file=E1886T.jpgsize of 0 bytes is >>>>> too small. Image may not exist >>>>> >>>>> But running "select imagethumburl from SOCIALEVENT" on Olio database >>>>> did not return any image file name with upper case. >>>>> >>>>> In the above email thread, Akara said: >>>>> >>>>> Unless the file system has an issue with case sensitivity, it >>>>> seems your DB is out of sync. >>>>> >>>>> >>>>> My question is: what kind of mis-configuration may cause DB out of >>>>> sync? >>>>> >>>>> Thanks, ZD >>>>> >>>> >>>> >>> >> >
