Found that libsynthesis based server generates Delete command for client with empty item:

<Sync><CmdID>4</CmdID><Target><LocURI>./C:Calendar</LocURI></Target><Source><LocURI>./calendar</LocURI></Source><NumberOfChanges>1</NumberOfChanges><Delete><CmdID>5</CmdID><Meta><Type>text/x-vcalendar</Type></Meta><Item/></Delete></Sync>

when calendar superdatastore is being used.

Test environment:
- libsynthesis (engine version 3.4.0.24) based server
- 2 Symbian phones: Nokia E65 and Nokia E90 Communicator (named as A and B, which one is A is not significant).
- superdatastore calendar was used

Perhaps also other Symbian phones can be used to reproduce the problem

Steps to repeat the problem:
1) create recurrent event on one of the phones (phone A), edit one of occurrences (change time interval), delete one occurrence
2) synchronize phone A with server (should add 2 events)
3) synchronize phone B with server (event is added on this phone).
4) remove all occurrences of event from phone A and synchronize with server (should remove 2 events from server according logs) 5) synchronize phone B with server. As far as I had tested, phone B has before this step still pending update for recurrent event but not for edited occurrence. As result replace/delete conflict occurs and configuration setting deletewins was not used. Recurrent event is re-added to server data-store but the modified occurrence is not even if it remains in EXDATES. 6) attempting to synchronize phone B again causes the error mentioned at the start to occur and the synchronization fails. In my case an attempt to repeat synchronization does not help any more as the same error repeats.

This error also causes session event loop to receive sysync::STEPCMD_DONE without actually returning a response to the client. Significant status changes are visible from output below (ones like STEPCMD_STEP ==> STEPCMD_OK and similar non-interesting ones are not outputted):

2011/09/15 16:19:19.0159 - ipn::tcp::HttpServerBase::Session::parse_request: INFO: request_id=145 remote_address='127.0.0.1' request_line='POST /syncml HTTP/1.1 body_length=291 HTTP request: session_id=N/A request_length=291 content_type='application/vnd.syncml+wbxml'
Generated ID: 'Remi685ET5bt0pQcZhzz7EJOudU'
session_step: 13:19:19.018 : t=0.000003 err=0 : STEPCMD_GOTDATA ==> STEPCMD_OK session_step: 13:19:19.051 : t=0.000213 err=0 : STEPCMD_STEP ==> STEPCMD_SENDDATA session_step: 13:19:19.051 : t=0.000002 err=0 : STEPCMD_SENTDATA ==> STEPCMD_NEEDDATA 2011/09/15 16:19:19.0511 - ipn::tcp::HttpServerBase::WorkerThread::process_request: INFO: request_id=145: 200 (OK) 2011/09/15 16:19:19.3220 - ipn::tcp::HttpServerBase::Session::parse_request: INFO: request_id=146 remote_address='127.0.0.1' request_line='POST /syncml?sessionid=Remi685ET5bt0pQcZhzz7EJOudU HTTP/1.1 body_length=2096
Using existing session ID: 'Remi685ET5bt0pQcZhzz7EJOudU'
session_step: 13:19:19.322 : t=0.000003 err=0 : STEPCMD_GOTDATA ==> STEPCMD_OK session_step: 13:19:19.358 : t=0.023678 err=0 : STEPCMD_STEP ==> STEPCMD_SENDDATA session_step: 13:19:19.358 : t=0.000003 err=0 : STEPCMD_SENTDATA ==> STEPCMD_NEEDDATA 2011/09/15 16:19:19.3585 - ipn::tcp::HttpServerBase::WorkerThread::process_request: INFO: request_id=146: 200 (OK) 2011/09/15 16:19:19.5674 - ipn::tcp::HttpServerBase::Session::parse_request: INFO: request_id=149 remote_address='127.0.0.1' request_line='POST /syncml?sessionid=Remi685ET5bt0pQcZhzz7EJOudU HTTP/1.1 body_length=399 2011/09/15 16:19:19.5674 - ipn::tcp::HttpServerBase::Session::parse_request: INFO: request_id=149 remote_address='127.0.0.1' request_line='POST /syncml?sessionid=Remi685ET5bt0pQcZhzz7EJOudU HTTP/1.1 body_length=399 HTTP request: session_id='Remi685ET5bt0pQcZhzz7EJOudU' request_length=399 content_type='application/vnd.syncml+wbxml'
Using existing session ID: 'Remi685ET5bt0pQcZhzz7EJOudU'
session_step: 13:19:19.568 : t=0.000003 err=0 : STEPCMD_GOTDATA ==> STEPCMD_OK session_step: 13:19:19.623 : t=0.000002 err=0 : STEPCMD_STEP ==> STEPCMD_DONE 2011/09/15 16:19:19.6228 - ipn::tcp::HttpServerBase::WorkerThread::process_request: INFO: request_id=149: 500 (INTERNAL ERROR)

As result the server has no data to send to the client as the response. Internal error message at the end is caused by absence of the response.

Andris



_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Reply via email to