Ralph Goers wrote:
Glad it worked out.
However, I still have a feeling that holding the lock while checking the
validity will create some contention in our usage since multiple threads
do want to read the file simultaneously.
Yup; try this delay validity idea.
If you want to fly out to
Sorry for not getting back to you sooner. I was swamped doing some
performance tuning.
I am using the authentication-fw and I have my own generator that calls
our authentication component and then generates the appropriate XML
response. During that proces the getInstance() is called. I also c
On Friday 16 December 2005 00:53, Jorg Heymans wrote:
> well it's not just the cocoon artifact i'm talking about. Various of our
> dependent libs aren't on ibiblio yet, so i uploaded them to
> cvs.apache.org.
Ok. But even better if you coordinate with the Maven peeps, so that everyone
else gets
Vadim and Berin,
Thank you both for your assistance. We got past this. The problem was
actually simple. The XMLFileModule was configured with reloadable false
and cacheable false. Since this file is read at the beginning of every
user session it was causing a huge bottleneck. After setting
Vadim Gritsenko wrote:
"http-8080-Processor17" daemon prio=1 tid=0x2e3d58c8 nid=0x19eb waiting
for monitor entry [2d7f3000..2d7f587c]
at
org.apache.avalon.excalibur.pool.ResourceLimitingPool.get(ResourceLimitingPool.java:262)
- waiting to lock <0x60088180> (a java.lang.Object)
...
The only
Berin Loritsch wrote:
Vadim Gritsenko wrote:
Ralph Goers wrote:
My guess is that the requests are simply coming in faster than
XMLFileModule is taking to release the lock.
That's not important, IMHO. Problem is in pool's lock, not
XMLFileModule's lock.
Are you sure?
90% sure. Have a lo
Vadim Gritsenko wrote:
Ralph Goers wrote:
OK. I'm wondering if the real problem is simply that the getDocument
method is completely synchronized?
It's *good*. You don't really want several threads trying to load
*same* document.
It's not perfect though. I see that XMLFileModule, when use
Ralph Goers wrote:
OK. I'm wondering if the real problem is simply that the getDocument
method is completely synchronized?
As far as pools go, I feel like a complete idiot. See my comments below.
Vadim Gritsenko wrote:
Ralph Goers wrote:
Thanks Vadim. I'm posting this back to the Cocoon li
Vadim Gritsenko wrote:
Ralph Goers wrote:
Also, Do you know why Document helper is declared static?
DocumentHelper *class* is static. Why it should not be?
Is DocumentHelper an inner class? If so I agree, all that the static on
a class means is that the inner class can (should?) be in
Jorg Heymans wrote:
>
> Andreas Hochsteger wrote:
>
>> But how would it be possible to say that the samples block depends on
>> any implementation which implements a certain API, like the roles
>> are used in Cocoon today? For example, my-block-samples-block needs
>> an XSL:FO processor but doe
Vadim Gritsenko wrote:
Ralph Goers wrote:
Also, Do you know why Document helper is declared static?
DocumentHelper *class* is static. Why it should not be?
Just never seen it before the way it is being used. After reading about
it I guess it is OK.
Vadim
SVN)
Reporter: Jean-Baptiste Quenot
Attachments: 20051216-continuationsmanager, contierror
Build Cocoon without any block.
When starting Cocoon with "cocoon.sh cli" there is an error:
NoClassDefFoundError javax/servlet/http/HttpSessionBindingListener, see error
log atta
Ralph Goers wrote:
Also, Do you know why Document helper is declared static?
DocumentHelper *class* is static. Why it should not be?
Vadim
Ralph Goers wrote:
OK. I'm wondering if the real problem is simply that the getDocument
method is completely synchronized?
It's *good*. You don't really want several threads trying to load *same*
document.
It's not perfect though. I see that XMLFileModule, when used in conjunction with
cocoo
* Max Pfingsthorn:
> I would like to start rejuventating the webdav block. We have
> some code to do cool things like event caching and a more
> general purpose WebDAVTransformer (which can also do propfind,
> proppatch, etc).
>
> If you know anything you would like to see in the webd
Also, Do you know why Document helper is declared static?
Ralph
Vadim Gritsenko wrote:
I've not looked into pool source code yesterday to double check all
points myself. I'm suggesting you to check:
* What type of pool is really used
* Why it is blocking (I guessed it is blocking due t
Le 16 déc. 05, à 17:12, Antonio Gallardo a écrit :
...Found the problem in
http://cocoon.zones.apache.org/logs/cocoon-demos/21branch/stderr.log:
I was not aware we have this link. It is great!
BTW is this stderr or stdout? ;-)
This is stderr, see the links to all logs in the yellow box at
Bertrand,
Thanks for fixing the demo site.
Bertrand Delacretaz wrote:
Le 16 déc. 05, à 16:10, Antonio Gallardo a écrit :
...Few days ago I updated groovy and asm. I also replaced
excalibur-io with commons-io. But this changes are not showed here:
http://cocoon.zones.apache.org/demos/21bra
OK. I'm wondering if the real problem is simply that the getDocument
method is completely synchronized?
As far as pools go, I feel like a complete idiot. See my comments below.
Vadim Gritsenko wrote:
Ralph Goers wrote:
Thanks Vadim. I'm posting this back to the Cocoon list as it seems
wha
* Stefan Pietschmann:
>
> When my component is looked up, I try to fetch the objectModel (to get the
> context as you suggested). Therefore I implement Contextualizable:
>
> public void contextualize(Context context) {
> Map objectModel = ContextHelper.getObjectModel(context);
> H
Ralph Goers wrote:
Thanks Vadim. I'm posting this back to the Cocoon list as it seems what
you are telling me is that the problem is either with the XMLFileModule
or with running out of components in the pool on the pipeline being
invoked.
What I am not clear on is what you are trying to tell
Le 16 déc. 05, à 16:10, Antonio Gallardo a écrit :
...Few days ago I updated groovy and asm. I also replaced
excalibur-io with commons-io. But this changes are not showed here:
http://cocoon.zones.apache.org/demos/21branch/samples/status.html
Found the problem in
http://cocoon.zones.apache
Hi cocoon-ers,
Few days ago I updated groovy and asm. I also replaced excalibur-io
with commons-io. But this changes are not showed here:
http://cocoon.zones.apache.org/demos/21branch/samples/status.html
Help! :-)
Seriously, somebody can take care of this? Thanks in advance.
Best Regards,
On 12/16/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote:
> Dear Cocooners,
>
> I would like to start rejuventating the webdav block. We have some code to do
> cool things like event caching and a more general purpose WebDAVTransformer
> (which can also do propfind, proppatch, etc).
>
> If you know
Dear Cocooners,
I would like to start rejuventating the webdav block. We have some code to do
cool things like event caching and a more general purpose WebDAVTransformer
(which can also do propfind, proppatch, etc).
If you know anything you would like to see in the webdav block, please say so
I'm sorry, I still don't completely get it. I assume that SessionData is the
class that implements HTTPSessionBindingListener?
So you call getInstance() during login, which adds the component
(SessionData) to the Session. It will then be notified, when it is unbound
from the session, which allows
Good idea. I tried this, but failed.
When my component is looked up, I try to fetch the objectModel (to get the
context as you suggested). Therefore I implement Contextualizable:
public void contextualize(Context context) {
Map objectModel = ContextHelper.getObjectModel(context);
27 matches
Mail list logo