Mailing List Archive

Andrew McMillan wrote:
> On Sun, 2009-11-22 at 11:31 +0100, Bruno Friedmann wrote:
>> Hi all,
>> I'm facing a strange trouble with the couple sunbird (1.0pre) and davical (0.9.7.6)
>> And I need to find who's culprit.
>>
>> You need to clients with right assistant to the other schedules. (can read/write/delete each other)
>>
>> cli1 create an event
>> cli2 delete this event
>>
>> On cli2 the event disappear immediately.
>> On cli1 the event stay here. Even with ctrl+r (refresh remote calendar)
>>
>> If on cli1 you try to edit the event, with apache2 < 2.2 there's not error reported.
>> If you (cli1) try to delete the event you receive an error and the schedule is marked as having a problem
>>
>> If you restart sunbird on cli1 the event disappear.
>>
>> I'm pretty sure about sunbird bug, but if someone can infirm/confirm this, it would help me to report it correctly on mozilla
>> bugzilla.
>
> Hi Bruno,
>
> It's a wild guess, but have you run the database upgrade script?
>
> This sounds like the sort of behaviour you would see if the trigger to
> update the collection tag was missing.
>
> If you go into PostgreSQL and do a '\d caldav_data' you should see this
> in your listing.
>
> Triggers:
> caldav_data_modified AFTER INSERT OR DELETE OR UPDATE ON caldav_data
> FOR EACH ROW EXECUTE PROCEDURE caldav_data_modified()
>
> Cheers,
> Andrew.
Thanks for the tricks, but the db was made new yesterday with all update scripts so I think everything is there

\d caldav_data
Table "public.caldav_data"
Column | Type | Modifiers
---------------+--------------------------+-----------------------------------------
user_no | integer | not null
dav_name | text | not null
dav_etag | text |
created | timestamp with time zone |
modified | timestamp with time zone |
caldav_data | text |
caldav_type | text |
logged_user | integer |
dav_id | bigint | default nextval('dav_id_seq'::regclass)
collection_id | bigint |
Indexes:
"caldav_data_pkey" PRIMARY KEY, btree (user_no, dav_name)
"caldav_data_dav_id_key" UNIQUE, btree (dav_id)
"caldav_data_collection_id_fkey" btree (collection_id)
Foreign-key constraints:
"caldav_data_collection_id_fkey" FOREIGN KEY (collection_id) REFERENCES collection(collection_id) ON UPDATE CASCADE ON
DELETE CASCADE DEFERRABLE
"caldav_data_logged_user_fkey" FOREIGN KEY (logged_user) REFERENCES usr(user_no) ON UPDATE CASCADE ON DELETE SET DEFAULT
DEFERRABLE
"caldav_data_user_no_fkey" FOREIGN KEY (user_no) REFERENCES usr(user_no) ON UPDATE CASCADE ON DELETE CASCADE DEFERRABLE
Triggers:
caldav_data_modified AFTER INSERT OR DELETE OR UPDATE ON caldav_data FOR EACH ROW EXECUTE PROCEDURE caldav_data_modified()
caldav_data_sync_dav_id AFTER INSERT OR UPDATE ON caldav_data FOR EACH ROW EXECUTE PROCEDURE sync_dav_id()


But ok the postgresql version is a bit old 8.1 ....



--

Bruno Friedmann

On Sun, 2009-11-22 at 21:05 +0100, Bruno Friedmann wrote:

> Thanks for the tricks, but the db was made new yesterday with all update scripts so I think everything is there
>
> \d caldav_data
> Table "public.caldav_data"

It all looks correct.


> But ok the postgresql version is a bit old 8.1 ....

PostgreSQL 8.1 is supposed to be OK. Although there might be bugs in
the support they are as yet unknown... :-)

One thing you could check is that the dav_etag field on the collection
has actually changed after the delete action. If it *hasn't* then it is
a DAViCal bug. If it *has* then odds are it is a lightning bug (heh) or
maybe still a DAViCal bug, but further investigation would be needed at
that point.

It's always helpful if you can get a TCP trace of a minimal set of
client/server interactions to identify where the problem is occurring.

My guess is that there is a problem with the trigger function, which
*should* set the dav_etag column on the collection table to something
different if a row is deleted, updated or inserted into the caldav_data
table.

Cheers,
Andrew.

------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Your business will go through a period of considerable expansion.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20091123/6d98808d/attachment.pgp>
-------------- next part --------------

Andrew McMillan wrote:
> On Sun, 2009-11-22 at 21:05 +0100, Bruno Friedmann wrote:
>
>> Thanks for the tricks, but the db was made new yesterday with all update scripts so I think everything is there
>>
>> \d caldav_data
>> Table "public.caldav_data"
>
> It all looks correct.
>
>
>> But ok the postgresql version is a bit old 8.1 ....
>
> PostgreSQL 8.1 is supposed to be OK. Although there might be bugs in
> the support they are as yet unknown... :-)
>
> One thing you could check is that the dav_etag field on the collection
> has actually changed after the delete action. If it *hasn't* then it is
> a DAViCal bug. If it *has* then odds are it is a lightning bug (heh) or
> maybe still a DAViCal bug, but further investigation would be needed at
> that point.

Ok I've try the manipulation : cli1 create an event the event is found in caldav_data

cli2 open the event and modify it (change description ) etag change in caldav_data, cli1 refresh and see change.
cli1 move event to another date, etag change, cli2 refresh and see the change.

cli2 delete the event, record is delete from caldav_data. cli1 refresh and nothing change.

cli2 sunbird message
CalDAV: refresh completed with status 207 at http://caldav-test.ioda.net/caldav.php/yellow/home/
CalDAV: Item deleted successfully from calendarYellow

cli1 log
CalDAV: Item modified successfully on Yellow

CalDAV: Status 207 fetching calendar-data for calendar Yellow

CalDAV: refresh completed with status 207 at http://caldav-test.ioda.net/caldav.php/yellow/home/

CalDAV: Item modified successfully on Yellow

CalDAV: Status 207 fetching calendar-data for calendar Yellow

CalDAV: refresh completed with status 207 at http://caldav-test.ioda.net/caldav.php/yellow/home/
and after the delete
CalDAV: Status 207 fetching calendar-data for calendar Yellow
CalDAV: refresh completed with status 207 at http://caldav-test.ioda.net/caldav.php/yellow/home/
(here I think they get the modification/delete event but they don't care :-)

>
> It's always helpful if you can get a TCP trace of a minimal set of
> client/server interactions to identify where the problem is occurring.
Just a bit tricky for me ( did you have the good corresponding flags to launch tcpdump ?)
I would also place sunbird in verbose debug mode.
>
> My guess is that there is a problem with the trigger function, which
> *should* set the dav_etag column on the collection table to something
> different if a row is deleted, updated or inserted into the caldav_data
> table.

So hopefully it seems all server part are working correctly.
Ah if I have a mac or an iphone ... :-)

Thanks for your support


--

Bruno Friedmann

On Mon, 2009-11-23 at 08:29 +0100, Bruno Friedmann wrote:
> Andrew McMillan wrote:
> > On Sun, 2009-11-22 at 21:05 +0100, Bruno Friedmann wrote:
> >
> >> Thanks for the tricks, but the db was made new yesterday with all update scripts so I think everything is there
> >>
> >> \d caldav_data
> >> Table "public.caldav_data"
> >
> > It all looks correct.
> >
> >
> >> But ok the postgresql version is a bit old 8.1 ....
> >
> > PostgreSQL 8.1 is supposed to be OK. Although there might be bugs in
> > the support they are as yet unknown... :-)
> >
> > One thing you could check is that the dav_etag field on the collection
> > has actually changed after the delete action. If it *hasn't* then it is
> > a DAViCal bug. If it *has* then odds are it is a lightning bug (heh) or
> > maybe still a DAViCal bug, but further investigation would be needed at
> > that point.

It's not clear to me from below what the result of:

SELECT dav_etag FROM collection WHERE dav_name = '/yellow/home/';

would be at each of the stages below. There's also an etag field on
caldav_data, but that applies to changes in the individual item, whereas
the one on the collection is supposed to be updated by the trigger
whenever *any* item in the collection changes.


> Ok I've try the manipulation : cli1 create an event the event is found in caldav_data
>
> cli2 open the event and modify it (change description ) etag change in caldav_data, cli1 refresh and see change.
> cli1 move event to another date, etag change, cli2 refresh and see the change.
>

SELECT dav_etag FROM collection WHERE dav_name = '/yellow/home/';

> cli2 delete the event, record is delete from caldav_data. cli1 refresh and nothing change.

SELECT dav_etag FROM collection WHERE dav_name = '/yellow/home/';



> > It's always helpful if you can get a TCP trace of a minimal set of
> > client/server interactions to identify where the problem is occurring.
> Just a bit tricky for me ( did you have the good corresponding flags to launch tcpdump ?)
> I would also place sunbird in verbose debug mode.

As a fallback you can also set:
$c->dbg['request'] = 1;
$c->dbg['response'] = 1;
in your config.

This doesn't catch all possible communication, but if things are
generally working it's likely to be helpful. The sorts of situations it
doesn't catch are when there is (e.g.) a variable uninitialised warning
from PHP that gets into the XML stream and screws everything up.

For tcpdump I use a command line like:

tcpdump -s0 -wfilename.tcpdump -ieth0 tcp port 8008

I can open a dump like that in Wireshark and go into the "Follow TCP
Stream" option to read (or save) the communication in detail.

Cheers,
Andrew.

------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Building more free and open source software for the world
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20091123/a64a169e/attachment.pgp>
-------------- next part --------------

Hi Andrew, many thanks to your support, really appreciate...

Andrew McMillan wrote:
> On Mon, 2009-11-23 at 08:29 +0100, Bruno Friedmann wrote:
>> Andrew McMillan wrote:
>>> On Sun, 2009-11-22 at 21:05 +0100, Bruno Friedmann wrote:
>>>
>>>> Thanks for the tricks, but the db was made new yesterday with all update scripts so I think everything is there
>>>>
>>>> \d caldav_data
>>>> Table "public.caldav_data"
>>> It all looks correct.
>>>
>>>
>>>> But ok the postgresql version is a bit old 8.1 ....
>>> PostgreSQL 8.1 is supposed to be OK. Although there might be bugs in
>>> the support they are as yet unknown... :-)
>>>
>>> One thing you could check is that the dav_etag field on the collection
>>> has actually changed after the delete action. If it *hasn't* then it is
>>> a DAViCal bug. If it *has* then odds are it is a lightning bug (heh) or
>>> maybe still a DAViCal bug, but further investigation would be needed at
>>> that point.
>
> It's not clear to me from below what the result of:
>
> SELECT dav_etag FROM collection WHERE dav_name = '/yellow/home/';
>
> would be at each of the stages below. There's also an etag field on
> caldav_data, but that applies to changes in the individual item, whereas
> the one on the collection is supposed to be updated by the trigger
> whenever *any* item in the collection changes.

Ok I've replay the operation, and at each step the collection.dav_etag change.
So a good news for davical.

>
>
>> Ok I've try the manipulation : cli1 create an event the event is found in caldav_data
>>
>> cli2 open the event and modify it (change description ) etag change in caldav_data, cli1 refresh and see change.
>> cli1 move event to another date, etag change, cli2 refresh and see the change.
>>
>
> SELECT dav_etag FROM collection WHERE dav_name = '/yellow/home/';
>
>> cli2 delete the event, record is delete from caldav_data. cli1 refresh and nothing change.
>
> SELECT dav_etag FROM collection WHERE dav_name = '/yellow/home/';
>
>
>
>>> It's always helpful if you can get a TCP trace of a minimal set of
>>> client/server interactions to identify where the problem is occurring.
>> Just a bit tricky for me ( did you have the good corresponding flags to launch tcpdump ?)
>> I would also place sunbird in verbose debug mode.
>
> As a fallback you can also set:
> $c->dbg['request'] = 1;
> $c->dbg['response'] = 1;
> in your config.

I've activated this, and dump part to the attached log, In which as I can see the correct response is send back to client.

>
> This doesn't catch all possible communication, but if things are
> generally working it's likely to be helpful. The sorts of situations it
> doesn't catch are when there is (e.g.) a variable uninitialised warning
> from PHP that gets into the XML stream and screws everything up.
>
> For tcpdump I use a command line like:
>
> tcpdump -s0 -wfilename.tcpdump -ieth0 tcp port 8008
Ok I've noted it, at will use it if necessary. But I'm pretty sure now that sunbird do nothing with the information
they received.

>
> I can open a dump like that in Wireshark and go into the "Follow TCP
> Stream" option to read (or save) the communication in detail.
>
> Cheers,
> Andrew.
>

As I've previously announced You can also use the http://caldav-test.ioda.net
(I've added a link to display the debug davical log (could be waste) and a reset log link)



--

Bruno Friedmann

-------------- next part --------------
A non-text attachment was scrubbed...
Name: davical_yellow_debug.log.gz
Type: application/x-gzip
Size: 3538 bytes
Desc: not available
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20091123/af2c59db/attachment.bin>
-------------- next part --------------