Hi,
You can replace default VirtualAssetStreamer with your implementation by
contributing it to ServiceOverride (contributeServiceOverride). Your version
of VirtualAssetStreamer can be based on
existing org.apache.tapestry5.internal.services.VirtualAssetStreamerImpl,
just replace all references of
Thanks Howard!
Unortunately we need some time to migrate to 5.2.x and we face this
issues each day, thus loosing our cluster and shop-customers. Downtimes
each day because of this issue is, well, ugly to horrible depending on
whom you ask...
Unfortunately we depend on "core" library mappings i
This is known and fixed in 5.2.
On Thu, Sep 22, 2011 at 3:36 AM, Jens Breitenstein wrote:
> Hi All!
>
> It seems we encountered a serious concurrency bug in Tapestry 5.1> under
> high load.
> In our special case one thread was blocked and unable to respond and write
> an asset output stream.
> As
Hi All!
It seems we encountered a serious concurrency bug in Tapestry 5.1> under
high load.
In our special case one thread was blocked and unable to respond and
write an asset output stream.
As virtual assets are shared and the same ByteArrayOutputStream is
reused for the same asset accross mu
