Hi, Turns out I got my versions wrong. Shipping Server.app's calendar server is 6.0, which is why the dataversion column is there. Sorry for the confusion (I was also highly confused).
My previous suggestion to upgrade needs to be re-evaluated in light of the fact that your client timeouts are probably not caused by problems with on-the-fly data format upgrades. I'm not saying you should roll back; just that I probably mis-attributed the cause of your timeouts. 5.4-dev is considered solid (from a release control perspective). It may be that 6.0 solves the problem, but we'd need more info to know for sure. I wouldn't recommend just trying it unless you can do so on a test server. To find out what requests are timing out, a tcpdump of the timing out connection would work, if you can temporarily enable a non-ssl port on the server. Start by sniffing everything on the service port and writing it to a file using -w. To minimize what you send, you can use tcpdump -r to select from the capture file based on the client IP and tcp port the server logs in the timeout log entry. This should show us the request made by the client that is timing out, if any. Alternatively, the server has an "AccountingPrincipals" feature to log everything server side for specified principals. This may be noisier than tcpdump as it would include successful requests and responses from that user. Also, if no request is ever made (eg tcp handshake failure), there may be no record of that in Accounting logs. I will swing back with further instructions on enabling this. -dre Sent from my iPhone > On Feb 5, 2015, at 4:20 PM, Andre LaBranche <d...@apple.com> wrote: > > You’ve most likely found a bug, I just don’t know what it is yet. > > The calendar servers I’m looking at which have dataversion on calendar_object > are Server.app servers, which are produced and built differently than our > open source offerings. Even so, I don’t think we expect schema differences > between the Server.app config and the open source config, given the same > version of Calendar Server on both. > > I’ll investigate further... > > -dre > >> On Feb 5, 2015, at 4:02 PM, Jacques Distler <dist...@golem.ph.utexas.edu> >> wrote: >> >> >>> On Feb 5, 2015, at 5:01 PM, Andre LaBranche <d...@apple.com> wrote: >> >>>>>> You can find out how many resources are in the old format by running >>>>>> this SQL: >>>>>> select count(*) from calendar_object where dataversion = 0; >>>>> >>>>> Well, now you have me REALLY confused. >>>>> >>>>> I did a calendarserver_upgrade when I upgraded to 5.3 (and, again, for >>>>> good measure when I upgraded to 5.4dev). So I THOUGHT I had the latest >>>>> schema version. But there's no "dataversion" column in the >>>>> "calendar_object" table: >>> >>> That can’t be good. There should absolutely be a dataversion column on >>> calendar_object, and I’m not really sure what to expect if that’s missing. >>> Most likely it means that somewhere along the line, some schema upgrade >>> failed. I’m somewhat surprised that your server is still working... >> >> If you call this "working." >> >> Anyway, according to >> >> http://trac.calendarserver.org/browser/CalendarServer/tags/release/CalendarServer-5.3/txdav/common/datastore/sql_schema/current.sql >> >> there's no "dataversion" column in the "calendar_object" table. >> >> Same for >> >> http://trac.calendarserver.org/browser/CalendarServer/branches/release/CalendarServer-5.4-dev/txdav/common/datastore/sql_schema/current.sql >> >> Now, I'll grant you that there IS a "dataversion" column in the >> "calendar_object" table in >> >> http://trac.calendarserver.org/browser/CalendarServer/tags/release/CalendarServer-6.0/txdav/common/datastore/sql_schema/current.sql >> >> But I'm not USING version 6.0. Should I be? What's the deal with the 5.x >> branch, then? >> >>> When you start the service, what does error.log say about checking schema / >>> data versions? >> >> [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] >> Beginning database schema check. >> [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] >> Required database key VERSION: 28. >> [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] >> Actual database key VERSION: 28. >> [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] >> Schema version check complete: no upgrade needed. >> ... >> [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseCalendarDataStep#warn] >> Beginning database calendar data check. >> [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseCalendarDataStep#warn] >> Required database key CALENDAR-DATAVERSION: 6. >> [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseCalendarDataStep#warn] >> Actual database key CALENDAR-DATAVERSION: 6. >> [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseCalendarDataStep#warn] >> Calendar data version check complete: no upgrade needed. > > _______________________________________________ > calendarserver-users mailing list > calendarserver-users@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/calendarserver-users _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
