Thanks for digging into this. In the earlier version we had a single directory filestore so simply chmoding it upfront (as is documented) works. However, after creating the directory hierarchy in 0.2, this is an issue. I have run into this but kind of forgot because we typically do not reload the filestore very often. When we do, it is done manually. I suspect others may be doing something similar. We should at least document this issue.
Shanti On Thu, Jul 22, 2010 at 6:47 PM, ZD Yu <[email protected]> wrote: > Finally I found the root cause of my problem. This is because after > reloading the filesstore, the sub-directories under filestore will be erased > and recreated by the reloading user (i.e., root), so the Apache processes > (run as daemon user) do not have write permisstion to the filestore. > > If users choose to reload filestore manually, they can "chmod -R 777 > filestore" everytime. But if users choose to reload filestore automatically > in Faban UI, they do not have a chance to chmod at all. Should this be a > bug? I am very curious why it has not been reported before... > > Thanks, ZD > > > On Thu, Jul 22, 2010 at 12:57 AM, Shanti Subramanyam < > [email protected]> wrote: > >> 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.jpg size 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 >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
