I am currently working on solution where date & time data is being inputted from IWP and I am seeing some unusual activity. After entering data via IWP the iCal calendar goes offline with this error (“500”
to operation CalDAVAccountRefreshQueueableOperation.)

When I look at WebPublishing Log on the server this is what I am seeing.
Error 0 in the Web Publishing Core localhost 127.0.0.1 ReadOnly XML 802 496 "/fmi/xml/FMPXMLRESULT.xml?-db=ResourceScheduler&-lay=ProscNoSuchTable&-view"

The odd thing about this is that after about 20 -30 minutes the calendar goes online again and the event shows up on iCal.

Hi,

I received your log also. There's no serious errors there, but this could be a resource issue as IWP and Zulu are both using FileMaker Server's web publishing engine. Typically 500 errors are the result of a data issue, but if it's correcting itself, then I'm not sure what that would be. Perhaps IWP has committed an incomplete record when iCal/Zulu are trying to access it as the log does have some of these types of warnings:

Dec 6, 2012 2:22:39 PM com.prosc.fmcaldav.EventResource fromResultSet
INFO: No start date for event with primary key 100070; skipping. UUID: null

These are generally harmless, but could be bogging the WPE down a bit.

I'm also seeing these as well:

Dec 6, 2012 2:22:39 PM com.prosc.fmcaldav.EventResource fromResultSet
WARNING: Could not parse eventData for 50e4891d-cbb6-45c0-b592-e6ed67e3109c
net.fortuna.ical4j.data.ParserException: Error at line 2: Expected [-3], read [10]

I'm going to send you a pre-release version of the next Zulu (1.3402) which corrects this issue and we'll be releasing soon. It's generally harmless to, but since this could be a general resource issue, cutting these down as much as possible might help. After upgrading to 1.3402, go ahead and clear the field zulu_iCal_Data for all your records. The extra carriage returns there are what's causing this warning and that should clean them up. This will make the next iCal refresh a bit slower than usual, but then hopefully things will smooth out, but let us know.

I'll send the next Zulu build via sendbigfiles.com and you should receive it shortly.

Thanks!

I'm still seeing the lag issues even with the new version. There is about a 20 min difference between the creation timestamp and modification timestamp.

Hi,

Thanks, and I got your log as well.

The only errors are 802 errors which means that the Zulu's unable to access the file via XML/CWP. My suspicion is that it's a resource issue for the Web Publishing Engine and the IWP activity has it maxed out so that Zulu can't hit it via XML. This makes sense that the changes eventually do come through as eventually the XML queries do go through. I'm not sure there's going to be much we can do about this as FileMaker Server's Web Publishing Engine is a limited resource. It is much improved in Server 12, but still does have limits.

rnakama wrote: There is about a 20 min difference between the creation timestamp and modification timestamp.

It might be helpful to get some more details on the changes using something like SuperLog, so you can see when the IWP user is done with the record and when Zulu/iCal picks it up. The Modification timestamp is what Zulu uses as a trigger, but if that's getting held up by IWP, then that could be part of the issue.

Hope that helps,
-Jason