Re: BufferedOutputStream
Joerg Heinicke wrote: On 29.05.2008 00:06, Joerg Heinicke wrote: Only issue I want to solve before the release is the BufferedOutputStream issue. I planned to do it this weekend. Done. Please review the file attached. It's still completely untested. At the moment I need some sleep ;) I will write junit tests for it this week and eventually commit it. Stupid question: why do we need a special BufferedOutputStream? Sylvain -- Sylvain Wallez - http://bluxte.net
Re: BufferedOutputStream
On 02.06.2008 05:56, Sylvain Wallez wrote: Only issue I want to solve before the release is the BufferedOutputStream issue. I planned to do it this weekend. Done. Please review the file attached. It's still completely untested. At the moment I need some sleep ;) I will write junit tests for it this week and eventually commit it. Stupid question: why do we need a special BufferedOutputStream? For being able to reset the response buffer for error handling. This is also possible with java.io.BufferedOutputStream, if the buffer size is big enough (current default value is 1MB), but then the buffer byte[] is always that big rather than increasing. That's what's happening right now, if you don't specify -1 as buffer size. -1 means complete buffering which on the other hand might lead to OutOfMemoryError [1]. In addition our BOS counts the bytes so that we can use the value to set the content length header. Joerg [1] https://issues.apache.org/jira/browse/COCOON-2168
Re: BufferedOutputStream
Joerg Heinicke wrote:
On 02.06.2008 05:56, Sylvain Wallez wrote:
Only issue I want to solve before the release is the
BufferedOutputStream issue. I planned to do it this weekend.
Done. Please review the file attached. It's still completely
untested. At the moment I need some sleep ;) I will write junit tests
for it this week and eventually commit it.
Stupid question: why do we need a special BufferedOutputStream?
For being able to reset the response buffer for error handling. This is
also possible with java.io.BufferedOutputStream, if the buffer size is
big enough (current default value is 1MB), but then the buffer byte[] is
always that big rather than increasing. That's what's happening right
now, if you don't specify -1 as buffer size. -1 means complete buffering
which on the other hand might lead to OutOfMemoryError [1]. In addition
our BOS counts the bytes so that we can use the value to set the content
length header.
Is my understanding right that the content length header can only be set
as long as you haven't written into the underlying output stream?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
Re: Cocoon 2.1 and Cocoon 2.2
Andrew Savory wrote:
Hi all,
Here's a question for you. What's the deal with patches and fixes for
Cocoon 2.1 and Cocoon 2.2?
I have some fixes to apply to 2.1 for COCOON-2152, and I figured I
should apply it to 2.2 as well. However, after reviewing the code for
2.2, it seems there's some divergence since the two were separated.
See for example EventAwareCacheImpl in branch [1] and trunk [2],
where there are 8 'meta' modifications (moving stuff around) but also
two serious fixes, at least one of which could probably have been
made to 2.1.
So, are we aiming to keep 2.1 and 2.2 in sync as much as possible, or
do I need to work on two different sets of bugfixes?
My take on this is that every bugfix or enhancement should go at least
into trunk. If you have the need for adding it to the 2.1. branch too,
keep it in sync with trunk but I wouldn't want to enforce it by some rule.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
[jira] Closed: (COCOON-2152) EventAware cache does not persist correctly when using the StoreEventRegistryImpl
[ https://issues.apache.org/jira/browse/COCOON-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Savory closed COCOON-2152. - Resolution: Fixed Fix Version/s: 2.1.12-dev (Current SVN) Fixed in SVN. Patch from Ellis applied, and a separate fix for samples added. EventAware cache does not persist correctly when using the StoreEventRegistryImpl - Key: COCOON-2152 URL: https://issues.apache.org/jira/browse/COCOON-2152 Project: Cocoon Issue Type: Bug Components: Blocks: Event Cache Affects Versions: 2.1.10, 2.1.11, 2.2 Reporter: Ellis Pritchard Assignee: Andrew Savory Fix For: 2.1.12-dev (Current SVN) When using the DefaultEventRegistryImpl the functionality now works as expected (events are persisted and restored) after the patch applied in COCOON-2146. However, there's still a problem with StoreEventRegistryImpl. The behaviour is that it doesn't seem to actually write/restore any event entries: the maps in the EventRegistryDataWrapper are empty (but not null) after restart, even though the actual cache entry (key EVENTREGWRAPPER) was found in the Store, and the entries were present when persist() was called. The effect of this is to correctly restore the cached entries, but discard all the events, which means that event-flushes don't work any more, which is not a good thing. I've tracked this down to the fact that AbstractDoubleMapEventRepository#dispose() which performs the persist(), then immediately clear()s the maps, WHICH HAVEN'T YET BEEN WRITTEN TO DISK BY EHCACHE SHUTDOWN! This code has probably never worked :) Patches to follow; I propose modifying dispose() to null the map fields, but not perform clear() on them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Cocoon 2.1 and Cocoon 2.2
Reinhard Pötz wrote: Andrew Savory wrote: Hi all, Here's a question for you. What's the deal with patches and fixes for Cocoon 2.1 and Cocoon 2.2? I have some fixes to apply to 2.1 for COCOON-2152, and I figured I should apply it to 2.2 as well. However, after reviewing the code for 2.2, it seems there's some divergence since the two were separated. See for example EventAwareCacheImpl in branch [1] and trunk [2], where there are 8 'meta' modifications (moving stuff around) but also two serious fixes, at least one of which could probably have been made to 2.1. So, are we aiming to keep 2.1 and 2.2 in sync as much as possible, or do I need to work on two different sets of bugfixes? My take on this is that every bugfix or enhancement should go at least into trunk. If you have the need for adding it to the 2.1. branch too, keep it in sync with trunk but I wouldn't want to enforce it by some rule. +1! -- Grzegorz Kossakowski
Re: BufferedOutputStream
Reinhard Pötz reinhard at apache.org writes: Is my understanding right that the content length header can only be set as long as you haven't written into the underlying output stream? Yes, it is. That's why the buffering has to be big enough, i.e. nothing must have been flushed yet. Joerg
[VOTE][result]Drop JDK1.3 support for Cocoon 2.1.11 and newer versions
Hi all, the vote for dropping JDK 1.3 support for Cocoon 2.1.11+ has been accepted by 12 +1 votes and no negative one. I'm going to move the artifacts into the Apache Maven Maven 1 synch repository in the next couple of days and will send a response to this mailinglist as a confirmation when it has been done. Regards, Jeroen Reijn
Re: [VOTE][result]Drop JDK1.3 support for Cocoon 2.1.11 and newer versions
Jeroen Reijn pisze: Hi all, the vote for dropping JDK 1.3 support for Cocoon 2.1.11+ has been accepted by 12 +1 votes and no negative one. I'm going to move the artifacts into the Apache Maven Maven 1 synch repository in the next couple of days and will send a response to this mailinglist as a confirmation when it has been done. Jeroen, what about announcing this decision? I think result of this vote deserves at least a news item on our front page. PS. Thanks for your work! -- Grzegorz Kossakowski
Re: [VOTE][result]Drop JDK1.3 support for Cocoon 2.1.11 and newer versions
On Jun 2, 2008, at 5:19 PM, Grzegorz Kossakowski wrote: Jeroen Reijn pisze: Hi all, the vote for dropping JDK 1.3 support for Cocoon 2.1.11+ has been accepted by 12 +1 votes and no negative one. I'm going to move the artifacts into the Apache Maven Maven 1 synch repository in the next couple of days and will send a response to this mailinglist as a confirmation when it has been done. Jeroen, what about announcing this decision? It should (i'd say must) be noted in change log (status.xml). I think result of this vote deserves at least a news item on our front page. That is IMHO not really needed but won't hurt at all, so please add if you want to :) Vadim
