[
https://issues.apache.org/jira/browse/DERBY-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13252503#comment-13252503
]
Knut Anders Hatlen commented on DERBY-3106:
-------------------------------------------
I'm seeing something similar with Java SE for Embedded 7 on ARMv7/Linux. Not
sure if the cause is the same, but the symptoms look similar enough that it's
worth mentioning here.
The first few invocations of the goo repro show fairly normal numbers (similar
to the ones Kathey reported):
Time for first database boot=1941
Time with securityMechanism 8=305
Time with no securityMechnism=29
But after the first few invocations, it starts getting a lot slower:
Time for first database boot=1922
Time with securityMechanism 8=387912
Time with no securityMechnism=33
Time for first database boot=1917
Time with securityMechanism 8=525695
Time with no securityMechnism=41
It looks like it's the calls to java.security.SecureRandom.generateSeed() in
client.am.EncryptionManager and impl.drda.DecryptionManager that block for a
very long time. My guess is that the operating system's entropy source is
emptied and it takes time before it is back at the level of entropy needed for
it to be able to generate truly random bits.
This problem also makes NSSecurityMechanismTest take a very long time (hours)
on that platform.
Not sure if it's worth fixing, though. We don't recommend using
securityMechanism=8 anymore (because of DERBY-4468/CVE-2009-4269), and in
DERBY-5651 we're even discussing if we should remove that mechanism altogether.
> securityMechansim=8 causes slowdown on some JVMs?
> -------------------------------------------------
>
> Key: DERBY-3106
> URL: https://issues.apache.org/jira/browse/DERBY-3106
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.2.2.0
> Environment: IBM JVM 1.42, SLES 10 or SLES 10 SP1
> Reporter: mike bell
> Labels: derby_triage10_9
> Attachments: goo.java, goo.jsp
>
>
> 1. We have a Web App that uses Derby 10.2, doing client/server. It is a Java
> 1.4 app
> 2. We run it extensively on Windows (JDK 1.4,1.5/Tomcat 4.1/5.5), SLES 9,
> SLES 10, OES, and NetWare
> 3. Recently I added securityMechanism=8 to the JDBC URL to at least encrypt
> the password (it's all local right now, but it was a nicety). Extensive
> testing on Windows proved flawless.
> 4. Immediately after releasing to Beta testers, we heard the "UI" was slow. I
> traced this specifically to pages that accessed Derby Connections (or built
> them into a pool - there are depressing reasons why we don't do this all the
> time currently).
> 5. The issue only occurs on SLES 10/10 SP1. It occurred for about 80% of
> users, and was oddly intermittent. The slowdown did NOT occur on initial
> login, but after they added some entries (adding some fields to some tables
> effectively). From then on, the slowdown was rampant and survived restarts.
> Even the login (which queries some DBs) was very very slow
> 6. A test JSP page was created, which basically will be attached, but did
> nothing more than create a Connection, do a simple query, iterate the result
> set. Then do the same thing without the security Mechanism. Then spit out
> benchmark numbers.
> On my box (Windows), the numbers were typically a total of less than 10 ms
> for the queries. On machines exhibiting the issue, they were 80 SECONDS!
> As soon as the securityMechanism=8 was removed, the issue disappeared.
> Now, I'm not really sure I should blame Derby. My offhand gut guess is there
> is something wrong with the IBM JVM 1.42, doing the encrypted password and
> Derby took a long time to timeout and then backed down to cleartext..
> But I don't have a lot of time to test this one out. So I'm mostly posting
> FYI.
> (Additional: Connection logging was performed and not that interesting.
> Telnet to derby server was quick - it appears it is all in the client
> negotiating the connection that the slow down occurs).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
