On 01/12/2012 02:18 PM, Michael Meeks wrote:
On Thu, 2012-01-12 at 10:44 +0100, Stephan Bergmann wrote:
One drawback of using the thread-affine apartment is that all code
related to the JDBC driver is effectively serialized, removing any
potential performance advantage from accessing the driver
Surely now that it's confined to a single thread, it can just call
AttachThread() once at startup, and never need to call DetachThread() ?
-- Noel Grandin
On 2012-01-13 10:54, Stephan Bergmann wrote:
On 01/12/2012 02:18 PM, Michael Meeks wrote:
On Thu, 2012-01-12 at 10:44 +0100, Stephan
On 01/13/2012 09:59 AM, Noel Grandin wrote:
Surely now that it's confined to a single thread, it can just call
AttachThread() once at startup, and never need to call DetachThread() ?
Yes, one could improve it further based on the fact that it is confied
now (it also internally uses some
Yeah, but given that such a re-design is probably a long way off, and
that other drivers seem are confined to a single-thread, and seem to
have acceptable performance, perhaps we should just live with this
limitation, and optimise the easy-case?
On 2012-01-13 11:18, Stephan Bergmann wrote:
On 01/13/2012 10:36 AM, Noel Grandin wrote:
Yeah, but given that such a re-design is probably a long way off, and
that other drivers seem are confined to a single-thread, and seem to
have acceptable performance, perhaps we should just live with this
limitation, and optimise the easy-case?
But anyway, I'll keep this in the back of my head, and if QA does not
find any horrible problems with confining the JDBC driver in LO 3.5,
we can probably simplify the code on master. (Would you be interested?)
Got something else on my plate right now (moving notes out of ScCell),
but once
On 10/20/2011 09:08 AM, Stephan Bergmann wrote:
On 10/19/2011 07:17 PM, Andrew Haley wrote:
On 10/19/2011 05:57 PM, Michael Meeks wrote:
On Wed, 2011-10-19 at 17:32 +0200, Stephan Bergmann wrote:
What the LibO hsqldb code does a lot is call JNI's
Attach/DetachCurrentThread. Googling around,
On Thu, 2012-01-12 at 10:44 +0100, Stephan Bergmann wrote:
I think the best solution here would be to change the LibO hsqldb code,
to call Attach/DetachCurrentThread rarely rather than frequently, but
according to Ocke Janssen (who used to maintain that code) that was no
easy option.
On 10/19/2011 07:17 PM, Andrew Haley wrote:
On 10/19/2011 05:57 PM, Michael Meeks wrote:
On Wed, 2011-10-19 at 17:32 +0200, Stephan Bergmann wrote:
What the LibO hsqldb code does a lot is call JNI's
Attach/DetachCurrentThread. Googling around,
John, which version of java are you running?
Running
java -version
at the command line should tell you.
On 19 October 2011 19:17:02, Andrew Haley wrote:
On 10/19/2011 05:57 PM, Michael Meeks wrote:
On Wed, 2011-10-19 at 17:32 +0200, Stephan Bergmann wrote:
What the LibO hsqldb code does
Hello, dear developers,
On Thu, 2011-10-20 at 09:08 +0200, Stephan Bergmann wrote:
This might still hit us, if the LibO hsqldb code runs in the main thread
(which I'm pretty sure it does). That code calls
Attach/DetachCurrentThread frequently.
I think the best solution here would be to
On 20/10/11 08:12, Noel Grandin wrote:
John, which version of java are you running?
java version 1.7.0_147-icedtea
OpenJDK Runtime Environment (IcedTea7 2.0pre) (7~b147-2.0~pre6-2)
OpenJDK Client VM (build 21.0-b17, mixed mode, sharing)
From Debian testing.
On 10/20/2011 08:08 AM, Stephan Bergmann wrote:
On 10/19/2011 07:17 PM, Andrew Haley wrote:
On 10/19/2011 05:57 PM, Michael Meeks wrote:
On Wed, 2011-10-19 at 17:32 +0200, Stephan Bergmann wrote:
What the LibO hsqldb code does a lot is call JNI's
Attach/DetachCurrentThread. Googling around,
Hi Kendy
OK, good; so what you can do to help to analyze it more, is to look at
the strace output, and see if the reason for hang in
java.net.PlainSocketimpl.socketAccept is actually something that can be
worked around.
I have got an strace, it is at
On 10/19/2011 04:10 PM, John Talbut wrote:
What I notice is that there is a set of lines starting with
read(72
and ending with
close(72)
(the number is not always 72) that is repeated more or less identically
some 12,000 times in the 7 minute run. Since each set appears to take
around .02
On Wed, 2011-10-19 at 16:34 +0200, Stephan Bergmann wrote:
(the number is not always 72) that is repeated more or less identically
some 12,000 times in the 7 minute run. Since each set appears to take
around .02 seconds that alone would account for some 4 minutes of the run.
7321 times
Hi
Is there a way of getting a stacktrace from this tool, so we could see where
the /proc/self/map access is coming from?
Regards, Noel.
Michael Meeks wrote:
On Wed, 2011-10-19 at 16:34 +0200, Stephan Bergmann wrote:
(the number is not always 72) that is repeated more or less identically
On 10/19/2011 05:07 PM, Michael Meeks wrote:
On Wed, 2011-10-19 at 16:34 +0200, Stephan Bergmann wrote:
(the number is not always 72) that is repeated more or less identically
some 12,000 times in the 7 minute run. Since each set appears to take
around .02 seconds that alone would account for
On 19/10/11 16:32, Stephan Bergmann wrote:
On 10/19/2011 05:07 PM, Michael Meeks wrote:
On Wed, 2011-10-19 at 16:34 +0200, Stephan Bergmann wrote:
(the number is not always 72) that is repeated more or less identically
some 12,000 times in the 7 minute run. Since each set appears to take
On Wed, 2011-10-19 at 17:32 +0200, Stephan Bergmann wrote:
What the LibO hsqldb code does a lot is call JNI's
Attach/DetachCurrentThread. Googling around,
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 Stack
guard pages should be removed when thread is detached suggests that
On 10/19/2011 05:57 PM, Michael Meeks wrote:
On Wed, 2011-10-19 at 17:32 +0200, Stephan Bergmann wrote:
What the LibO hsqldb code does a lot is call JNI's
Attach/DetachCurrentThread. Googling around,
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 Stack
guard pages should be
Hi John,
On 2011-10-18 at 06:18 +0100, jowyta wrote:
Also, I see Ocke Janssen wrote in
https://issues.apache.org/ooo/show_bug.cgi?id=117203
[...]
I have done some searching and the bug appears to be filed as:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7024514
So provided the
On Tue, 2011-10-18 at 09:03 +0200, Jan Holesovsky wrote:
the strace output, and see if the reason for hang in
java.net.PlainSocketimpl.socketAccept is actually something that can be
worked around.
Of course, it is possible that Java7 adds some security features around
accepting
I wrote on libreoffice-users:
how to we drill down deeper to isolate this problem?
On 17/10/11 10:54, Alexander Thurgood wrote:
You would probably need someone with a debug build of LibO master
branch who can find some way to analyse the Java stack using gdb or
valgrind or some other
Hi John,
On 2011-10-16 at 14:17 +0100, jowyta wrote:
I do not know whether this helps, but I have observed the when moving
from the first to the last record in a table soffice.bin takes 100% CPU
while it is happening.
Also, I see Ocke Janssen wrote in
I do not know whether this helps, but I have observed the when moving
from the first to the last record in a table soffice.bin takes 100% CPU
while it is happening.
Also, I see Ocke Janssen wrote in
https://issues.apache.org/ooo/show_bug.cgi?id=117203
I did some performance tests and the
26 matches
Mail list logo