BufferedOutputStream (was: Releasing 2.1.12 - a new release manager?)

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.

Joerg

/*
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 * 
 *      http://www.apache.org/licenses/LICENSE-2.0
 * 
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
package org.apache.cocoon.util;

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

Cocoon 2.1 and Cocoon 2.2

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                  reinhard <at> apache.org
________________________________________________________________________

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                  reinhard <at> apache.org
________________________________________________________________________

[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