Mailing List Archive

Hi,

I'm having trouble for some days now with my davical server with one
calendar (the biggest one). All other calendars are working. I'm using
iceowl 0.8 as a client. When I try to load the URL in the browser,
I get following error:

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
allocate 282356 bytes) in /usr/share/davical-0.9.7-0/inc/caldav-GET.php
on line 169

This calender contains about 400-500 events over a period of about
2 years. Any ideas?

Thanks in advance,

Armin

Michael Rasmussen wrote:
> On Sat, 14 Nov 2009 10:31:48 +0100
> Armin Fuerst <afuerst at cogidata.com> wrote:
>
>> Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
>> allocate 282356 bytes) in /usr/share/davical-0.9.7-0/inc/caldav-GET.php
>> on line 169
>>
> Try adjusting this option in your php.ini file:
> post_max_size = 8M
>
> The above is the default setting.

Yes, this is working. But what if the events increase till 1000 or 2000
events? Do I have to increase this again? 8M for around 500 events seems
quite a lot to me...

Armin

Armin Fuerst wrote:

> Michael Rasmussen wrote:
>> On Sat, 14 Nov 2009 10:31:48 +0100
>> Armin Fuerst <afuerst at cogidata.com> wrote:
>>
>>> Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
>>> allocate 282356 bytes) in /usr/share/davical-0.9.7-0/inc/caldav-GET.php
>>> on line 169
>>>
>> Try adjusting this option in your php.ini file:
>> post_max_size = 8M
>>
>> The above is the default setting.
>
> Yes, this is working. But what if the events increase till 1000 or 2000
> events? Do I have to increase this again? 8M for around 500 events seems
> quite a lot to me...
>
> Armin
>

Default php 5.3 is 32MB recommended ...

--

Bruno Friedmann

Hi,

On Sat, 14 Nov 2009, Armin Fuerst wrote:

> Michael Rasmussen wrote:
> > On Sat, 14 Nov 2009 10:31:48 +0100
> > Armin Fuerst <afuerst at cogidata.com> wrote:
> >
> >> Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
> >> allocate 282356 bytes) in /usr/share/davical-0.9.7-0/inc/caldav-GET.php
> >> on line 169
> >>
> > Try adjusting this option in your php.ini file:
> > post_max_size = 8M
> >
> > The above is the default setting.
>
> Yes, this is working.

I must admit, the error above would lead me to adjust the memory_limit not
the post_max_size (though I think the default value for memory limit is
16MB and the above seems to be hitting an 8MB limit).

> But what if the events increase till 1000 or 2000 events? Do I have to
> increase this again? 8M for around 500 events seems quite a lot to me...

Can I ask what's happening here? If the post_max_size limit is being hit,
that suggests that the client is sending 8MB of data to the server. I
don't (yet) know much about caldav but I imagined the point was that the
client-server data would be granular requests and responses of calendar
events, not an entire calendar being sent -- so I wouldn't expect a large
calendar to mean larger transfers (excepting perhaps that the index would
grow in a big calendar). 8MB seems like an awful lot for a client to send
to a server.

Do you attach large files to your calendar entries by any chance?

Gavin

On Sat, 14 Nov 2009 12:56:57 +0000
Gavin McCullagh <gavin.mccullagh at gcd.ie> wrote:
> I must admit, the error above would lead me to adjust the memory_limit
The memory_limit has nothing to do with the transfer size. memory_limit
solely controls the maximum among of memery any running php script can
consume.

> events, not an entire calendar being sent -- so I wouldn't expect a large
> calendar to mean larger transfers (excepting perhaps that the index would
> grow in a big calendar). 8MB seems like an awful lot for a client to send
> to a server.
>
DAViCal officially supports WebDAV. One of the special annoyances with
WebDAV is that the entire calendar is transfered each and every time a
request is made.


--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
A day for firm decisions!!!!! Or is it?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20091114/747096eb/attachment-0001.pgp>
-------------- next part --------------

Hi,

On Sat, 14 Nov 2009, Michael Rasmussen wrote:

> On Sat, 14 Nov 2009 12:56:57 +0000
> Gavin McCullagh <gavin.mccullagh at gcd.ie> wrote:
> > I must admit, the error above would lead me to adjust the memory_limit
> The memory_limit has nothing to do with the transfer size. memory_limit
> solely controls the maximum among of memery any running php script can
> consume.

Agreed. But the error says memory size exceeded:

>>>>> Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
>>>>> allocate 282356 bytes) in /usr/share/davical-0.9.7-0/inc/caldav-GET.php
>>>>> on line 169

I'm noy saying the post_max_size isn't the correct solution, I'm just
observing that the error doesn't obviously suggest it.

> > events, not an entire calendar being sent -- so I wouldn't expect a large
> > calendar to mean larger transfers (excepting perhaps that the index would
> > grow in a big calendar). 8MB seems like an awful lot for a client to send
> > to a server.
> >
> DAViCal officially supports WebDAV. One of the special annoyances with
> WebDAV is that the entire calendar is transfered each and every time a
> request is made.

Ah. I understand. So the proper solution is to use CalDAV not WebDAV.
Armin: are you using WebDAV?

Gavin

On Sat, 2009-11-14 at 13:48 +0000, Gavin McCullagh wrote:
>
> >>>>> Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
> >>>>> allocate 282356 bytes) in /usr/share/davical-0.9.7-0/inc/caldav-GET.php
> >>>>> on line 169
>

> > >
> > DAViCal officially supports WebDAV. One of the special annoyances with
> > WebDAV is that the entire calendar is transfered each and every time a
> > request is made.
>
> Ah. I understand. So the proper solution is to use CalDAV not WebDAV.
> Armin: are you using WebDAV?

He must be, because line 169 is part of the WebDAV code - there's no
other way to get there.

One solution might be to restrict the DAViCal response for read-only
WebDAV to only include events with instances after some relative date.

That probably wouldn't be such a great idea for writable webdav (which
is disabled by default anyway), but for read-only webdav it might be an
appropriate optional setting.

Cheers,
Andrew.


------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/ Porirua, New Zealand
Twitter: _karora Phone: +64(272)DEBIAN
Keep emotionally active. Cater to your favorite neurosis.
------------------------------------------------------------------------

-------------- 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/20091115/fcf51c32/attachment.pgp>
-------------- next part --------------

Andrew McMillan wrote:
> On Sat, 2009-11-14 at 13:48 +0000, Gavin McCullagh wrote:
>>>>>>> Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
>>>>>>> allocate 282356 bytes) in /usr/share/davical-0.9.7-0/inc/caldav-GET.php
>>>>>>> on line 169
>
>>> DAViCal officially supports WebDAV. One of the special annoyances with
>>> WebDAV is that the entire calendar is transfered each and every time a
>>> request is made.
>> Ah. I understand. So the proper solution is to use CalDAV not WebDAV.
>> Armin: are you using WebDAV?
>
> He must be, because line 169 is part of the WebDAV code - there's no
> other way to get there.

I always thought I would use CalDAV. In iceowl, I *certainly* have
configured CalDAV. Might my configuration in apache cause a mixture?

Armin

> One solution might be to restrict the DAViCal response for read-only
> WebDAV to only include events with instances after some relative date.
>
> That probably wouldn't be such a great idea for writable webdav (which
> is disabled by default anyway), but for read-only webdav it might be an
> appropriate optional setting.
>
> Cheers,
> Andrew.
>
>
> ------------------------------------------------------------------------
> http://andrew.mcmillan.net.nz/ Porirua, New Zealand
> Twitter: _karora Phone: +64(272)DEBIAN
> Keep emotionally active. Cater to your favorite neurosis.
> ------------------------------------------------------------------------
>
>
>
> ------------------------------------------------------------------------
>

Andrew McMillan wrote:
> On Sat, 2009-11-14 at 13:48 +0000, Gavin McCullagh wrote:
>>>>>>> Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
>>>>>>> allocate 282356 bytes) in /usr/share/davical-0.9.7-0/inc/caldav-GET.php
>>>>>>> on line 169
>
>>> DAViCal officially supports WebDAV. One of the special annoyances with
>>> WebDAV is that the entire calendar is transfered each and every time a
>>> request is made.
>> Ah. I understand. So the proper solution is to use CalDAV not WebDAV.
>> Armin: are you using WebDAV?
>
> He must be, because line 169 is part of the WebDAV code - there's no
> other way to get there.

I always thought I would use CalDAV. In iceowl, I *certainly* have
configured CalDAV. Might my configuration in apache cause a mixture?

Armin

> One solution might be to restrict the DAViCal response for read-only
> WebDAV to only include events with instances after some relative date.
>
> That probably wouldn't be such a great idea for writable webdav (which
> is disabled by default anyway), but for read-only webdav it might be an
> appropriate optional setting.
>
> Cheers,
> Andrew.
>
>
> ------------------------------------------------------------------------
> http://andrew.mcmillan.net.nz/ Porirua, New Zealand
> Twitter: _karora Phone: +64(272)DEBIAN
> Keep emotionally active. Cater to your favorite neurosis.
> ------------------------------------------------------------------------
>
>
>
> ------------------------------------------------------------------------
>

On Sun, 2009-11-15 at 00:08 +0100, Armin Fuerst wrote:
> Andrew McMillan wrote:
> > On Sat, 2009-11-14 at 13:48 +0000, Gavin McCullagh wrote:
> >>>>>>> Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
> >>>>>>> allocate 282356 bytes) in /usr/share/davical-0.9.7-0/inc/caldav-GET.php
> >>>>>>> on line 169
> >
> >>> DAViCal officially supports WebDAV. One of the special annoyances with
> >>> WebDAV is that the entire calendar is transfered each and every time a
> >>> request is made.
> >> Ah. I understand. So the proper solution is to use CalDAV not WebDAV.
> >> Armin: are you using WebDAV?
> >
> > He must be, because line 169 is part of the WebDAV code - there's no
> > other way to get there.
>
> I always thought I would use CalDAV. In iceowl, I *certainly* have
> configured CalDAV. Might my configuration in apache cause a mixture?

I seem to recall there might have been some bugs in 0.8 that switched to
WebDAV without the user noticing it had happened, and that kind of
behaviour is why I changed the default WebDAV access to be read-only.

It's a shame that various constraints have meant there hasn't been a
Mozilla Calendar release for some considerable time, and my
recommendation to anyone using Lightning / Sunbird would be to use
something as close to 1.0 as possible, even if it does mean downloading
it directly rather than using the horribly outdated OS-supplied version.

Cheers,
Andrew.


------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/ Porirua, New Zealand
Twitter: _karora Phone: +64(272)DEBIAN
A few hours grace before the madness begins again.
------------------------------------------------------------------------

-------------- 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/20091115/d7679844/attachment.pgp>
-------------- next part --------------

On Sun, 15 Nov 2009 13:46:31 +1300
Andrew McMillan <andrew at morphoss.com> wrote:

> It's a shame that various constraints have meant there hasn't been a
> Mozilla Calendar release for some considerable time, and my
> recommendation to anyone using Lightning / Sunbird would be to use
> something as close to 1.0 as possible, even if it does mean downloading
> it directly rather than using the horribly outdated OS-supplied version.
>
Running version 0.9 of Sunbird. This version has fixes of a number of
major critical bugs. As I recall it the developers consider anything
below 0.9 to be completely useless regarding CalDAV.

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
You will be audited by the Internal Revenue Service.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20091115/d7a278b0/attachment.pgp>
-------------- next part --------------

Thanks for the info about the 0.8 version. I'm currently on the process
of updating to 0.9 (available in experimental).
But I have one comment being possibly important: The error I posted at
the beginning was a result of my request through the browser (and in my
first post I mentioned this). Might this have caused the the mixture
CalDAV / WebDAV?

Armin


Andrew McMillan wrote:
> On Sun, 2009-11-15 at 00:08 +0100, Armin Fuerst wrote:
>> Andrew McMillan wrote:
>>> On Sat, 2009-11-14 at 13:48 +0000, Gavin McCullagh wrote:
>>>>>>>>> Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
>>>>>>>>> allocate 282356 bytes) in /usr/share/davical-0.9.7-0/inc/caldav-GET.php
>>>>>>>>> on line 169
>>>>> DAViCal officially supports WebDAV. One of the special annoyances with
>>>>> WebDAV is that the entire calendar is transfered each and every time a
>>>>> request is made.
>>>> Ah. I understand. So the proper solution is to use CalDAV not WebDAV.
>>>> Armin: are you using WebDAV?
>>> He must be, because line 169 is part of the WebDAV code - there's no
>>> other way to get there.
>> I always thought I would use CalDAV. In iceowl, I *certainly* have
>> configured CalDAV. Might my configuration in apache cause a mixture?
>
> I seem to recall there might have been some bugs in 0.8 that switched to
> WebDAV without the user noticing it had happened, and that kind of
> behaviour is why I changed the default WebDAV access to be read-only.
>
> It's a shame that various constraints have meant there hasn't been a
> Mozilla Calendar release for some considerable time, and my
> recommendation to anyone using Lightning / Sunbird would be to use
> something as close to 1.0 as possible, even if it does mean downloading
> it directly rather than using the horribly outdated OS-supplied version.
>
> Cheers,
> Andrew.
>
>
> ------------------------------------------------------------------------
> http://andrew.mcmillan.net.nz/ Porirua, New Zealand
> Twitter: _karora Phone: +64(272)DEBIAN
> A few hours grace before the madness begins again.
> ------------------------------------------------------------------------
>

On Sun, 15 Nov 2009 11:58:55 +0100
Armin Fuerst <afuerst at cogidata.com> wrote:

> But I have one comment being possibly important: The error I posted at
> the beginning was a result of my request through the browser (and in my
> first post I mentioned this). Might this have caused the the mixture
> CalDAV / WebDAV?
>
I browser does not know anything about CalDAV. It has only knowledge
about DAV - in this case WebDAV.

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
You are always busy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20091115/f98f9c2e/attachment.pgp>
-------------- next part --------------

On Sun, 2009-11-15 at 11:58 +0100, Armin Fuerst wrote:
> Thanks for the info about the 0.8 version. I'm currently on the process
> of updating to 0.9 (available in experimental).
>
> But I have one comment being possibly important: The error I posted at
> the beginning was a result of my request through the browser (and in my
> first post I mentioned this). Might this have caused the the mixture
> CalDAV / WebDAV?

Hi Armin,

Yes, your web browser will generally only do GET or POST methods. You
need a DAV client (or CalDAV client) to do the more advanced PROPFIND,
REPORT, OPTIONS, PROPPATCH, PUT, DELETE and so forth that are important
parts of CalDAV.

I'd missed that you were seeing this error when accessing the calendar
through a web browser in the earlier communication.

Do you have any errors using it with a calendaring client?

Cheers,
Andrew.

------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
You may be recognized soon. Hide.
------------------------------------------------------------------------

-------------- 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/20091116/e81957c8/attachment.pgp>
-------------- next part --------------