Team Calendar CalDav Syncronizer

[Katharina Wolkwitz]

Hi Support,

recently we have installed confluence including the team calendar function. We'd like to syncronize them to Outlook via the CalDav Syncronizer, which causes internal server errors (code 500). Do you have a hint what it could be and how I can resolve it?

We have deactivated the collaborative editing feature as we don't need it. Does it influence the calendar synchronisation?

Is there a way to add the report xml.file to the support-request? The edit-field is limited to 20.000 chars and the report exeeds that by far.

Kate

[Shannon S]

Katharina

Can you show me which CalDav Synchronizer this is? I'm not familiar with it.

If you were to create a test calendar and add a basic event or two, does the issue still occur?

Lastly, what is the report xml file you refer to? Is it generated by the synchronizer? What error messages do you see in the Confluence Server logs when it tries to synchronize?

Regards,

Shannon

[Katharina Wolkwitz]

Hi Shannon,

sorry for taking so long answering your post. I was off work on Friday.

The CalDav Synchronizer is the tool recommended by your own step-by-step guide "Subscribe to Team Calendars from Microsoft Outlook" ( https://community.atlassian.com/t5/Confluence-questions/Team-Calendar-CalDav-Syncronizer/qaq-p/879535?utm_campaign=&utm_content=post&utm_medium=email&utm_source=atlcomm#M118137 ) which I followed to connect our Team Calendars to our Outlook-Clients btw.

The report-file is indeed from this tool.

Could you give me a hint as to where I'd find the Confluence Server logs? I inherited the server and am not very familiar with its setup.

I'll create a test-calendar and subscribe to it only with my Outlook-Client and create a few test events. And then I'll have a look if that calendar will produce synchronization errors as well.

Kate

[Katharina Wolkwitz]

One more information:

All our other team-calendars are based on pre-existing calendars exported from a group-ware-server to .ics-files and imported into confluence team-calendars. They had between 5 and 480 events when they were generated/imported (some of them recurring).

Kate

[Katharina Wolkwitz]

Hi again,

in the /opt/atlassian/confluence/logs/catalina.2018-08-24.log and also in others from different dates I've found numerous errors like this:

24-Aug-2018 14:35:07.995 WARNUNG [ContainerBackgroundProcessor[StandardEngine[Standalone]]] org.apache.catalina.valves.StuckThreadDetectionValve.notifyStuckThreadCompleted Thread [http-nio-8090-exec-134] (id=[3673]) was previously reported to be stuck but has completed. It was active for approximately [154,232] milliseconds. There is/are still [8] thread(s) that are monitored by this Valve and may be stuck.
24-Aug-2018 14:35:07.996 WARNUNG [ContainerBackgroundProcessor[StandardEngine[Standalone]]] org.apache.catalina.valves.StuckThreadDetectionValve.notifyStuckThreadCompleted Thread [http-nio-8090-exec-122] (id=[3661]) was previously reported to be stuck but has completed. It was active for approximately [127,339] milliseconds. There is/are still [7] thread(s) that are monitored by this Valve and may be stuck.
24-Aug-2018 14:35:07.996 WARNUNG [ContainerBackgroundProcessor[StandardEngine[Standalone]]] org.apache.catalina.valves.StuckThreadDetectionValve.notifyStuckThreadCompleted Thread [http-nio-8090-exec-135] (id=[3674]) was previously reported to be stuck but has completed. It was active for approximately [127,374] milliseconds. There is/are still [6] thread(s) that are monitored by this Valve and may be stuck.
24-Aug-2018 14:35:07.996 WARNUNG [ContainerBackgroundProcessor[StandardEngine[Standalone]]] org.apache.catalina.valves.StuckThreadDetectionValve.notifyStuckThreadCompleted Thread [http-nio-8090-exec-123] (id=[3662]) was previously reported to be stuck but has completed. It was active for approximately [93,553] milliseconds. There is/are still [5] thread(s) that are monitored by this Valve and may be stuck.

Since until now I only kept the CalDav synchronization reports for one day, I'm afraid I'm not able to compare the date/time-stamps from the server-log-files with the CalDav-synchronizer-report-files at the moment. I've changed the time-frame the reports are kept to three days, so I'll be able to do some alignement tomorrow.

Kate

[Shannon S]

Hi Kate,

Thank you for clarifying which sync product you're using.

The Confluence server logs can be found at <confluence-home>/logs/atlassian-confluence.log. For example: c:/confluence/data/logs/atlassian-confluence.log

However, you may be better off checking the DEBUG log of the synchronizer itself. This can tell you what error Confluence returned directly to it. If it's a 500 error, I'm wondering if you aren't behind a proxy or firewall that might be blocking access.

Additionally, the support portal for the synchronizer itself is available from this page. My searches online and from their forum show there might be an invalid event which is why I was asking if it does the same for all calendars.

Please do take a moment to review both the Confluence server logs (this is separate than catlina.out) as well as the logs from the synchronizer itself in order to determine the reason for the issue.

Regards,

Shannon

[Katharina Wolkwitz]

Hi Shannon,

I'm starting to suspect a problem with those imported events as well, since the test-calendar is behaving outstandingly well so far (but with only one subscriber and three events there are really no great strain on it either ;-) )...

Well - I've tried disabling the firewall completly and that didn't have any effects on the synchronization behaviour at all.

Also I changed the report-behaviour from "Sync runs with errors or warnings" to "All" - so now I'm seeing that there are really a lot of successfull sync runs and only a few "red" runs in between.

But the test-calendar had it's red-run as well now. A 500-error too.

I've taken a look at the /var/atlassian/application-data/confluence/logs/atlassian-confluence.log and managed to extract one "error-occurrence" for the ID of the test-calendar as far as I can identify it (from on time-stamp to the next), but I'm afraid even just that extract is almost 400 lines long and thus too long to be posted here inside the editor. :-(

I'll give it a try in a seperate reply - since I cannot make heads nor tails of it...

Kate

[Katharina Wolkwitz]

Hmmm - when I try to paste the part of the log-file (either directly or as a code-block) I get the following error-message:

Error

Your message was not accepted. Check for invalid HTML or try reposting as plain text.

Do you have an idea how I should get the log-file/-text to you?

Kate

[Shannon S]

Kate,

Could you use something such as Dropbox to send the logs you're finding? That way you can just send the link here and I'll be able to review it.

Edited to add - please make sure to review the logs specifically from the synchronizer as well, since I think they will give you the most important details.

Regards,

Shannon

[Katharina Wolkwitz]

Hi Shannon,

I've put both the CalDav-report (1) and the Confluence-Server-log-file-extract (2) into my drop-box.

Here are the links:

(1) https://www.dropbox.com/s/aown2cdcunejpsb/report-500.xml?dl=0

(2) https://www.dropbox.com/s/nt41qex67wxnxse/altessian-error.log?dl=0

I hope, you can help me understand what's happening to cause these errors.

Kate

[Shannon S]

Hi Kate,

Sorry for the delay!

So the problem here doesn't appear to be an issue with Confluence and Team Calendars, but rather the synchronizer.

The request the plugin is sending to Confluence is the issue. The request is making it to Confluence, but Confluence is having trouble with the request.

I mentioned earlier that you have a look at the synchronizer logs. This is different than the synchronization report you sent. Per their documentation:

Each synchronization attempt is logged in the log.txt file. There you can find information about sync duration and the amount of added, deleted or modified events. Errors and Exceptions are logged aswell. You can view and clear the log file in General Options. There you can also change the log level from INFO to DEBUG.

There's a way to enable DEBUG logging for the synchronizer and get the log file.

See here: Debugging and more config options

In addition, if you just tail the Confluence logs when you try to synchronize the calendar in Outlook, it may also be helpful by giving us the exact log entries. The timestamps differ from the synchronizer error and the Confluence logs you already provided. This would ensure the errors are indeed related to your synchronizing issue.

Regards,

Shannon

[Katharina Wolkwitz]

Hi Shannon,

I've just changed my CalDav-Logging-Settings from Info to Debug. Now I'll have to wait for a synchronization-error to appear in the report-window so that I can try to match time-stamps for you and put the right file snippets into my DropBox.

I'm afraid tailing the Confluence logs isn't a very feasable option. The synchronization-errors are rarer as I thought in the beginning - so I need to know specifically what to look for in the server-log-file.

What caused us to panic in the beginning was the CalDav-Synchronization-Report-setting "Log Sync-Runs with errors and warnings" in combination with "Show reports and notify errors and warnings". This causes the report-window to pop-up seemingly every other minute or so and have LOTS of red warnings plastered all over it...

Now, that I've changed those settings for all users to not show the report window automatically at all and to report all sync runs in my client, I see a totally different picture. ;-)

At the moment, synchronization seems to be working ok - but maybe that's because I'm sitting here, waiting for an error. Or maybe it's because most of my colleagues have already left for home.

I'll take another look tomorrow morning.

Kate

[Shannon S]

Hi Kate,

Thank you for all the work you're doing on that. Once you have another look tomorrow do let me know how it goes.

Regards,

Shannon

[Katharina Wolkwitz]

Hi Shannon,

finally I've found the time to have a look at a bunch of six errors happening within about one minute and to pick out the code from the debug-log-file, the report-code and the server-log-file. I've also added the debug-code-snippets for three synchronization events that went through without any problem.

You can find all these files in one folder in my dropbox under this link:

https://www.dropbox.com/sh/kmpy187gqvdc0up/AAB1sbTOnXw46ALSm2Zm6B4xa?dl=0

While comparing the different files I found the CalDav-Synchronizer debug-files and report-code very similar (almost identical) whereas the server-log-file is rather different.

As for understanding what's happening - I'm afraid it could as well be written in Mandarin or Arameic. :-(

But I found out one thing that is different between the error-debug-files/reports and those for the successful synchronizations. When there was an error the identification of the calendar is missing:

Something like /plugins/servlet/team-calendars/caldav/1f893fd4-f217-4e75-ac36-779337675d6b/ exists both in the server-log and the CalDav-debug-log and report-file when a synchroniziation is a success, but not when there's an error.

Perhaps that might help narrow down the search?

I'm going to be away on a trainig course from Monday till Thursday next week, so I won't be able to continue our communication before next Friday.

Wishing you a happy weekend!

Kate

[Shannon S]

Thank you, Kate.

If you're not comfortable reviewing the logs from the Synchronizer then I would recommend raising a ticket with the creator themselves.

As I showed earlier, they have a support portal here:

• Outlook CalDav Synchronizer Tickets

They're familiar with their log files and will be able to let you know what the problem is.

Regards,

Shannon