Re: Evaluation

On Fri, 2009-05-15 at 15:32 -0400, Dirk Bartley wrote:
> I did an svn up and recompiled and installed.  Same result.  Is there
> something I can do to assist in figuring out why this happens??
> 
> Here is 500 lines of output from the log file.
> http://www.schupan.com/ogo-zidestore-1.5-out.log

Hrm,  it seems to be caught in a loop getting -
GET /zidestore/dbartley/public/Contacts/10121.vcf HTTP/1.  Which could
peg the CPU forever.  There is no reason it should retrieve an object
more than once.  Your response times look pretty good.  

But it is odd that the request is answered with a 404 (Not Found) and
ZideOne tries again.  I wonder if the multistatus response [PROPFIND]
on /zidestore/dbartley/public/Contacts/ indicated that 10121.vcf was a
resource.

Is there anything interesting in ogo-zidestore-1.5.err.log ?

> I could also do a tcpdump if that would help.

An awesome feature is stream logging, which will put to the log file the
literal exchange between the client and the server.  On page 95 of the
latest WMOGAG:

<quote>
HTTP Streams
Especially when debugging clients of the ZideStore integration server it
is extremely useful to capture the literal exchange between clients and
the server. Unfortunately switched and router networks, in addition to
SSL encryption, often make using a traditional traffic capturing tool
quite difficult. In order to facilitate debugging the exchanges between
clients and servers can be captured to the server's error log by
enabling the “WOHttpAdaptor_LogStream” default. When
“WOHttpAdaptor_LogStream” is set to a value of “YES” every request and
the corresponding response will be written to the log; therefore
enabling this default on a production server can cause a tremendous
increase in log size and I/O. If stream logging is enabled in the
NSGlobalDomain domain then requests and responses will be recorded for
all servers: ZideStore, XML-RPC, and the web interface. Given this
consideration stream logging should usually be enabled in the context of
a specific service171. Client support for stream compression may result
in compressed results being recorded in the logs, especially in the case
of the web interfac. Setting “WODontZipResponse” to “YES” in the same
default domain as “WOHttpAdaptor_LogStream” will prevent streams from
being compresses. Setting “WODontZipResponse” to “NO” or deleting the
“WODontZipResponse” default will restore the default behavior of
compressing responses if the client supports compressed responses.
</quote>

Another trick is to just retrieve the object using curl, which is
something I use all the time for various purposes, like:

curl -u adam:******
http://opengroupware.mormail.com/zidestore/adam/public/Contacts/10100.vcf

Then you can see if there is something really weird/malformed in the
result.  If it looks normal then you can use stream logging to see
ZideOne's request and how the server replies. (or of course, you can
capture the exchange with WireShark or tcpdump).  I usually find stream
logging to be easier.

There is a section "Interacting with ZideStore via “curl”" in the
ZideStore chapter of WMOGAG (currently on page 75).


-- 
OpenGroupware developer: [email protected]
<http://whitemiceconsulting.blogspot.com/>
OpenGroupare & Cyrus IMAPd documenation @
<http://docs.opengroupware.org/Members/whitemice/wmogag/file_view>

-- 
OpenGroupware.org Users
[email protected]
http://mail.opengroupware.org/mailman/listinfo/users