* Ralph Goers:
Thatupdate includedsome newcalculators written
in flowscript. This versionof Cocoonis using
rhino1.5r4-continuations-20040629T1232.jar.
Ralph,
Have you tried to replace this jar with Cocoon trunk's Rhino jar?
We are successfully running
On 1/19/06, Ralph Goers [EMAIL PROTECTED] wrote:
I looked at what I believe is the right version of
ContinuationInterpreter
(http://svn.cocoondev.org/repos/rhino+cont/branches/BEFORE_PACKAGENAME_CHANGE/rhino1_5R4pre/src/org/mozilla/javascript/continuations/ContinuationInterpreter.java)
and
No. I might suggest they test it in our development environment after
they get the system stabilized.
Jean-Baptiste Quenot wrote:
* Ralph Goers:
Thatupdate includedsome newcalculators written
in flowscript. This versionof Cocoonis using
I thought I'd update you all on the problems we have been having with
our production deployment. We finally rolled out an update that include
proper pool sizes for the components and the fix to the Castor mapping
file. However, before we did that our system engineer provided some
valuable
On 1/18/06, Ralph Goers [EMAIL PROTECTED] wrote:
However, we have been able to recreate the loop without entering bad
data.
How ? Just random pounding on the calculator?
Thoughts and comments are welcome.
Looks to me like both times you've caught the process of a
continuation being
Peter Hunsberger wrote:
On 1/18/06, Ralph Goers [EMAIL PROTECTED] wrote:
However, we have been able to recreate the loop without entering bad
data.
How ? Just random pounding on the calculator?
Yup. With nornal input.
Thoughts and comments are welcome.
Looks to me
* Ralph Goers:
OK. I ran some basic tests on one of my machines. Just for basic info it is
a P4 2.5 GHz with 1 GB of memory
running RHEL 3.
The only thing I did was set up JMeter to login to the portal as user cocoon.
In all the tests the computer was
maxed at 100% cpu.
Before the
I replied to that days ago in the issue (1709 I believe). In short,
this is a good idea for sites (like mine) that only use anonymous
users. However, the idea of permanantly caching millions of users
profiles in memory is very scary and will be considered to be a memory
leak by many people.
* Ralph Goers:
I replied to that days ago in the issue (1709 I believe).
Sorry, I didn't notice your comment on JIRA, strangely. I will
followup to your comment.
--
Jean-Baptiste Quenot
Systèmes d'Information
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
Ralph Goers wrote:
OK. I ran some basic tests on one of my machines. Just for basic info it is
a P4 2.5 GHz with 1 GB of memory
running RHEL 3.
The only thing I did was set up JMeter to login to the portal as user
cocoon. In all the tests the computer was
maxed at 100% cpu.
Before the
I used the latest source for both 2.1 and trunk.
Carsten Ziegeler wrote:
Ralph Goers wrote:
OK. I ran some basic tests on one of my machines. Just for basic info it is a P4 2.5 GHz with 1 GB of memory
running RHEL 3.
The only thing I did was set up JMeter to login to the portal as user
OK. I ran some basic tests on one of my machines. Just for basic info
it is a P4 2.5 GHz with 1 GB of memory running RHEL 3.
The only thing I did was set up JMeter to login to the portal as user
cocoon. In all the tests the computer was maxed at 100% cpu.
Before the change:
5 threads login
We took some thread dumps of our product when it was running normally.
It was interesting in that we still saw in almost every stack trace the
portal calling castor which was in the class loader throwing a
ClassNotFoundException. I then stepped through the sample site and have
discovered that
OK. I figured out how to use the matches attribute and was able to
verify that it doesn't throw ClassNotFoundExceptions all the time. I'll
do a little load testing next to see what kind of difference it makes on
throughput.
Ralph Goers wrote:
We took some thread dumps of our product when it
Castor seems to have a lot of useful little hacks - I just found out,
that we can prevent castor from checking for default constructors which
I really needed for 2.2 - it's there, you only have to find out how to
configure it :). Im curious how the matches configuration looks like :)
Carsten
Ralph Goers wrote:
...
when
bind-xml auto-naming=deriveByClass
is used, Castor starts making up names and trying to load them.
...
I expect, when the resource pool is exceeded the
class loader is completely overstressed and the system comes to a
grinding halt. It doesn't actually stop, but
Vadim Gritsenko wrote:
Ralph Goers wrote:
...
when
bind-xml auto-naming=deriveByClass
is used, Castor starts making up names and trying to load them.
...
I expect, when the resource pool is exceeded the class loader is
completely overstressed and the system comes to a grinding halt. It
I'll check them in as soon as I get some testing done. Shouldn't be too
long.
Carsten Ziegeler wrote:
Castor seems to have a lot of useful little hacks - I just found out,
that we can prevent castor from checking for default constructors which
I really needed for 2.2 - it's there, you only
Ralph Goers wrote:
We tried to deploy an update to our product. Pretty much the only
thing we did to Cocoon was to replace Xalan with XSLTC which produces
a dramatic performance improvement. However, Cocoon is not
consistently hanging. I tried to attach the thread dumps but they are
too
On Dec 24, 2005, at 12:16 PM, Ralph Goers wrote:
Has anyone had problems with ehcache? I suspect that our problems
are being caused by problems with data being returned from the
cache when the cache starts writing to disk.
Do you really need persistence store? If not, replace store with
Has anyone had problems with ehcache? I suspect that our problems are
being caused by problems with data being returned from the cache when
the cache starts writing to disk.
Ralph
Does anyone have any experience with these binding frameworks?
https://bindmark.dev.java.net/
It sure looks like Castor is a poor choice for what the portal is
doing. Notably missing from the list is JaxMe.
Ralph
Carsten Ziegeler wrote:
The latest version of Castor has bugs in the
We are running Sun JDK 1.4.2_05 on RHEL 3. The Tomcat is 5.0 something
(I'm out of tow at the moment so I don't have access to the info).
Frankly, I'm suspecting that ehcache is returning a bad document to
Castor although I don't have any proof. But if that is the case I
really would have
Thanks for the info. Do you think we should rewrite this using Digester
instead of Castor?
Carsten Ziegeler wrote:
Someone told me some months ago that they experienced several strange
issues with castor under load - I think he mentioned class loading and
synchronization problems. I still
Ralph Goers wrote:
Thanks for the info. Do you think we should rewrite this using Digester
instead of Castor?
I never really liked Castor; at the time when we started with the
portal Digester was not usable for us as there were some problems
with complex types like lists and maps (at least
Ralph Goers wrote:
Thanks for the info. Do you think we should rewrite this using Digester
instead of Castor?
Commons Digester is only a one-way tool: XML-Java.
Castor could be replaced by XMLBeans (if you need to use XML Schema), XStream
(if you only want to de/serialiaze XML to Java) or
What were the problems you had with the last version of Castor you
tried? (I believe a new version is now available).
Reinhard pointed out a potential problem with Digester - we have to
write out the instance data when preferences are updated.
I wish I understood what exactly the problem is.
Ralph Goers wrote:
What were the problems you had with the last version of Castor you
tried? (I believe a new version is now available).
Reinhard pointed out a potential problem with Digester - we have to
write out the instance data when preferences are updated.
Does the data follow an XML
Ralph Goers wrote:
What were the problems you had with the last version of Castor you
tried? (I believe a new version is now available).
Reinhard pointed out a potential problem with Digester - we have to
write out the instance data when preferences are updated.
I wish I understood what
We finally got some thread dumps from our production server. It shows
something very different than what we were seeing in testing. First,
this happens under light load after running for days. To summarize,
many threads are waiting for the ResourceLimitingPool and several are
waiting for
On 22 Dec 2005, at 18:16, Ralph Goers wrote:
We finally got some thread dumps from our production server. It
shows something very different than what we were seeing in testing.
First, this happens under light load after running for days. To
summarize, many threads are waiting for the
Ralph Goers wrote:
We finally got some thread dumps from our production server. It shows
something very different than what we were seeing in testing. First,
this happens under light load after running for days. To summarize,
many threads are waiting for the ResourceLimitingPool and
We are still experiencing this hang. Does anyone have any idea what may be causing these threads to hang? It seems to hanging at the same spot, but admittedly I'm not sure what I'm looking at.
http-8080-Processor1 daemon prio=1 tid=0x082ca7d8 nid=0x574c runnable [2e6fe000..2e6ff87c]at
We tried to deploy an update to our product. Pretty much the only thing
we did to Cocoon was to replace Xalan with XSLTC which produces a
dramatic performance improvement. However, Cocoon is not consistently
hanging. I tried to attach the thread dumps but they are too big. They
also don't
Java version?
BTW, the src are here:
http://apache.secsup.org/dist/avalon/excalibur-pool/source/
Best Regards,
Antonio Gallardo.
Ralph Goers wrote:
We tried to deploy an update to our product. Pretty much the only
thing we did to Cocoon was to replace Xalan with XSLTC which produces
a
Ralph Goers wrote:
We tried to deploy an update to our product. Pretty much the only
thing we did to Cocoon was to replace Xalan with XSLTC which produces
a dramatic performance improvement. However, Cocoon is not
consistently hanging. I tried to attach the thread dumps but they are
too
It is running on AIX so it is IBM's JDK 1.4
Thanks, I found the code. I don't see a whole lot different but there is
clearly a problem in this code.
Ralph
Antonio Gallardo wrote:
Java version?
BTW, the src are here:
http://apache.secsup.org/dist/avalon/excalibur-pool/source/
Best
Antonio Gallardo wrote:
Ralph Goers wrote:
We tried to deploy an update to our product. Pretty much the only
thing we did to Cocoon was to replace Xalan with XSLTC which produces
a dramatic performance improvement. However, Cocoon is not
consistently hanging. I tried to attach the thread
38 matches
Mail list logo
