On 5 October 2010 16:33, Simon Brown st...@cam.ac.uk wrote:
Which nobody has requested, making this a massive red herring. I fail
to see how cutting back on unnecessary and redundant database access
constitutes overhead to cover up the problems of larger
repositories.
One person's
On 6 Oct 2010, at 15:15, Graham Triggs wrote:
[snip]
This is exactly the kind of pointless pontification that we got last time.
Any point that is raised is deflected or ignored, and you even manage to
contradict yourself between paragraphs. What's it to be, should patches benefit
ALL
All,
I would really appreciate it if we could stop the negativity in this
discussion thread. I'm sorry to have to post a message of this sort
publicly, but I feel I'm unfortunately being forced to do so.
Insults and negativity on a public listserv do not help anyone. I also
personally take
On 4 Oct 2010, at 15:00, Graham Triggs wrote:
On 29 September 2010 14:17, Tom De Mulder td...@cam.ac.uk wrote:
I know you like to talk down the problem, but that really isn't
helping.
This isn't about talking down the problem - it's about finding where
the real problems are and not
Hi Simon All,
On 10/5/2010 10:33 AM, Simon Brown wrote:
On 4 Oct 2010, at 15:00, Graham Triggs wrote:
On 29 September 2010 14:17, Tom De Muldertd...@cam.ac.uk wrote:
I know you like to talk down the problem, but that really isn't
helping.
This isn't about talking down the problem - it's
On 29 September 2010 14:17, Tom De Mulder td...@cam.ac.uk wrote:
I know you like to talk down the problem, but that really isn't helping.
This isn't about talking down the problem - it's about finding where the
real problems are and not just patching the immediate concerns. And
considering the
useful to others:
http://wiki.apache.org/tomcat/OutOfMemory
--Hardy
-Original Message-
From: Mark H. Wood [mailto:mw...@iupui.edu]
Sent: Wednesday, September 29, 2010 12:08 PM
To: dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] tomcat reporting memory leak?
I'd like
On 24 Sep 2010, at 21:17, bill.ander...@library.gatech.edu wrote:
We've been experiencing problems similar to some reported on this thread
since our
upgrade to 1.6 several months ago. We're still using the jspui, and we've
wondered
(among other things) if some of these problems might be
On 29 Sep 2010, at 11:38, Hilton Gibson wrote:
We started with a VM which had 2GB memory.
Then added 2GB to the VM, no luck.
Then luckily we had funds to buy a server.
So now we have 12GB RAM and 12CPU's. No crashes so far.
Using the XMLUI.
Does DSpace really need this and what happens when
On 29 Sep 2010, at 11:47, Mark Ehle wrote:
Why was tomcat chosen as a platform for DSpace?
It wasn't. You can use any Servlet engine. We used JBoss for a while but went
back to Tomcat because it fitted into our infrastructure better.
I believe DSpace was written in Java because Rob Tansley
On 29 September 2010 11:38, Hilton Gibson hilton.gib...@gmail.com wrote:
Using the XMLUI.
Does DSpace really need this and what happens when we go to one million
items ??
Does DSpace really need that? No. As I have said, I'm running 30 separate
repositories - using JSPUI (circa 1.4.2 / 1.5
On 29 September 2010 11:48, Tom De Mulder td...@cam.ac.uk wrote:
A lot of the back-end code of DSpace, the very core of it, is inherently
inefficient
I don't entirely disagree with that statement - there are some things that
can definitely be improved, particularly where you have to deal with
That begs the question as do you think something else should be chosen /
recommended?
There really isn't anything preventing you using Jetty, etc. but Tomcat is
actually a pretty solid server that does a lot of things quite well - and
particularly in recent versions in being defensive against bad
We're comfortably running *three* production DSpace instances in a
single Tomcat 6 with these limits:
JAVA_OPTS=-Xmx1024M -Xms768M
JAVA_OPTS=$JAVA_OPTS -XX:MaxPermSize=128M
JAVA_OPTS=$JAVA_OPTS -XX:PermSize=32M
That's on a box with 3GB of physical memory. One DSpace instance is
1.6, and the
On Wed, Sep 29, 2010 at 11:48:02AM +0100, Tom De Mulder wrote:
A lot of the back-end code of DSpace, the very core of it, is inherently
inefficient. Several tasks are executed more than once, and entire objects
are created when only one attribute is needed, etc. (I'd be more specific,
but
On 29 Sep 2010, at 13:03, Graham Triggs wrote:
Some of those repositories have 1000s of items, and get quite decent levels
of access.
Thousands?
I don't even want to have this discussion until you're talking hundreds of
thousands, and how many hits per second. I know you like to talk down
Hi all,
Interesting thread so far and keep up the good discussion.
I think it'd be helpful to us all if we could all share more information
about our DSpace setups (similar to Mark Wood's tip on his local
JAVA_OPTS settings). The more we know about your
DSpace/Java/Tomcat/Postgres (or
Thanks - I was just curious.
On Wed, Sep 29, 2010 at 6:53 AM, Tom De Mulder td...@cam.ac.uk wrote:
On 29 Sep 2010, at 11:47, Mark Ehle wrote:
Why was tomcat chosen as a platform for DSpace?
It wasn't. You can use any Servlet engine. We used JBoss for a while but went
back to Tomcat because
Quick followup, in case it isn't clear (as I was asked about this
off-list). The preference would be to share your DSpace
setup/configuration information directly on this listserv (or you can
post up on the wiki if you prefer). That way we can get more eyes on
it, and hopefully come up with
- Tim Donohue tdono...@duraspace.org wrote:
| Quick followup, in case it isn't clear (as I was asked about this
| off-list). The preference would be to share your DSpace
| setup/configuration information directly on this listserv
Let me kick things off, then (questions truncated a bit
I'd like to point out that the discussion is broadening considerably:
a system can be slow for many reasons, not just memory starvation.
Step 1: what resource(s) are you short of? Something like LambdaProbe
can peek inside Tomcat and show you how much of each of the various
memory pools is being
On 22 Sep 2010, at 20:22, Sands Alden Fish wrote:
(2) We currently don't have a centralized server with enough test data
to run many of these memory or scalability tests on our own. I think
this is something we could look into improving upon (especially if
anyone has test data to donate to
Hello Graham,
this is an important point. Apart from the issues mentioned, a simpler
architecture will help DSpace adopt to new requirements/technology
changes and stay flexible and easy to manage.
Furthermore too much clever tricks under the hood will raise the risk
that with change in the
-Original Message-
From: Pottinger, Hardy J. [mailto:pottinge...@umsystem.edu]
Sent: 21 September 2010 18:27
To: Graham Triggs; Tom De Mulder
Cc: dspace-tech@lists.sourceforge.net; Damian Marinaccio
Subject: Re: [Dspace-tech] tomcat reporting memory leak?
Hi, Graham, for what it's worth
I am very happy to see that this issue seems finally to be taken seriously.
However, I find myself getting a bit frustrated that it was never taken
seriously when I raised it in the past.
I think the DSpace source code carries with it a lot of historical baggage, and
it could do with being
Hi all,
I'm sorry if any of you have felt that this issue is not being taken
seriously in the past. The reality of the situation is that we (the
DSpace Developers/Committers) currently depend on feedback/testing from
larger DSpace instances around these sorts of scalability and memory
On Sep 22, 2010, at 12:10 PM, Tim Donohue wrote:
(2) We currently don't have a centralized server with enough test data
to run many of these memory or scalability tests on our own. I think
this is something we could look into improving upon (especially if
anyone has test data to donate to the
A random collection of thoughts which occurred while reading this
thread:
o Performance, scalability, complexity, and ruggedness are sometimes
competing influences on the design of code. We can improve in all
of these aspects. Sometimes all of those influences will conspire
to suggest
And one point I forgot:
o Volunteers dont' have to write code. If you aren't quite ready to
step into the DSpace tarball with torch and machete, but can read
Java, you can review the code and make suggestions. Many eyes
make all bugs shallow.
Bug reports (including performance
On Wed, Sep 22, 2010 at 4:51 PM, Mark H. Wood mw...@iupui.edu wrote:
o Best practice and commonest practice w.r.t. deployment of libraries
seem to be antithetical in the Java universe. I was quite pleased
to discover that I'm not the only one who thinks that Tomcat's /lib
directory is
On 20 September 2010 15:59, Tom De Mulder td...@cam.ac.uk wrote:
On Mon, 20 Sep 2010, Damian Marinaccio wrote:
I'm seeing the following log messages in catalina.out:
[...]
SEVERE: The web application [] appears to have started a thread named
[FinalizableReferenceQueue] but has failed to
To: Tom De Mulder
Cc: dspace-tech@lists.sourceforge.net; Damian Marinaccio
Subject: Re: [Dspace-tech] tomcat reporting memory leak?
On 20 September 2010 15:59, Tom De Mulder td...@cam.ac.uk wrote:
On Mon, 20 Sep 2010, Damian Marinaccio wrote:
I'm seeing the following log
I'm seeing the following log messages in catalina.out:
INFO: Deploying web application directory ROOT
Sep 19, 2010 8:01:33 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [] appears to have started a thread named
[FinalizableReferenceQueue] but
On Mon, 20 Sep 2010, Damian Marinaccio wrote:
I'm seeing the following log messages in catalina.out:
[...]
SEVERE: The web application [] appears to have started a thread named
[FinalizableReferenceQueue] but has failed to stop it.
This is very likely to create a memory leak.
There are
34 matches
Mail list logo
