[jira] [Commented] (DERBY-7161) Document the need for client-side applications to vet user-supplied connection directives
[ https://issues.apache.org/jira/browse/DERBY-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841009#comment-17841009 ] Bryan Pendleton commented on DERBY-7161: Thanks Rick. The doc changes look good to me. > Document the need for client-side applications to vet user-supplied > connection directives > - > > Key: DERBY-7161 > URL: https://issues.apache.org/jira/browse/DERBY-7161 > Project: Derby > Issue Type: Task > Components: Documentation, Network Client >Affects Versions: 10.18.0.0 >Reporter: Richard N. Hillegas >Priority: Major > Attachments: derby-7161-01-aa-traceFileAttributes.diff, > derby-7161-01-aa-traceFileAttributes.tar > > > Somewhere, we should document the fact that client-side applications should > not use user-supplied URLs or Properties objects to connect to remote > databases. Those URLs and Properties objects may contain instructions for > tracing network traffic. If the client-side application runs from a more > privileged account than the user, then this could let the user pollute parts > of the directory system to which the user does not normally have > write-access. Client-side applications should vet all user-supplied > directives before establishing connections. > A related MySQL problem is described by [1]. > [1] > https://github.com/apache/security-site/compare/main...raboof:security-site:mysql -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7161) Document the need for client-side applications to vet user-supplied connection directives
[ https://issues.apache.org/jira/browse/DERBY-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834550#comment-17834550 ] Bryan Pendleton commented on DERBY-7161: Yes, those seem good. Perhaps also put links to the information in these places? * [https://db.apache.org/derby/docs/10.17/ref/rrefattrib24612.html] * https://db.apache.org/derby/docs/10.17/devguide/cdevdvlp51654.html > Document the need for client-side applications to vet user-supplied > connection directives > - > > Key: DERBY-7161 > URL: https://issues.apache.org/jira/browse/DERBY-7161 > Project: Derby > Issue Type: Task > Components: Documentation, Network Client >Affects Versions: 10.18.0.0 >Reporter: Richard N. Hillegas >Priority: Major > > Somewhere, we should document the fact that client-side applications should > not use user-supplied URLs or Properties objects to connect to remote > databases. Those URLs and Properties objects may contain instructions for > tracing network traffic. If the client-side application runs from a more > privileged account than the user, then this could let the user pollute parts > of the directory system to which the user does not normally have > write-access. Client-side applications should vet all user-supplied > directives before establishing connections. > A related MySQL problem is described by [1]. > [1] > https://github.com/apache/security-site/compare/main...raboof:security-site:mysql -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7161) Document the need for client-side applications to vet user-supplied connection directives
[ https://issues.apache.org/jira/browse/DERBY-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834537#comment-17834537 ] Bryan Pendleton commented on DERBY-7161: Hi Rick, have you thought much about where we might best document this? My thought is that we might put such documentation in multiple places to give it the best chance of being seen. > Document the need for client-side applications to vet user-supplied > connection directives > - > > Key: DERBY-7161 > URL: https://issues.apache.org/jira/browse/DERBY-7161 > Project: Derby > Issue Type: Task > Components: Documentation, Network Client >Affects Versions: 10.18.0.0 >Reporter: Richard N. Hillegas >Priority: Major > > Somewhere, we should document the fact that client-side applications should > not use user-supplied URLs or Properties objects to connect to remote > databases. Those URLs and Properties objects may contain instructions for > tracing network traffic. If the client-side application runs from a more > privileged account than the user, then this could let the user pollute parts > of the directory system to which the user does not normally have > write-access. Client-side applications should vet all user-supplied > directives before establishing connections. > A related MySQL problem is described by [1]. > [1] > https://github.com/apache/security-site/compare/main...raboof:security-site:mysql -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7157) Tasks for releasing Derby 10.17.1
[ https://issues.apache.org/jira/browse/DERBY-7157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779876#comment-17779876 ] Bryan Pendleton commented on DERBY-7157: I've struggled with this same question myself. It wasn't obvious to me that 10.17 was JDK 21+., either. The way we've dealt with this in the past was to document things on [https://db.apache.org/derby/derby_downloads.html] , but that is getting increasingly clunky. For example, the top of the page where it says "For Java 8 and higher", "For Java 9 and higher", etc. could easily make you think that the various releases have no known upper bound, but I don't think that's true. Documenting the valid releases in multiple places will help with discoverability, but it might also be time to re-arrange that downloads page in a way which makes it more clear that some of these decades-old releases are in a different category. Perhaps a paragraph at the top covering the major boundaries (when Modules were released, when Security Manager was dropped, etc.)? > Tasks for releasing Derby 10.17.1 > - > > Key: DERBY-7157 > URL: https://issues.apache.org/jira/browse/DERBY-7157 > Project: Derby > Issue Type: Task > Components: Build tools >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7157-01-aa-draftReleaseNotes.diff, > derby-7157-02-aa-initialSTATUSupdate.diff, > derby-7157-03-aa-updateDocConstants.diff, > derby-7157-04-aa-updateReleaseProperties.diff, > derby-7157-05-aa-bumpReleaseNumberOnTrunk.diff, > derby-7157-06-aa-newDataDictionaryVersion.diff, > derby-7157-07-aa-recordBranchesOnWebsite.diff, > derby-7157-08-aa-updateAntVersion.diff > > > Placeholder for activity related to producing a 10.17.1 release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7157) Tasks for releasing Derby 10.17.1
[ https://issues.apache.org/jira/browse/DERBY-7157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778416#comment-17778416 ] Bryan Pendleton commented on DERBY-7157: Hi Rick, I noticed that [https://db.apache.org/derby/dev/derby_source.html] is a bit out of date, it seems that we never updated it when we made the 10.16 source branch. Perhaps we are missing a step in one of our checklists? > Tasks for releasing Derby 10.17.1 > - > > Key: DERBY-7157 > URL: https://issues.apache.org/jira/browse/DERBY-7157 > Project: Derby > Issue Type: Task > Components: Build tools >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7157-01-aa-draftReleaseNotes.diff, > derby-7157-02-aa-initialSTATUSupdate.diff, > derby-7157-03-aa-updateDocConstants.diff, > derby-7157-04-aa-updateReleaseProperties.diff, > derby-7157-05-aa-bumpReleaseNumberOnTrunk.diff, > derby-7157-06-aa-newDataDictionaryVersion.diff > > > Placeholder for activity related to producing a 10.17.1 release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7152) Derby DOAP file has error
[
https://issues.apache.org/jira/browse/DERBY-7152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740237#comment-17740237
]
Bryan Pendleton commented on DERBY-7152:
Rick, I think you can close this work item now?
> Derby DOAP file has error
> -
>
> Key: DERBY-7152
> URL: https://issues.apache.org/jira/browse/DERBY-7152
> Project: Derby
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 10.16.1.1
>Reporter: Claude Warren
>Priority: Minor
> Attachments: derby-7152-01-aa-missingElementInDOAP.diff
>
>
> The DOAP file [1] as listed in [2] has the error:
> [line: 35, col: 16] \{E201} Multiple children of property element
> [1] http://svn.apache.org/repos/asf/db/derby/site/trunk/doap_Derby.rdf
> [2]
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[
https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654124#comment-17654124
]
Bryan Pendleton commented on DERBY-7149:
{quote}I intend to modify CacheManagerMBeanTest so that it skips the failing
tests when the default, restrictive filter is in place. I think it would also
be a good idea to modify our MBean documentation to describe this problem and
its workaround.
{quote}
That seems like a great approach. Thanks for taking care of this Rick!
> Make it possible to build and test Derby cleanly with JDK 20
>
>
> Key: DERBY-7149
> URL: https://issues.apache.org/jira/browse/DERBY-7149
> Project: Derby
> Issue Type: Task
> Components: Build tools
>Affects Versions: 10.17.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7149-01-aa-deprecateURLconstructor.diff,
> derby-7149-01-ac-deprecateURLconstructor.diff,
> derby-7149-02-aa-disableJMXtest.diff
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642921#comment-17642921 ] Bryan Pendleton commented on DERBY-7147: Perhaps we can proceed with what we have now, and in a separate Jira we could log the enhancement to have our documentation provide thorough details about how to integrate Derby with LDAP using ldaps: protocol. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar, > derby-7147-03-ab-updateLDAPinstructions.diff, > derby-7147-03-ab-updateLDAPinstructions.tar > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642879#comment-17642879 ] Bryan Pendleton commented on DERBY-7147: Actually, I think I did my ldaps test incorrectly. Configuring ldaps works, but it is a lot more complex (see [https://directory.apache.org/apacheds/basic-ug/3.3-enabling-ssl.html#other-clients-java-programs-using-jndi)] for all the details. Derby has to have the right keystore to trust the self-signed certificate supplied by ApacheDS. Do you think this is important for us to document? If so, we'll probably need a fair bit more documentation to work out the specifics. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar, > derby-7147-03-ab-updateLDAPinstructions.diff, > derby-7147-03-ab-updateLDAPinstructions.tar > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642851#comment-17642851 ] Bryan Pendleton commented on DERBY-7147: Those documentation updates seem like good improvements to me. For csecldapbooting.dita, you could possibly change 'Boot ApacheDS via the following command' to something like 'Boot ApacheDS. On Linux, for example, run the following command' since I believe the precise instructions vary by platform. The 'ldaps' worked fine for me in my toy example, and I have no reason to believe it wouldn't work else. I unfortunately have no input on your much harder second question. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17640706#comment-17640706 ] Bryan Pendleton commented on DERBY-7147: Fine with me to make just a 10.16.2 release. What in particular did you have in mind for documentation changes? Just a release note, or do you think that the actual documentation is inaccurate w.r.t. these topics? > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[
https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17639540#comment-17639540
]
Bryan Pendleton commented on DERBY-7147:
Rick, a possible difference between your 'ant junit-single' and mine is that I
was running with *classes* (I did 'ant all', but not 'ant buildJars'), whereas
I think you were running with {*}jars{*}.
> LDAP injection vulnerability in LDAPAuthenticationImpl
> --
>
> Key: DERBY-7147
> URL: https://issues.apache.org/jira/browse/DERBY-7147
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.16.1.1
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7147-01-aa-reformatForReadability.diff,
> derby-7147-02-aa-escapeLDAPsearchFilter.diff,
> derby-7147-02-ab-escapeLDAPsearchFilter.diff
>
>
> An LDAP injection vulnerability has been identified in
> LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been
> provided, but there is a possibility that an intruder could bypass
> authentication checks in Derby-powered applications which rely on external
> LDAP servers.
> For more information on LDAP injection, see
> https://www.synopsys.com/glossary/what-is-ldap-injection.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17639539#comment-17639539 ] Bryan Pendleton commented on DERBY-7147: Anyway, if it wasn't clear from the above, +1 from me to move ahead with your second 'ab' patch, it is working fine for my very limited testing. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[
https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17639538#comment-17639538
]
Bryan Pendleton commented on DERBY-7147:
Yay! I've successfully run LDAPAuthenticationTest with your second patch
applied.
A tiny nit: your second patch includes a whitespace-only extra blank line, not
sure if this was intentional or not:
{code:java}
@@ -418,6 +468,7 @@
String searchFilter =
this.leftSearchFilter + uid + this.rightSearchFilter;
+
NamingEnumeration results =
ctx.search(searchBaseDN, searchFilter, ctls);
{code}
Here are some raw notes. Perhaps someday they will be useful as memory-joggers,
should I need to do this again:
# I used Ubuntu Linux 20.04 and OpenJDK 19.0.1
# I installed ApacheDS and ApacheDirectoryStudio from
[https://directory.apache.org,|https://directory.apache.org%2C/] just following
the directions.
# I started up ApacheDS by sudo /etc/init.d/apacheds-2.0.0.AM26-default start
# Using ApacheDirectoryStudio, I followed these instructions to generate a
sample database of users:
[https://directory.apache.org/apacheds/basic-ug/1.5-sample-configuration.html]
# I used ApacheDirectoryStudio to change the password for sample user
Cornelius Buckley to 'secret'
# I additionally created user 'kathy/kathyS' using ApacheDirectoryStudio to
add a new entry to the ou=people,o=sevenseas database using one of the existing
entries as a template.
# I applied your ("ab") patch and did 'ant all'
# I verified that LDAP authentication was working by following
[https://db.apache.org/derby/docs/10.16/security/cseccsecure863446.html] and
using the following properties for my test database:
##
{code:java}
derby.authentication.server=ldap://127.0.0.1:10389
derby.authentication.provider=LDAP
derby.authentication.ldap.searchBase=o=sevenseas {code}
##
{code:java}
java -cp
/home/bpendleton/derby/trunk/tools/java/junit.jar:/home/bpendleton/derby/trunk/classes/engine:/home/bpendleton/derby/trunk/classes/shared:/home/bpendleton/derby/trunk/classes/tools:/home/bpendleton/derby/trunk/classes/testing:/home/bpendleton/derby/trunk/classes/server:/home/bpendleton/derby/trunk/classes/drda:/home/bpendleton/derby/trunk/classes/client
org.apache.derby.tools.ij
ij version 10.17
ij> connect 'jdbc:derby:test2;create=true;user=cbuckley;password=secret';
ij> quit; {code}
# Lastly, I verified that LDAPAuthenticationTest passed by doing:
##
{code:java}
java -cp
/home/bpendleton/derby/trunk/tools/java/junit.jar:/home/bpendleton/derby/trunk/classes/engine:/home/bpendleton/derby/trunk/classes/shared:/home/bpendleton/derby/trunk/classes/tools:/home/bpendleton/derby/trunk/classes/testing:/home/bpendleton/derby/trunk/classes/server:/home/bpendleton/derby/trunk/classes/drda:/home/bpendleton/derby/trunk/classes/client
-DderbyTesting.ldapUser=cbuckley -DderbyTesting.ldapPassword=secret
-DderbyTesting.ldapPort=10389 -DderbyTesting.dnString=sevenseas
-DderbyTesting.ldapServer=ldap://127.0.0.1:10389 junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.jdbcapi.LDAPAuthenticationTest
{code}
## (Note that the help text for 'derbyTesting.ldapServer' in
LDAPAuthenticationTest doesn't make it very obvious that you're supposed to set
it to the value that will be used for the
'[derby.authentication.server|https://db.apache.org/derby/docs/10.16/ref/rrefproper25581.html]'
property; that took me a while to figure out)
Lastly, two final notes that I'm not sure if they are important or not:
# LDAPAuthenticationTest.java requires that I set
-DderbyTesting.ldapPort=10389, but as far as I can see it doesn't actually
*use* that setting anywhere. It sets the 'ldapPort' variable, but I can't find
anything that uses that variable. Note from above that when I run the test, I
specify the port number in the 'ldapServer' URL.
# LDAPAuthenticationTest.java includes the following line. I can't figure out
if this line interacts with your patch in any interesting ways or not. Is your
patch in play whether or not this line is used? I stared at
[https://db.apache.org/derby/docs/10.16/ref/rrefproper37341.html] for a while
but it did not make me any smarter. I tried running LDAPAuthenticationTest both
with this line in place, and with it commented out, and the test passed either
way, so probably I guess I have no idea whether any of this matters or not,
but since your patch touches the code that has the word 'searchFilter' in it I
figured I'd bring this up.
##
{code:java}
setDatabaseProperty("derby.authentication.ldap.searchFilter","(&(objectClass=inetOrgPerson)(uid=%USERNAME%))",
conn); {code}
> LDAP injection vulnerability in LDAPAuthenticationImpl
> --
>
> Key: DERBY-7147
> URL: https://issues.apache.org/jira/browse/DERBY-7147
> Project:
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[
https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17639509#comment-17639509
]
Bryan Pendleton commented on DERBY-7147:
Hi Rick, sorry for these stupid questions. Do you think that 'ant junit-single'
still works for the current Derby trunk? Specifically, does [the command shown
in the
wiki|https://cwiki.apache.org/confluence/display/DERBY/DerbyJUnitTesting#DerbyJUnitTesting-RunningasingleJUnittestsuiteusingantinacodeline]
work for you?
I find that I can successfully run individual tests using the JUnit TestRunner
classes directly, [as described in the wiki
here|https://cwiki.apache.org/confluence/display/DERBY/DerbyJUnitTesting#DerbyJUnitTesting-RunningtestsusingJunitdirectly],
but the 'ant' approach does not work for me, I get class loading failures with
the autoloaded driver.
{code:java}
ERROR XBM02: Startup failed due to missing functionality for
org.apache.derby.iapi.store.raw.data.DataFactory. Please ensure your classpath
includes the correct Derby software {code}
> LDAP injection vulnerability in LDAPAuthenticationImpl
> --
>
> Key: DERBY-7147
> URL: https://issues.apache.org/jira/browse/DERBY-7147
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.16.1.1
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7147-01-aa-reformatForReadability.diff,
> derby-7147-02-aa-escapeLDAPsearchFilter.diff,
> derby-7147-02-ab-escapeLDAPsearchFilter.diff
>
>
> An LDAP injection vulnerability has been identified in
> LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been
> provided, but there is a possibility that an intruder could bypass
> authentication checks in Derby-powered applications which rely on external
> LDAP servers.
> For more information on LDAP injection, see
> https://www.synopsys.com/glossary/what-is-ldap-injection.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[
https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637772#comment-17637772
]
Bryan Pendleton commented on DERBY-7147:
Rick, my fairly casual read of [RFC
2254|https://www.rfc-editor.org/rfc/rfc2254] says that we're only supposed to
escape the *value* data in the search filter, not the entire search filter.
That is, in the following, I think we should only be escaping 'uid', not all of
'searchFilter'.
{code:java}
@@ -418,6 +465,10 @@ String searchFilter =
this.leftSearchFilter + uid + this.rightSearchFilter;
+
+ // Escape the search filter as a defense against LDAP injection. See
DERBY-7147.
+ searchFilter = doFilterEscaping(searchFilter);
+{code}
> LDAP injection vulnerability in LDAPAuthenticationImpl
> --
>
> Key: DERBY-7147
> URL: https://issues.apache.org/jira/browse/DERBY-7147
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.16.1.1
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7147-01-aa-reformatForReadability.diff,
> derby-7147-02-aa-escapeLDAPsearchFilter.diff
>
>
> An LDAP injection vulnerability has been identified in
> LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been
> provided, but there is a possibility that an intruder could bypass
> authentication checks in Derby-powered applications which rely on external
> LDAP servers.
> For more information on LDAP injection, see
> https://www.synopsys.com/glossary/what-is-ldap-injection.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637475#comment-17637475 ] Bryan Pendleton commented on DERBY-7147: Uh-oh! Reverting your patch makes the problem go away. I eyeballed your change but nothing jumped out at me. But we're making progress! Since I can reproduce a problem, I'll find some time over the long weekend to try adding some debug information and see what I can learn. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637473#comment-17637473 ] Bryan Pendleton commented on DERBY-7147: That's a good point! I do have your patch applied. I'll try reverting the patch and see if anything changes. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637439#comment-17637439 ] Bryan Pendleton commented on DERBY-7147: My attempts to connect to the ApacheDS server using the built-in Apache Directory Studio tool are successful, so the LDAP server itself seems to be working; I just don't understand how to configure the derby.properties for LDAP Authentication to match what the ApacheDS server wants, and the error message I get back from it isn't giving any hints about what's wrong (this is a common problem with security-related tools, their error messages are often opaque, because giving too much information is often felt to be a security risk in itself). Sigh. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[
https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637437#comment-17637437
]
Bryan Pendleton commented on DERBY-7147:
I've been trying to verify that Derby can use the ApacheDS LDAP server but
haven't had much success yet.
I'm trying to follow
[https://db.apache.org/derby/docs/10.16/security/cseccsecure863446.html] but
all my attempts to connect are failing with
{code:java}
ERROR 08004: Connection refused :
javax.naming.directory.InvalidSearchFilterException: invalid attribute
description {code}
> LDAP injection vulnerability in LDAPAuthenticationImpl
> --
>
> Key: DERBY-7147
> URL: https://issues.apache.org/jira/browse/DERBY-7147
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.16.1.1
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7147-01-aa-reformatForReadability.diff,
> derby-7147-02-aa-escapeLDAPsearchFilter.diff
>
>
> An LDAP injection vulnerability has been identified in
> LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been
> provided, but there is a possibility that an intruder could bypass
> authentication checks in Derby-powered applications which rely on external
> LDAP servers.
> For more information on LDAP injection, see
> https://www.synopsys.com/glossary/what-is-ldap-injection.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[
https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636981#comment-17636981
]
Bryan Pendleton commented on DERBY-7147:
Here's a tiny little bit of instructions on how to run LDAPAuthenticationTest:
https://issues.apache.org/jira/browse/DERBY-3659?focusedCommentId=12600313=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12600313
There it says:
{code:java}
When the properties are set, and the extra user (kathy/kathyS) is specified,
the test will run. {code}
It seems like I need to:
# Figure out how to set the 5 magic properties that need to be set when
running the test
# Figure out what data I have to load into my LDAP server
The comment in the test source code says:
{code:java}
// This test assumes at least one valid user (to be passed in) and one
// additional user (kathy / kathyS) to be setup in ou=People on the
// LDAPServer.
{code}
> LDAP injection vulnerability in LDAPAuthenticationImpl
> --
>
> Key: DERBY-7147
> URL: https://issues.apache.org/jira/browse/DERBY-7147
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.16.1.1
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7147-01-aa-reformatForReadability.diff,
> derby-7147-02-aa-escapeLDAPsearchFilter.diff
>
>
> An LDAP injection vulnerability has been identified in
> LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been
> provided, but there is a possibility that an intruder could bypass
> authentication checks in Derby-powered applications which rely on external
> LDAP servers.
> For more information on LDAP injection, see
> https://www.synopsys.com/glossary/what-is-ldap-injection.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636980#comment-17636980 ] Bryan Pendleton commented on DERBY-7147: Archive.org finds that ancient broken link: [https://web.archive.org/web/20080719183716/http://today.java.net/today/2007/03/22/secArticle.LDIF] Eyeballing it, I think it is just the "sevenseas" sample that comes with ApacheDS. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636344#comment-17636344 ] Bryan Pendleton commented on DERBY-7147: I can test on Linux, and possibly (if we really think necessary), on Windows. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636217#comment-17636217 ] Bryan Pendleton commented on DERBY-7147: That seems like it could be a useful step forward! I can at least help with some of the testing. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636172#comment-17636172 ] Bryan Pendleton commented on DERBY-7147: Can we adapt our LDAP sample instructions to the ApacheDS tutorial, e.g., use the LDIF file from here: https://directory.apache.org/apacheds/basic-ug/1.5-sample-configuration.html#the-sample-data-sailors-of-the-seven-seas > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7145) MERGE UPDATE failing: Restore of a serializable or SQLData object of class , attempted to read more data than was originally stored
[
https://issues.apache.org/jira/browse/DERBY-7145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17615945#comment-17615945
]
Bryan Pendleton commented on DERBY-7145:
> when the UPDATE count > 5
Makes me think of
https://issues.apache.org/jira/browse/DERBY-7144?focusedCommentId=17574762=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17574762
and its observation that the rowcount of 5 is related to the behind-the-scenes
creation of a temporary conglomerate.
> MERGE UPDATE failing: Restore of a serializable or SQLData object of class ,
> attempted to read more data than was originally stored
> ---
>
> Key: DERBY-7145
> URL: https://issues.apache.org/jira/browse/DERBY-7145
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.2.0, 10.15.2.0, 10.16.1.1, 10.17.0.0
> Environment: Windows 10, JDK 8, Derby 10.14.2.0;
> Windows 10, JDK 11, Derby 10.15.2.0;
> Windows 10, JDK 17, Derby 10.16.1.1.
>Reporter: Stanimir Stamenkov
>Priority: Major
> Attachments: bug-demo3.zip, derby.log, derby2.log, sysinfo.txt
>
>
> _\[May be related to DERBY-7144.\]_
> [^bug-demo3.zip] – a revision of {{bug-demo2.zip}} in DERBY-7144. Extract;
> Copy the Derby JARs to a {{lib/}} subdirectory; Compile:
> {noformat}
> $ mkdir classes
> $ javac -d classes src/net/example/derby/*.java
> {noformat}
> Run to see the problem:
> {noformat}
> $ java -cp "classes;lib/*" net.example.derby.BugDemo -seed -merge -print
> {noformat}
> {noformat}
> Exception in thread "main" java.sql.SQLException: Restore of a serializable
> or SQLData object of class , attempted to read more data than was originally
> stored
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:115)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:141)
> at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:252)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:431)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353)
> at
> org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2405)
> at
> org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:88)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1436)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1709)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeLargeUpdate(EmbedPreparedStatement.java:320)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:309)
> at net.example.derby.BugDemo.mergeData(BugDemo.java:125)
> at net.example.derby.BugDemo.run(BugDemo.java:254)
> at net.example.derby.BugDemo.main(BugDemo.java:224)
> Caused by: ERROR XSDA7: Restore of a serializable or SQLData object of class
> , attempted to read more data than was originally stored
> at
> org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory.java:170)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:75)
> ... 13 more
> Caused by: java.io.EOFException
> at
> org.apache.derby.iapi.services.io.ArrayInputStream.readLong(ArrayInputStream.java:323)
> at
> org.apache.derby.iapi.types.SQLLongint.readExternal(SQLLongint.java:184)
> at
> org.apache.derby.iapi.types.DataType.readExternalFromArray(DataType.java:276)
> at
> org.apache.derby.impl.store.raw.data.StoredPage.readRecordFromArray(StoredPage.java:5676)
> at
> org.apache.derby.impl.store.raw.data.StoredPage.restoreRecordFromSlot(StoredPage.java:1514)
> at
> org.apache.derby.impl.store.raw.data.BasePage.fetchFromSlot(BasePage.java:450)
> at
> org.apache.derby.impl.store.raw.data.CachedPage.fetchFromSlot(CachedPage.java:53)
> at
> org.apache.derby.impl.store.access.conglomerate.GenericScanController.fetch(GenericScanController.java:1518)
> at
> org.apache.derby.impl.store.access.conglomerate.GenericScanController.fetch(GenericScanController.java:1487)
> at
> org.apache.derby.impl.sql.execute.TemporaryRowHolderResultSet.getNextRowCore(TemporaryRowHolderResultSet.java:499)
> at
> org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java:148)
>
[jira] [Commented] (DERBY-6925) Bug in derby_common.sh
[ https://issues.apache.org/jira/browse/DERBY-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606615#comment-17606615 ] Bryan Pendleton commented on DERBY-6925: +1 to Piotr's change; thanks for the patch! I, too, always use derbyrun.jar (and I don't use Docker very often); I guess that's why I've never encountered this issue in my own work. > Bug in derby_common.sh > -- > > Key: DERBY-6925 > URL: https://issues.apache.org/jira/browse/DERBY-6925 > Project: Derby > Issue Type: Bug >Reporter: Eli Barzilay >Priority: Minor > Attachments: DERBY-6925.diff > > Original Estimate: 1h > Remaining Estimate: 1h > > At the end of the `derby_common.sh` file, as I currently see in the GH > mirror: > > https://github.com/apache/derby/blob/trunk/bin/templates/derby_common.sh#L166 > there is an unquoted use of $SHELL which should really be quoted. We > have run into this bug trying to start the server in a docker image, > with a setup that has no SHELL variable, which results in a syntax > error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DERBY-7144) MERGE INSERT failing when target has GENERATED IDENTITY column
[
https://issues.apache.org/jira/browse/DERBY-7144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Pendleton updated DERBY-7144:
---
Summary: MERGE INSERT failing when target has GENERATED IDENTITY column
(was: MERGE INSERT failing when target has GENERATED INDENTITY column)
> MERGE INSERT failing when target has GENERATED IDENTITY column
> --
>
> Key: DERBY-7144
> URL: https://issues.apache.org/jira/browse/DERBY-7144
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.2.0, 10.15.2.0, 10.16.1.1
> Environment: Windows 10, JDK 8, Derby 10.14.2.0;
> Windows 10, JDK 11, Derby 10.15.2.0;
> Windows 10, JDK 17, Derby 10.16.1.1.
>Reporter: Stanimir Stamenkov
>Priority: Major
> Fix For: 10.15.2.1, 10.16.1.2, 10.17.0.0
>
> Attachments: branches-10.14.diff, bug-demo.zip, bug-demo2.zip,
> derby-7144-01-aa-reformatTemporaryRowHolderImpl.diff,
> derby-7144-02-ae-reformat.diff,
> derby-7144-03-aa-computeRowTemplateAndTrackIdentityColumnsBetter.diff,
> derby-7144-1.sql, derby-7144-2.sql, derby-7144-3.sql, derby-7144-default.sql,
> derby-7144.sql, derby.log, svn-merge.log, sysinfo.out
>
>
> _TL;DR:_ The following statement fails (most often) when the target table has
> a GENERATED BY DEFAULT AS IDENTITY primary key:
> {code:sql}
> MERGE INTO AGGREGATEDATA target
> USING TABLE (AGGREGATE_BULK_DATA()) source
>ON target.CATEGORY = source.CATEGORY
> AND target.AGGDATE = source.AGGDATE
> WHEN MATCHED THEN
> UPDATE SET VALUE = target.VALUE + source.VALUE,
> ATTIME = CASE WHEN source.ATTIME < target.ATTIME THEN target.ATTIME
> ELSE source.ATTIME END,
> AGGCOUNT = target.AGGCOUNT + source.AGGCOUNT
> WHEN NOT MATCHED THEN
> INSERT (CATEGORY, VALUE, ATTIME, AGGDATE, AGGCOUNT)
> VALUES (source.CATEGORY, source.VALUE, source.ATTIME, source.AGGDATE,
> source.AGGCOUNT)
> {code}
> {noformat}
> java.sql.SQLException: Java exception: ': java.lang.NullPointerException'.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.seeNextException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeLargeUpdate(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown
> Source)
> at net.example.derby.BugDemo.mergeData(BugDemo.java:124)
> at net.example.derby.BugDemo.run(BugDemo.java:242)
> at net.example.derby.BugDemo.main(BugDemo.java:212)
> Caused by: ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.wrapArgsForTransportAcrossDRDA(Unknown
> Source)
> ... 15 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.derby.impl.store.access.conglomerate.ConglomerateUtil.createFormatIds(Unknown
> Source)
> at org.apache.derby.impl.store.access.heap.Heap.create(Unknown Source)
> at
> org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.createConglomerate(Unknown
> Source)
> at
> org.apache.derby.impl.store.access.RAMTransaction.createConglomerate(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.TemporaryRowHolderImpl.insert(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.MatchingClauseConstantAction.bufferThenRow(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.MergeResultSet.collectAffectedRows(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.MergeResultSet.open(Unknown Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
> Source)
> ... 7 more
> {noformat}
> With the debug-version JARs I'm getting:
> {noformat}
> java.sql.SQLException: Java exception: 'ASSERT FAILED row template is null
> for column[0].:
[jira] [Commented] (DERBY-7144) MERGE INSERT failing when target has GENERATED INDENTITY column
[
https://issues.apache.org/jira/browse/DERBY-7144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17574865#comment-17574865
]
Bryan Pendleton commented on DERBY-7144:
Very interesting bug! I suspect this has been around a long time, glad you were
able to track it down, Rick.
And thanks Stanimir for the very clean and precise bug report, very helpful!
> MERGE INSERT failing when target has GENERATED INDENTITY column
> ---
>
> Key: DERBY-7144
> URL: https://issues.apache.org/jira/browse/DERBY-7144
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.2.0, 10.15.2.0, 10.16.1.1
> Environment: Windows 10, JDK 8, Derby 10.14.2.0;
> Windows 10, JDK 11, Derby 10.15.2.0;
> Windows 10, JDK 17, Derby 10.16.1.1.
>Reporter: Stanimir Stamenkov
>Priority: Major
> Attachments: bug-demo.zip, bug-demo2.zip, derby-7144-1.sql,
> derby-7144-2.sql, derby-7144-3.sql, derby-7144-default.sql, derby-7144.sql,
> derby.log, sysinfo.out
>
>
> _TL;DR:_ The following statement fails (most often) when the target table has
> a GENERATED BY DEFAULT AS IDENTITY primary key:
> {code:sql}
> MERGE INTO AGGREGATEDATA target
> USING TABLE (AGGREGATE_BULK_DATA()) source
>ON target.CATEGORY = source.CATEGORY
> AND target.AGGDATE = source.AGGDATE
> WHEN MATCHED THEN
> UPDATE SET VALUE = target.VALUE + source.VALUE,
> ATTIME = CASE WHEN source.ATTIME < target.ATTIME THEN target.ATTIME
> ELSE source.ATTIME END,
> AGGCOUNT = target.AGGCOUNT + source.AGGCOUNT
> WHEN NOT MATCHED THEN
> INSERT (CATEGORY, VALUE, ATTIME, AGGDATE, AGGCOUNT)
> VALUES (source.CATEGORY, source.VALUE, source.ATTIME, source.AGGDATE,
> source.AGGCOUNT)
> {code}
> {noformat}
> java.sql.SQLException: Java exception: ': java.lang.NullPointerException'.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.seeNextException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeLargeUpdate(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown
> Source)
> at net.example.derby.BugDemo.mergeData(BugDemo.java:124)
> at net.example.derby.BugDemo.run(BugDemo.java:242)
> at net.example.derby.BugDemo.main(BugDemo.java:212)
> Caused by: ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.wrapArgsForTransportAcrossDRDA(Unknown
> Source)
> ... 15 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.derby.impl.store.access.conglomerate.ConglomerateUtil.createFormatIds(Unknown
> Source)
> at org.apache.derby.impl.store.access.heap.Heap.create(Unknown Source)
> at
> org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.createConglomerate(Unknown
> Source)
> at
> org.apache.derby.impl.store.access.RAMTransaction.createConglomerate(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.TemporaryRowHolderImpl.insert(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.MatchingClauseConstantAction.bufferThenRow(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.MergeResultSet.collectAffectedRows(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.MergeResultSet.open(Unknown Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
> Source)
> ... 7 more
> {noformat}
> With the debug-version JARs I'm getting:
> {noformat}
> java.sql.SQLException: Java exception: 'ASSERT FAILED row template is null
> for column[0].: org.apache.derby.shared.common.sanity.AssertFailure'.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:115)
> at
>
[jira] [Commented] (DERBY-7143) HarmonySerialBlob.getBinaryStream(long, long) makes it impossible to retrieve the last character of the Blob.
[ https://issues.apache.org/jira/browse/DERBY-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561492#comment-17561492 ] Bryan Pendleton commented on DERBY-7143: Perhaps you could contribute a patch? Your patch could be as simple as: * Contribute a new regression test to the Derby regression suite, demonstrating the problem, you could perhaps add a testcase to org.apache.derbyTesting.functionTests.tests.jdbcapi.BlobTest? * Contribute a change to HarmonySerialBlob.java, demonstrating a fix; perhaps it's as simple as changing if (pos < 1 || pos + length > len) to if (pos < 1 || (pos-1) + length > len) > HarmonySerialBlob.getBinaryStream(long, long) makes it impossible to retrieve > the last character of the Blob. > - > > Key: DERBY-7143 > URL: https://issues.apache.org/jira/browse/DERBY-7143 > Project: Derby > Issue Type: Bug > Components: Network Client, SQL >Affects Versions: 10.15.2.0 >Reporter: Ben >Priority: Major > > As far as I understand it, the method HarmonySerialBlob.getBinaryStream(long, > long) takes two arguments and and is supposed to produce a > ByteArrayInputStream() with a substring of the Blob's Contents that starts at > and has length . > Unfortunately, the error handling in this method makes it impossible to > retrieve a suffix of the Blobs contents as the last character is always > missing. > In detail: > When calling this method with =0, then it raises the SQLException XJ087. > Hence, must always be > 0. > When calling this method with =1 and =blob.length(), then it > also raises the SQLException, because pos+length > blob.length(). Hence, > can at most be set to blob.length()-1. > When calling this method with =1 and =blob.length()-1, then it > gives a ByteArrayInputStream which is missing the last character from the > blob. > The fact that the last character is missing makes sense, when is set > to blob.length()-1. > But it does not make sense to prohibit setting =blob.length() when > this is the only way to include the last character in the > ByteArrayInputStream. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7142) Contribution code through gihub?
[ https://issues.apache.org/jira/browse/DERBY-7142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17556928#comment-17556928 ] Bryan Pendleton commented on DERBY-7142: Hello Christoph, thank you for your interest in Derby! The best way to communicate with the developers is via the derby-dev mailing list. I am not sure why it is not working for you, it is working fine for other subscribers, here are the active archives: [https://lists.apache.org/list.html?derby-dev@db.apache.org] The active SCM repository for Derby is the Subversion repository, you can see it here: [https://svn.apache.org/viewvc/db/derby/] The best guide for new contributors is this: [https://db.apache.org/derby/derby_comm.html#Contribute+Code+or+Documentation] I agree that the Derby wiki can be hard to navigate. It was moved from one hosting platform to another one some years ago and the conversion was not as clean as we wish it had been. Contributions to improving the wiki are also very welcome! But the first problem is that you need to figure out why you have been unable to subscribe to the derby-dev mailing list and why you are unable to use the mailing list. > Contribution code through gihub? > > > Key: DERBY-7142 > URL: https://issues.apache.org/jira/browse/DERBY-7142 > Project: Derby > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > > Hi derby-dev's, > > first of all sorry for askin more a question through ticket system by the > derby mailing list seems to be down (I always get timeouts when sending > messages) > I'd like to contribute some code to derby and wonder if the github mirror is > suitable for this purpose? > [https://github.com/apache/derby] > according to the github ui it was updated last in 2019 but I see never > releases at maven central e.g.: > [https://mvnrepository.com/artifact/org.apache.derby/derbyclient] > or do I need to use (but I can't see when it was last updated?): > [http://svn.apache.org/repos/asf/db/derby/code/trunk/] > or is there maybe even a completely other place an documentation is just > outdated? I tried the wiki and confluence pages but the mostly reference each > other and I can't get a clear view how to get the latest code. > Thanks in advance. > Christoph -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (DERBY-7133) Make it possible to build and test Derby cleanly with OpenJDK 19
[ https://issues.apache.org/jira/browse/DERBY-7133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17556621#comment-17556621 ] Bryan Pendleton commented on DERBY-7133: Our JDK 19 joy was short-lived, eh? Your proposal seems just fine to me. I'm in no particular rush to move to JDK 19 (nor to JDK 23), and I can't foresee us needing a new feature release right away, I haven't heard of any Derby feature development that's underway and looking for a release vehicle. > Make it possible to build and test Derby cleanly with OpenJDK 19 > > > Key: DERBY-7133 > URL: https://issues.apache.org/jira/browse/DERBY-7133 > Project: Derby > Issue Type: Task >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Priority: Major > > Builds of JDK 19 can be found at https://jdk.java.net/19/ We should adjust > Derby as necessary so that it builds cleanly (including javadoc) and tests > cleanly with this version of the platform. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (DERBY-7136) Tasks for releasing 10.16.1
[ https://issues.apache.org/jira/browse/DERBY-7136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537825#comment-17537825 ] Bryan Pendleton commented on DERBY-7136: Thanks Rick, I don't have any improvements to suggest, I think those release notes are both succinct and clear. And I think this might be the first time I've seen the use of "aegis" in our Release Notes :) Thank you for the table of possible alternate mitigations to achieve the goals without the Security Manager, it will be interesting to get feedback from other users about this. I never made much use of the Security Manager features so I don't have much experience in this area. > Tasks for releasing 10.16.1 > --- > > Key: DERBY-7136 > URL: https://issues.apache.org/jira/browse/DERBY-7136 > Project: Derby > Issue Type: Task > Components: Build tools >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7136-01-aa-firstDraftOfReleaseNotes.diff > > > Placeholder for activity related to producing a 10.16.1 release. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (DERBY-7137) Compile 10.16 into Java 17 byte code so that it won't run on earlier platforms
[ https://issues.apache.org/jira/browse/DERBY-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537116#comment-17537116 ] Bryan Pendleton commented on DERBY-7137: Yes I think that release note gets the message across quite clearly. +1. > Compile 10.16 into Java 17 byte code so that it won't run on earlier platforms > -- > > Key: DERBY-7137 > URL: https://issues.apache.org/jira/browse/DERBY-7137 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.16.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Fix For: 10.16.0.0 > > Attachments: derby-7137-01-aa-compileToJava17byteCode.diff, > releaseNote.html > > > The 10.16 network server must be run with -Djava.security.manager=allow in > order to enable the Java Security Manager over the objections of > https://openjdk.java.net/jeps/411. The meaning of that flag has changed since > Java 11. To minimize confusion, we want to prevent people from accidentally > running 10.16 on Java platforms older than Java 17. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (DERBY-7137) Compile 10.16 into Java 17 byte code so that it won't run on earlier platforms
[ https://issues.apache.org/jira/browse/DERBY-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537047#comment-17537047 ] Bryan Pendleton commented on DERBY-7137: Thanks for the release note, Rick! I wonder if the text should use "must" instead of "should". > Compile 10.16 into Java 17 byte code so that it won't run on earlier platforms > -- > > Key: DERBY-7137 > URL: https://issues.apache.org/jira/browse/DERBY-7137 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.16.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Fix For: 10.16.0.0 > > Attachments: derby-7137-01-aa-compileToJava17byteCode.diff, > releaseNote.html > > > The 10.16 network server must be run with -Djava.security.manager=allow in > order to enable the Java Security Manager over the objections of > https://openjdk.java.net/jeps/411. The meaning of that flag has changed since > Java 11. To minimize confusion, we want to prevent people from accidentally > running 10.16 on Java platforms older than Java 17. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (DERBY-7138) Remove references to the Java Security Manager
[ https://issues.apache.org/jira/browse/DERBY-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536384#comment-17536384 ] Bryan Pendleton commented on DERBY-7138: No apologies needed! I think the technique you used was very sensible, and it's exactly the way I would have approached it, had I but your energy. On we go into the future, all is well. > Remove references to the Java Security Manager > -- > > Key: DERBY-7138 > URL: https://issues.apache.org/jira/browse/DERBY-7138 > Project: Derby > Issue Type: Task > Components: Build tools, Documentation >Affects Versions: 10.16.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: DerbyServerTest.java, Z.java, > derby-3547-01-aa-policyGenerator.diff, > derby-7138-01-aa-removeSecurityManagerFromOldHarnessTests.diff, > derby-7138-02-ab-moveMethodsToTestConfiguration.diff, > derby-7138-03-aa-removePermissionsTests.diff, > derby-7138-04-ab-hostChangeInNetworkServerControlApiTest.diff, > derby-7138-05-aa-removeSecurityManager.diff, > derby-7138-06-aa-removeSecurityManagerSetup.diff, > derby-7138-07-aa-removePrivilegeBlocksFromTests.diff, > derby-7138-08-aa-removePolicyFiles.diff, > derby-7138-09-aa-removeMostProductPrivilegeFiles.diff, > derby-7138-10-aa-removeRemainingPrivilegeBlocks.diff, > derby-7138-11-aa-miscCleanup.diff, > derby-7138-12-aa-SYSCS_RELOAD_SECURITY_POLICY.diff, > derby-7138-13-aa-adjustUserDocumentation.diff, > derby-7138-13-aa-adjustUserDocumentation.tar, > derby-7138-14-aa-removeMoreDocReferences-1.tar, > derby-7138-14-aa-removeMoreDocReferences.diff, > derby-7138-14-aa-removeMoreDocReferences.tar, > derby-7138-16-aa-removeMoreReferences.diff, > derby-7138-17-ab-securityExceptions.diff, > derby-7138-18-aa-moreSecurityExceptions.diff, > derby-7138-19-aa-privilegedActions.diff, derby-7138-20-aa-fixJavadoc.diff, > postSecurityManager.html, releaseNote.html > > > The Open JDK team has deprecated the Java Security Manager and indicated that > it will be removed in a future release of Java. See > https://openjdk.java.net/jeps/411. In an email thread titled "protecting > security-sensitive operations on multi-tenant servers" on the > security-...@openjdk.java.net mailing list, Alan Bateman indicated that > developers should containerize their applications instead. > This issue tracks work needed to remove Derby's references to the Java > Security Manager. > At a minimum, the following work needs to be done: > o The tests should be adjusted so that they don't install a SecurityManager. > o References to the SecurityManager should be removed from product code. > o We should remove the SecurityManager section of the Derby Security Guide. > In its place, we should recommend that developers containerize their Derby > applications. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (DERBY-7138) Remove references to the Java Security Manager
[ https://issues.apache.org/jira/browse/DERBY-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536289#comment-17536289 ] Bryan Pendleton commented on DERBY-7138: My what a lot of cleanup this has been! It's been very interesting to watch all the incremental progress you've been making, and how many different details there were along the way. I guess that the Security Manager work was accomplished over a decade (or more?), and so it's no surprise that unwinding it has been a fair piece of work. > Remove references to the Java Security Manager > -- > > Key: DERBY-7138 > URL: https://issues.apache.org/jira/browse/DERBY-7138 > Project: Derby > Issue Type: Task > Components: Build tools, Documentation >Affects Versions: 10.16.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: DerbyServerTest.java, Z.java, > derby-3547-01-aa-policyGenerator.diff, > derby-7138-01-aa-removeSecurityManagerFromOldHarnessTests.diff, > derby-7138-02-ab-moveMethodsToTestConfiguration.diff, > derby-7138-03-aa-removePermissionsTests.diff, > derby-7138-04-ab-hostChangeInNetworkServerControlApiTest.diff, > derby-7138-05-aa-removeSecurityManager.diff, > derby-7138-06-aa-removeSecurityManagerSetup.diff, > derby-7138-07-aa-removePrivilegeBlocksFromTests.diff, > derby-7138-08-aa-removePolicyFiles.diff, > derby-7138-09-aa-removeMostProductPrivilegeFiles.diff, > derby-7138-10-aa-removeRemainingPrivilegeBlocks.diff, > derby-7138-11-aa-miscCleanup.diff, > derby-7138-12-aa-SYSCS_RELOAD_SECURITY_POLICY.diff, > derby-7138-13-aa-adjustUserDocumentation.diff, > derby-7138-13-aa-adjustUserDocumentation.tar, > derby-7138-14-aa-removeMoreDocReferences-1.tar, > derby-7138-14-aa-removeMoreDocReferences.diff, > derby-7138-14-aa-removeMoreDocReferences.tar, > derby-7138-16-aa-removeMoreReferences.diff, > derby-7138-17-ab-securityExceptions.diff, > derby-7138-18-aa-moreSecurityExceptions.diff, > derby-7138-19-aa-privilegedActions.diff, derby-7138-20-aa-fixJavadoc.diff, > postSecurityManager.html > > > The Open JDK team has deprecated the Java Security Manager and indicated that > it will be removed in a future release of Java. See > https://openjdk.java.net/jeps/411. In an email thread titled "protecting > security-sensitive operations on multi-tenant servers" on the > security-...@openjdk.java.net mailing list, Alan Bateman indicated that > developers should containerize their applications instead. > This issue tracks work needed to remove Derby's references to the Java > Security Manager. > At a minimum, the following work needs to be done: > o The tests should be adjusted so that they don't install a SecurityManager. > o References to the SecurityManager should be removed from product code. > o We should remove the SecurityManager section of the Derby Security Guide. > In its place, we should recommend that developers containerize their Derby > applications. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (DERBY-7138) Remove references to the Java Security Manager
[ https://issues.apache.org/jira/browse/DERBY-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522309#comment-17522309 ] Bryan Pendleton commented on DERBY-7138: Delete that code! Delete that code! Delete that code! Yay! > Remove references to the Java Security Manager > -- > > Key: DERBY-7138 > URL: https://issues.apache.org/jira/browse/DERBY-7138 > Project: Derby > Issue Type: Task > Components: Build tools, Documentation >Affects Versions: 10.16.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: DerbyServerTest.java, Z.java, > derby-7138-01-aa-removeSecurityManagerFromOldHarnessTests.diff, > derby-7138-02-ab-moveMethodsToTestConfiguration.diff, > derby-7138-03-aa-removePermissionsTests.diff, > derby-7138-04-ab-hostChangeInNetworkServerControlApiTest.diff, > derby-7138-05-aa-removeSecurityManager.diff > > > The Open JDK team has deprecated the Java Security Manager and indicated that > it will be removed in a future release of Java. See > https://openjdk.java.net/jeps/411. In an email thread titled "protecting > security-sensitive operations on multi-tenant servers" on the > security-...@openjdk.java.net mailing list, Alan Bateman indicated that > developers should containerize their applications instead. > This issue tracks work needed to remove Derby's references to the Java > Security Manager. > At a minimum, the following work needs to be done: > o The tests should be adjusted so that they don't install a SecurityManager. > o References to the SecurityManager should be removed from product code. > o We should remove the SecurityManager section of the Derby Security Guide. > In its place, we should recommend that developers containerize their Derby > applications. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DERBY-7138) Remove references to the Java Security Manager
[ https://issues.apache.org/jira/browse/DERBY-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516791#comment-17516791 ] Bryan Pendleton commented on DERBY-7138: I *do* love a commit which simply deletes unneeded tests, thanks! > Remove references to the Java Security Manager > -- > > Key: DERBY-7138 > URL: https://issues.apache.org/jira/browse/DERBY-7138 > Project: Derby > Issue Type: Task > Components: Build tools, Documentation >Affects Versions: 10.16.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: > derby-7138-01-aa-removeSecurityManagerFromOldHarnessTests.diff, > derby-7138-02-ab-moveMethodsToTestConfiguration.diff, > derby-7138-03-aa-removePermissionsTests.diff > > > The Open JDK team has deprecated the Java Security Manager and indicated that > it will be removed in a future release of Java. See > https://openjdk.java.net/jeps/411. In an email thread titled "protecting > security-sensitive operations on multi-tenant servers" on the > security-...@openjdk.java.net mailing list, Alan Bateman indicated that > developers should containerize their applications instead. > This issue tracks work needed to remove Derby's references to the Java > Security Manager. > At a minimum, the following work needs to be done: > o The tests should be adjusted so that they don't install a SecurityManager. > o References to the SecurityManager should be removed from product code. > o We should remove the SecurityManager section of the Derby Security Guide. > In its place, we should recommend that developers containerize their Derby > applications. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DERBY-7126) Make it possible to build and test Derby cleanly with OpenJDK 18
[ https://issues.apache.org/jira/browse/DERBY-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510692#comment-17510692 ] Bryan Pendleton commented on DERBY-7126: That seems like a great plan! I thought that 10.15 still ran on JDK 9+, but I guess you're saying that JDK 9 and 10 were *not* LTS? The word "support" seems a bit loaded, I guess. Perhaps what we claim is more like "testing"? In the release note, or maybe on [https://db.apache.org/derby/derby_downloads.html,] or maybe in both places, it would be nice to include examples of the error messages that you get if you * Try to run 10.15 or 10.16 on JDK 8 * Try to run 10.16 on JDK 11 > Make it possible to build and test Derby cleanly with OpenJDK 18 > > > Key: DERBY-7126 > URL: https://issues.apache.org/jira/browse/DERBY-7126 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.16.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: DERBY_7126_A.java, DERBY_7126_B.java, dcl_emc2sm.jar, > derby-7126-01-aa-regenerateSignedJars.diff, > derby-7126-02-aa-suppressDeprecationWarnings.diff, > derby-7126-03-aa-mention-java.security.manager.diff, > derby-7126-04-aa-makeTestsRunOnJDK11andJDK18.diff, > derby-7126-05-aa-suppressRemovalWarnings.diff > > > Releases of Open JDK 18 can be found at https://jdk.java.net/178. We should > adjust Derby as necessary so that it builds cleanly (including javadoc) and > tests cleanly with this version of the platform. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DERBY-7126) Make it possible to build and test Derby cleanly with OpenJDK 18
[ https://issues.apache.org/jira/browse/DERBY-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510173#comment-17510173 ] Bryan Pendleton commented on DERBY-7126: Hi Rick, I've been starting to see a few questions about the new "deprecated" messages in JDK 17+ Here's an example: [https://stackoverflow.com/questions/71541745/i-keep-getting-this-error-messages-when-try-to-use-javadb] I wonder if we should start planning for releasing a new version that supports JDK 17+? > Make it possible to build and test Derby cleanly with OpenJDK 18 > > > Key: DERBY-7126 > URL: https://issues.apache.org/jira/browse/DERBY-7126 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.16.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: DERBY_7126_A.java, DERBY_7126_B.java, dcl_emc2sm.jar, > derby-7126-01-aa-regenerateSignedJars.diff, > derby-7126-02-aa-suppressDeprecationWarnings.diff, > derby-7126-03-aa-mention-java.security.manager.diff, > derby-7126-04-aa-makeTestsRunOnJDK11andJDK18.diff, > derby-7126-05-aa-suppressRemovalWarnings.diff > > > Releases of Open JDK 18 can be found at https://jdk.java.net/178. We should > adjust Derby as necessary so that it builds cleanly (including javadoc) and > tests cleanly with this version of the platform. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DERBY-7135) Does derby 10.14.2.0 contain the CVE-2020-13949 vulnerability?
[ https://issues.apache.org/jira/browse/DERBY-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510018#comment-17510018 ] Bryan Pendleton commented on DERBY-7135: This seems like a flaw in the scanning tool. Apache Derby does not include any source code from Apache Thrift and I have not heard of any reports of CVE-2020-13949 for Apache Derby. Perhaps you could contact the vendor of the scanning tool and ask them to help you figure out why your copy of derbynet.jar is being flagged as containing this CVE? > Does derby 10.14.2.0 contain the CVE-2020-13949 vulnerability? > -- > > Key: DERBY-7135 > URL: https://issues.apache.org/jira/browse/DERBY-7135 > Project: Derby > Issue Type: Bug >Affects Versions: 10.14.2.0 >Reporter: JenickLee >Priority: Blocker > Attachments: Snipaste_2022-03-22_00-43-37.png, > Snipaste_2022-03-22_00-51-12.png > > > Use a security tool to scan the derby 10.14.2.0 installation package. *The > result shows that derbynet.jar contains the CVE-2020-13949 vulnerability.* > The vulnerability is related to Hive and Thrift, but no reference is found > in the derby 10.14.2.0 source code. > *Is it a false positive? Which of the following application scenarios will be > affected if the vulnerability is involved?* > For details about the scanning result, see the attachment. > Vulnerability Details: > [https://nvd.nist.gov/vuln/detail/CVE-2020-13949] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DERBY-7132) SQLDataException when executing CAST inside a CASE WHEN clause
[
https://issues.apache.org/jira/browse/DERBY-7132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500836#comment-17500836
]
Bryan Pendleton commented on DERBY-7132:
Thanks for continuing to investigate this!
There are some guides to working with generated code in the Derby wiki, for
example [https://cwiki.apache.org/confluence/display/DERBY/DumpClassFile]
And there is some documentation about viewing and understanding query plans in
the Derby documentation, for example
[https://db.apache.org/derby/docs/10.15/tuning/ctundepth13055.html]
There is also the simpler derby.language.logQueryPlan=true, which writes query
plan information to the log file
> SQLDataException when executing CAST inside a CASE WHEN clause
> --
>
> Key: DERBY-7132
> URL: https://issues.apache.org/jira/browse/DERBY-7132
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.2.0, 10.15.2.0
>Reporter: Stamatis Zampetakis
>Priority: Major
> Attachments: derby-dump.tar.gz, schemaddl.sql, uml_schema.svg
>
>
> {code:sql}
> SELECT "PARTITIONS"."PART_ID"
> FROM "PARTITIONS"
> INNER JOIN "TBLS" ON "PARTITIONS"."TBL_ID" = "TBLS"."TBL_ID"
> INNER JOIN "DBS" ON "TBLS"."DB_ID" = "DBS"."DB_ID"
> INNER JOIN "PARTITION_KEY_VALS" "FILTER0" ON "FILTER0"."PART_ID" =
> "PARTITIONS"."PART_ID"
> WHERE "DBS"."CTLG_NAME" = 'hive'
> AND "TBLS"."TBL_NAME" = 'src_bucket_tbl'
> AND "DBS"."NAME" = 'default'
> AND "FILTER0"."INTEGER_IDX" = 0
> AND (((CASE
> WHEN "FILTER0"."PART_KEY_VAL" <> '__HIVE_DEFAULT_PARTITION__'
> AND "TBLS"."TBL_NAME" = 'src_bucket_tbl'
> AND "DBS"."NAME" = 'default'
> AND "DBS"."CTLG_NAME" = 'hive'
> AND "FILTER0"."INTEGER_IDX" = 0 THEN
> cast("FILTER0"."PART_KEY_VAL" AS decimal(21, 0))
> END) = 10))
> {code}
> The SQL query above fails with the following stacktrace when attempting to
> evaluate the CAST expression. Note that the condition inside the CASE WHEN
> clause guarantees that only legal values (numbers) should be passed inside
> the CAST function. Apparently, the operations are somehow re-ordered and the
> CAST is evaluated before the condition in the WHEN clause which has a result
> a non-number to be passed in the CAST and cause the exception below.
> {noformat}
> Exception in thread "main" java.sql.SQLDataException: Invalid character
> string format for type DECIMAL.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:84)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:230)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:424)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353)
> at
> org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2405)
> at
> org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:88)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1436)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1709)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(EmbedPreparedStatement.java:286)
> at com.github.zabetak.CaseProblem.main(CaseProblem.java:63)
> Caused by: ERROR 22018: Invalid character string format for type DECIMAL.
> at
> org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290)
> at
> org.apache.derby.iapi.error.StandardException.newException(StandardException.java:285)
> at
> org.apache.derby.iapi.types.DataType.invalidFormat(DataType.java:1280)
> at org.apache.derby.iapi.types.DataType.setValue(DataType.java:552)
> at
> org.apache.derby.exe.acf81e0010x017fx0812xbaa5x3a07fe880.e3(Unknown
> Source)
> at
> org.apache.derby.impl.services.reflect.DirectCall.invoke(ReflectGeneratedClass.java:107)
> at
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:302)
> at
> org.apache.derby.impl.sql.execute.NestedLoopJoinResultSet.getNextRowCore(NestedLoopJoinResultSet.java:119)
> at
> org.apache.derby.impl.sql.execute.JoinResultSet.openCore(JoinResultSet.java:149)
> at
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(ProjectRestrictResultSet.java:182)
> at
> org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(BasicNoPutResultSetImpl.java:266)
> at
>
[jira] [Commented] (DERBY-7133) Make it possible to build and test Derby cleanly with OpenJDK 19
[ https://issues.apache.org/jira/browse/DERBY-7133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499815#comment-17499815 ] Bryan Pendleton commented on DERBY-7133: That's a welcome change! > Make it possible to build and test Derby cleanly with OpenJDK 19 > > > Key: DERBY-7133 > URL: https://issues.apache.org/jira/browse/DERBY-7133 > Project: Derby > Issue Type: Task >Affects Versions: 10.16.0.0 >Reporter: Richard N. Hillegas >Priority: Major > > Builds of JDK 19 can be found at https://jdk.java.net/19/ We should adjust > Derby as necessary so that it builds cleanly (including javadoc) and tests > cleanly with this version of the platform. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DERBY-7126) Make it possible to build and test Derby cleanly with OpenJDK 18
[ https://issues.apache.org/jira/browse/DERBY-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469432#comment-17469432 ] Bryan Pendleton commented on DERBY-7126: Still seems quite strange to me that none of this is listed on [https://openjdk.java.net/projects/jdk/18/] I guess it just indicates that Derby's codebase has drifted far from the Java mainstream, and the problems that Derby encounters in this Jira issue were not considered very significant. > Make it possible to build and test Derby cleanly with OpenJDK 18 > > > Key: DERBY-7126 > URL: https://issues.apache.org/jira/browse/DERBY-7126 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.16.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: DERBY_7126_A.java, DERBY_7126_B.java, dcl_emc2sm.jar, > derby-7126-01-aa-regenerateSignedJars.diff, > derby-7126-02-aa-suppressDeprecationWarnings.diff, > derby-7126-03-aa-mention-java.security.manager.diff, > derby-7126-04-aa-makeTestsRunOnJDK11andJDK18.diff > > > Releases of Open JDK 18 can be found at https://jdk.java.net/178. We should > adjust Derby as necessary so that it builds cleanly (including javadoc) and > tests cleanly with this version of the platform. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DERBY-7126) Make it possible to build and test Derby cleanly with OpenJDK 18
[ https://issues.apache.org/jira/browse/DERBY-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446515#comment-17446515 ] Bryan Pendleton commented on DERBY-7126: It's starting to feel a bit as though JDK 18 will be a watershed release for Derby with some external consequences similar in scope to JDK 9, though internally of course the situation with the two Java releases is very different. I'm wondering if we should lay the groundwork to have a new major release of Derby, just as we did with JDK 9, so we'd have: * People who are still using JDK 8 (yes, amazingly, still a large user base): stick with Derby 10.14 * People who have moved to JDK 9-JDK 17: use Derby 10.15 * People who have moved to JDK 18+: use Derby 10.16 > Make it possible to build and test Derby cleanly with OpenJDK 18 > > > Key: DERBY-7126 > URL: https://issues.apache.org/jira/browse/DERBY-7126 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.16.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: DERBY_7126_A.java, DERBY_7126_B.java, dcl_emc2sm.jar, > derby-7126-01-aa-regenerateSignedJars.diff, > derby-7126-02-aa-suppressDeprecationWarnings.diff > > > Releases of Open JDK 18 can be found at https://jdk.java.net/178. We should > adjust Derby as necessary so that it builds cleanly (including javadoc) and > tests cleanly with this version of the platform. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DERBY-7126) Make it possible to build and test Derby cleanly with OpenJDK 18
[ https://issues.apache.org/jira/browse/DERBY-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445609#comment-17445609 ] Bryan Pendleton commented on DERBY-7126: I kind of feel increasingly like an outsider in the Java world, and I fear I just haven't been paying much attention. Still, my reaction to all this is: it seems like the Java world has decided that the future does *not* involve System Programming in Java. I'm not sure what use case they feel Java is best suited for, but it certainly doesn't appear to be building a general purpose DBMS engine. > Make it possible to build and test Derby cleanly with OpenJDK 18 > > > Key: DERBY-7126 > URL: https://issues.apache.org/jira/browse/DERBY-7126 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.16.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: DERBY_7126_A.java, dcl_emc2sm.jar, > derby-7126-01-aa-regenerateSignedJars.diff, > derby-7126-02-aa-suppressDeprecationWarnings.diff > > > Releases of Open JDK 18 can be found at https://jdk.java.net/178. We should > adjust Derby as necessary so that it builds cleanly (including javadoc) and > tests cleanly with this version of the platform. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DERBY-7126) Make it possible to build and test Derby cleanly with OpenJDK 18
[ https://issues.apache.org/jira/browse/DERBY-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445385#comment-17445385 ] Bryan Pendleton commented on DERBY-7126: Rick, do you know which JEP is planning to remove Runtime.exec()? Is that also JEP 411? > Make it possible to build and test Derby cleanly with OpenJDK 18 > > > Key: DERBY-7126 > URL: https://issues.apache.org/jira/browse/DERBY-7126 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.16.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: DERBY_7126_A.java, dcl_emc2sm.jar, > derby-7126-01-aa-regenerateSignedJars.diff, > derby-7126-02-aa-suppressDeprecationWarnings.diff > > > Releases of Open JDK 18 can be found at https://jdk.java.net/178. We should > adjust Derby as necessary so that it builds cleanly (including javadoc) and > tests cleanly with this version of the platform. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DERBY-7126) Make it possible to build and test Derby cleanly with OpenJDK 18
[
https://issues.apache.org/jira/browse/DERBY-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439691#comment-17439691
]
Bryan Pendleton commented on DERBY-7126:
It seems to me that you had a nice clean example of a program that used to
throw an exception and now does not, and the response was that
{quote}Throwing an Exception would be too high of a risk for applications that
happen to load signed JARs off the classpath but don't otherwise behave any
differently.
{quote}
I don't oppose the documentation changes that you're proposing. I also am not
sure that adding more to the documentation really helps anything at this point.
Often, with documentation, more is not necessarily better.
Thanks for digging into this and for sharing the results of your investigation!
> Make it possible to build and test Derby cleanly with OpenJDK 18
>
>
> Key: DERBY-7126
> URL: https://issues.apache.org/jira/browse/DERBY-7126
> Project: Derby
> Issue Type: Task
> Components: Build tools
>Affects Versions: 10.16.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: DERBY_7126_A.java, dcl_emc2sm.jar,
> derby-7126-01-aa-regenerateSignedJars.diff
>
>
> Releases of Open JDK 18 can be found at https://jdk.java.net/178. We should
> adjust Derby as necessary so that it builds cleanly (including javadoc) and
> tests cleanly with this version of the platform.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DERBY-7126) Make it possible to build and test Derby cleanly with OpenJDK 18
[ https://issues.apache.org/jira/browse/DERBY-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17435005#comment-17435005 ] Bryan Pendleton commented on DERBY-7126: This is interesting, thanks for posting the details! I assume that JDK 18 is dropping support for SHA1 because they are trying to force everyone to move to something newer and stronger (is there a SHA2?). Assuming there is a newer replacement, probably we need to figure out how to test with that newer replacement I guess? But it also seems like if JDK doesn't support a certain signing level (that is, SHA1), then it should raise an error, not just quietly disregard the signature. > Make it possible to build and test Derby cleanly with OpenJDK 18 > > > Key: DERBY-7126 > URL: https://issues.apache.org/jira/browse/DERBY-7126 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.16.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: DERBY_7126_A.java > > > Releases of Open JDK 18 can be found at https://jdk.java.net/178. We should > adjust Derby as necessary so that it builds cleanly (including javadoc) and > tests cleanly with this version of the platform. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7124) Errors seen while running the junit-all target
[
https://issues.apache.org/jira/browse/DERBY-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402635#comment-17402635
]
Bryan Pendleton commented on DERBY-7124:
Guess it's been a while since we ran the tests the old-fashioned way. Thanks
for digging into this!
> Errors seen while running the junit-all target
> --
>
> Key: DERBY-7124
> URL: https://issues.apache.org/jira/browse/DERBY-7124
> Project: Derby
> Issue Type: Task
> Components: Test
>Affects Versions: 10.16.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
>
> When I run the following commands...
> {noformat}
> ant clean
> ant all
> ant junit-clean junit-all junitreport
> {noformat}
> ...I see the following output:
> {noformat}
> [junit] Running org.apache.derbyTesting.junit.EnvTest
> [junit] Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 5.344 sec
> [junit] Running
> org.apache.derbyTesting.functionTests.tests.derbynet._Suite
> [junit] Tests run: 338, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 342.785 sec
> [junit] Running org.apache.derbyTesting.functionTests.tests.tools._Suite
> [junit] Tests run: 129, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 78.403 sec
> [junit] Running org.apache.derbyTesting.functionTests.tests.demo._Suite
> [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 50.304 sec
> [junit] Running org.apache.derbyTesting.functionTests.tests.lang._Suite
> [junit] Tests run: 3236, Failures: 0, Errors: 1, Skipped: 0, Time
> elapsed: 1,069.957 sec
> [junit] Test org.apache.derbyTesting.functionTests.tests.lang._Suite
> FAILED
> [junit] Running org.apache.derbyTesting.functionTests.tests.jdbcapi._Suite
> [junit] Tests run: 8015, Failures: 0, Errors: 0, Skipped: 0, Time
> elapsed: 1,255.236 sec
> [junit] Running org.apache.derbyTesting.functionTests.tests.store._Suite
> [junit] Tests run: 346, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 542.981 sec
> [junit] Running org.apache.derbyTesting.functionTests.tests.engine._Suite
> [junit] Tests run: 39, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 160.282 sec
> [junit] Running
> org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationSuite
> [junit] Tests run: 23, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 423.346 sec
> [junit] Running org.apache.derbyTesting.unitTests.junit._Suite
> [junit] Tests run: 169, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.151 sec
> [junit] Running
> org.apache.derbyTesting.functionTests.tests.upgradeTests._Suite
> [junit] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 5.176 sec
> [junit] Running
> org.apache.derbyTesting.functionTests.suites.EncryptionSuite
> [junit] Tests run: 203, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 26.483 sec
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DERBY-7122) java.security.AccessControlException when creating a DB remotely: Permission getenv.SOURCE_DATE_EPOCH
[ https://issues.apache.org/jira/browse/DERBY-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17398676#comment-17398676 ] Bryan Pendleton commented on DERBY-7122: In addition to the Open JDK bug linked above, there is also now a Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/openjdk-16/+bug/1939339 > java.security.AccessControlException when creating a DB remotely: Permission > getenv.SOURCE_DATE_EPOCH > - > > Key: DERBY-7122 > URL: https://issues.apache.org/jira/browse/DERBY-7122 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.14.2.0, 10.15.2.0 >Reporter: Art O Cathain >Priority: Major > Attachments: DERBY_7122.java, derby.log > > > Following the tutorial at > [https://db.apache.org/derby/docs/10.15/getstart/twwdactivity2.html] I get an > AccessControlException in the server log when trying to create a DB (via > CONNECT 'jdbc:derby://localhost:1527/seconddb;create=true') > This is with derby 10.15.2.0 but the same is observed in 10.14 > OS version: Ubuntu 21.04 > Java version: > openjdk version "11.0.11" 2021-04-20 > OpenJDK Runtime Environment (build 11.0.11+9-Ubuntu-0ubuntu2) > OpenJDK 64-Bit Server VM (build 11.0.11+9-Ubuntu-0ubuntu2, mixed mode) > but OpenJDK 16 and 17(early access) have the same problem -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (DERBY-7122) java.security.AccessControlException when creating a DB remotely: Permission getenv.SOURCE_DATE_EPOCH
[ https://issues.apache.org/jira/browse/DERBY-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton updated DERBY-7122: --- Summary: java.security.AccessControlException when creating a DB remotely: Permission getenv.SOURCE_DATE_EPOCH (was: java.security.AccessControlException when creating a DB remotely) > java.security.AccessControlException when creating a DB remotely: Permission > getenv.SOURCE_DATE_EPOCH > - > > Key: DERBY-7122 > URL: https://issues.apache.org/jira/browse/DERBY-7122 > Project: Derby > Issue Type: Bug >Reporter: Art O Cathain >Priority: Major > Attachments: derby.log > > > Following the tutorial at > [https://db.apache.org/derby/docs/10.15/getstart/twwdactivity2.html] I get an > AccessControlException in the server log when trying to create a DB (via > CONNECT 'jdbc:derby://localhost:1527/seconddb;create=true') > This is with derby 10.15.2.0 but the same is observed in 10.14 > OS version: Ubuntu 21.04 > Java version: > openjdk version "11.0.11" 2021-04-20 > OpenJDK Runtime Environment (build 11.0.11+9-Ubuntu-0ubuntu2) > OpenJDK 64-Bit Server VM (build 11.0.11+9-Ubuntu-0ubuntu2, mixed mode) > but OpenJDK 16 and 17(early access) have the same problem -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7122) java.security.AccessControlException when creating a DB remotely
[
https://issues.apache.org/jira/browse/DERBY-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17395240#comment-17395240
]
Bryan Pendleton commented on DERBY-7122:
Rick, is there a downside to adding the following to our base security policy?
{code:java}
grant {
permission java.lang.RuntimePermission "getenv.SOURCE_DATE_EPOCH", "read";
};
{code}
Art, were you able to confirm that this was a viable workaround for you?
> java.security.AccessControlException when creating a DB remotely
>
>
> Key: DERBY-7122
> URL: https://issues.apache.org/jira/browse/DERBY-7122
> Project: Derby
> Issue Type: Bug
>Reporter: Art O Cathain
>Priority: Major
> Attachments: derby.log
>
>
> Following the tutorial at
> [https://db.apache.org/derby/docs/10.15/getstart/twwdactivity2.html] I get an
> AccessControlException in the server log when trying to create a DB (via
> CONNECT 'jdbc:derby://localhost:1527/seconddb;create=true')
> This is with derby 10.15.2.0 but the same is observed in 10.14
> OS version: Ubuntu 21.04
> Java version:
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment (build 11.0.11+9-Ubuntu-0ubuntu2)
> OpenJDK 64-Bit Server VM (build 11.0.11+9-Ubuntu-0ubuntu2, mixed mode)
> but OpenJDK 16 and 17(early access) have the same problem
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DERBY-7110) Make it possible to build and test Derby cleanly with OpenJDK 17
[ https://issues.apache.org/jira/browse/DERBY-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17370646#comment-17370646 ] Bryan Pendleton commented on DERBY-7110: This Java 17 change certainly seems to be running under the radar. I haven't seen any other discussions of this in the various Internet communities I participate in. Is it possible that Derby were the only Java community that had adopted the Java Security Manager? Rick, do you think we should open any sort of discussion of this on the derby-users list, would there be any benefit to that? > Make it possible to build and test Derby cleanly with OpenJDK 17 > > > Key: DERBY-7110 > URL: https://issues.apache.org/jira/browse/DERBY-7110 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.16.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7110-01-aa-removeAngleBrackets.diff, > derby-7110-02-aa-suppressWarnings.diff, > derby-7110-03-aa-forkAntJavaTask.diff, derby-7110-03-ab-forkAntJavaTask.diff > > > Releases of Open JDK 17 can be found at https://jdk.java.net/17/. We should > adjust Derby as necessary so that it builds cleanly (including javadoc) and > tests cleanly with this version of the platform. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-6656) Re-enable views as the source data sets of MERGE statements
[ https://issues.apache.org/jira/browse/DERBY-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17366681#comment-17366681 ] Bryan Pendleton commented on DERBY-6656: We'd love to have more developers contributing to Derby! Here's a great place to start learning about the details: [https://cwiki.apache.org/confluence/display/DERBY/DerbyDev] Note that the lovely thing about working on Derby is that it's an old, mature, and stable codebase. However, also note that the challenging thing about working on Derby is that it's an old, mature, and stable codebase. > Re-enable views as the source data sets of MERGE statements > --- > > Key: DERBY-6656 > URL: https://issues.apache.org/jira/browse/DERBY-6656 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.11.1.1 >Reporter: Richard N. Hillegas >Priority: Major > > The SQL Standard allows views as the source data sets of MERGE statements. > However, we disabled this feature because of namespace resolution problems > (see DERBY-6652). Namespace resolution for the MERGE statement needs to be > overhauled. Some of the issues are described on DERBY-3155. When the > namespace problems are fixed comprehensively, we may be able to allow the use > of synonyms and subqueries and perhaps, also, the use of correlation names > for columns. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7110) Make it possible to build and test Derby cleanly with OpenJDK 17
[ https://issues.apache.org/jira/browse/DERBY-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363823#comment-17363823 ] Bryan Pendleton commented on DERBY-7110: Thanks for the pointer to JEP411 – I wasn't aware of that. In a quick scan of that document, I didn't understand: Derby uses the Security Manager to allow a user to confidently state a rule such as: "I am authorizing this DBMS server to read and write filesystem files in this directory and its child subdirectories only". We (kinda) document how to state these rules here: [http://db.apache.org/derby/docs/10.15/security/rsecbasicengine.html] In the future, how will a Derby deployment control where the Derby engine is allowed to put files? > Make it possible to build and test Derby cleanly with OpenJDK 17 > > > Key: DERBY-7110 > URL: https://issues.apache.org/jira/browse/DERBY-7110 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.16.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7110-01-aa-removeAngleBrackets.diff > > > Releases of Open JDK 17 can be found at https://jdk.java.net/17/. We should > adjust Derby as necessary so that it builds cleanly (including javadoc) and > tests cleanly with this version of the platform. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7116) Meta-data for unknown could not be accessed to read
[
https://issues.apache.org/jira/browse/DERBY-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343258#comment-17343258
]
Bryan Pendleton commented on DERBY-7116:
[Lots of good ideas
here|https://superuser.com/questions/117902/find-out-which-process-is-locking-a-file-or-folder-in-windows],
but they all seem to require (a) being able to reproduce the problem on
demand, and (b) being able to run an interactive tool to examine the running
system to track down the contention.
Sigh.
> Meta-data for unknown could not be accessed to read
> ---
>
> Key: DERBY-7116
> URL: https://issues.apache.org/jira/browse/DERBY-7116
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
>Affects Versions: 10.14.2.0
> Environment: Windows 10
>Reporter: Sam Hutchins
>Priority: Major
>
> Hi,
>
> I'm afraid I don't have a reproducible case for this, but it's an issue we've
> seen in the wild on customer's machines. I'd guess it's specific to Windows,
> as other platforms don't support exclusive locks, and we've only ever seen it
> reported from Windows users.
>
> The `ConcurrentCache` in the stacktrace makes me wonder if Derby is able to
> lock itself out of the database under the right conditions. Here's the trace:
>
> {code:java}
> Caused by: java.sql.SQLException: Meta-data for unknown could not be accessed
> to read
> C:\Users\USER\.ScreamingFrogSEOSpider\ProjectInstanceData\6b422f28-46c9-492e-bbde-aeb5bc1e6307\results_10505723-008c-4b06-aa69-2c676ef858c8\sql\seg0\c71.dat
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java)
> at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java)
> at
> org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java)
> at
> org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(EmbedPreparedStatement.java)
> at
> uk.co.screamingfrog.seospider.db.AbstractDuplicateTableOperations.getSpiderUrls(AbstractDuplicateTableOperations.java:152)
> ... 17 more
> Caused by: ERROR XSDG3: Meta-data for unknown could not be accessed to read
> C:\Users\USER\.ScreamingFrogSEOSpider\ProjectInstanceData\6b422f28-46c9-492e-bbde-aeb5bc1e6307\results_10505723-008c-4b06-aa69-2c676ef858c8\sql\seg0\c71.dat
> at
> org.apache.derby.iapi.error.StandardException.newException(StandardException.java)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory.java)
> ... 28 more
> Caused by: java.io.FileNotFoundException:
> C:\Users\USER\.ScreamingFrogSEOSpider\ProjectInstanceData\6b422f28-46c9-492e-bbde-aeb5bc1e6307\results_10505723-008c-4b06-aa69-2c676ef858c8\sql\seg0\c71.dat
> (The process cannot access the file because it is being used by another
> process)
> at java.base/java.io.RandomAccessFile.open0(Native Method)
> at java.base/java.io.RandomAccessFile.open(Unknown Source)
> at java.base/java.io.RandomAccessFile.(Unknown Source)
> at java.base/java.io.RandomAccessFile.(Unknown Source)
> at
> org.apache.derby.impl.io.DirRandomAccessFile.(DirRandomAccessFile.java)
> at org.apache.derby.impl.io.DirFile.getRandomAccessFile(DirFile.java)
> at
> org.apache.derby.impl.store.raw.data.RAFContainer.run(RAFContainer.java)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.derby.impl.store.raw.data.RAFContainer.openContainer(RAFContainer.java)
> at
> org.apache.derby.impl.store.raw.data.RAFContainer4.openContainer(RAFContainer4.java)
> at
> org.apache.derby.impl.store.raw.data.FileContainer.setIdent(FileContainer.java)
> at
> org.apache.derby.impl.store.raw.data.FileContainer.setIdentity(FileContainer.java)
> at
> org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java)
> at
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(BaseDataFileFactory.java)
> at
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(BaseDataFileFactory.java)
> at
[jira] [Commented] (DERBY-7116) Meta-data for unknown could not be accessed to read
[
https://issues.apache.org/jira/browse/DERBY-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17342976#comment-17342976
]
Bryan Pendleton commented on DERBY-7116:
Hi Rick, I think that Sam's theory that the other accessor of the file is a
Security scanner or a Backup program or some other sort of utility software is
a pretty good theory.
But I don't know how to write Java software that coordinates with such other
system software cleanly.
> Meta-data for unknown could not be accessed to read
> ---
>
> Key: DERBY-7116
> URL: https://issues.apache.org/jira/browse/DERBY-7116
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
>Affects Versions: 10.14.2.0
> Environment: Windows 10
>Reporter: Sam Hutchins
>Priority: Major
>
> Hi,
>
> I'm afraid I don't have a reproducible case for this, but it's an issue we've
> seen in the wild on customer's machines. I'd guess it's specific to Windows,
> as other platforms don't support exclusive locks, and we've only ever seen it
> reported from Windows users.
>
> The `ConcurrentCache` in the stacktrace makes me wonder if Derby is able to
> lock itself out of the database under the right conditions. Here's the trace:
>
> {code:java}
> Caused by: java.sql.SQLException: Meta-data for unknown could not be accessed
> to read
> C:\Users\USER\.ScreamingFrogSEOSpider\ProjectInstanceData\6b422f28-46c9-492e-bbde-aeb5bc1e6307\results_10505723-008c-4b06-aa69-2c676ef858c8\sql\seg0\c71.dat
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java)
> at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java)
> at
> org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java)
> at
> org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(EmbedPreparedStatement.java)
> at
> uk.co.screamingfrog.seospider.db.AbstractDuplicateTableOperations.getSpiderUrls(AbstractDuplicateTableOperations.java:152)
> ... 17 more
> Caused by: ERROR XSDG3: Meta-data for unknown could not be accessed to read
> C:\Users\USER\.ScreamingFrogSEOSpider\ProjectInstanceData\6b422f28-46c9-492e-bbde-aeb5bc1e6307\results_10505723-008c-4b06-aa69-2c676ef858c8\sql\seg0\c71.dat
> at
> org.apache.derby.iapi.error.StandardException.newException(StandardException.java)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory.java)
> ... 28 more
> Caused by: java.io.FileNotFoundException:
> C:\Users\USER\.ScreamingFrogSEOSpider\ProjectInstanceData\6b422f28-46c9-492e-bbde-aeb5bc1e6307\results_10505723-008c-4b06-aa69-2c676ef858c8\sql\seg0\c71.dat
> (The process cannot access the file because it is being used by another
> process)
> at java.base/java.io.RandomAccessFile.open0(Native Method)
> at java.base/java.io.RandomAccessFile.open(Unknown Source)
> at java.base/java.io.RandomAccessFile.(Unknown Source)
> at java.base/java.io.RandomAccessFile.(Unknown Source)
> at
> org.apache.derby.impl.io.DirRandomAccessFile.(DirRandomAccessFile.java)
> at org.apache.derby.impl.io.DirFile.getRandomAccessFile(DirFile.java)
> at
> org.apache.derby.impl.store.raw.data.RAFContainer.run(RAFContainer.java)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.derby.impl.store.raw.data.RAFContainer.openContainer(RAFContainer.java)
> at
> org.apache.derby.impl.store.raw.data.RAFContainer4.openContainer(RAFContainer4.java)
> at
> org.apache.derby.impl.store.raw.data.FileContainer.setIdent(FileContainer.java)
> at
> org.apache.derby.impl.store.raw.data.FileContainer.setIdentity(FileContainer.java)
> at
> org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java)
> at
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(BaseDataFileFactory.java)
> at
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(BaseDataFileFactory.java)
> at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java)
> at
>
[jira] [Commented] (DERBY-7115) Outdated documentation 'Getting Started'
[
https://issues.apache.org/jira/browse/DERBY-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338696#comment-17338696
]
Bryan Pendleton commented on DERBY-7115:
Old that guide is, but it's still widely used and is very heavily linked to
from other Internet sites (blogs, forums, etc.).
So thanks for continuing to work through the documentation and make this common
stumbling block less common in the future!
> Outdated documentation 'Getting Started'
>
>
> Key: DERBY-7115
> URL: https://issues.apache.org/jira/browse/DERBY-7115
> Project: Derby
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 10.15.2.0
>Reporter: Hiran Chaudhuri
>Priority: Minor
>
> I just tried to start a new project using the Derby embedded database. For my
> first steps I followed
> [https://db.apache.org/derby/docs/10.15/getstart/getstartderby.pdf.]
> According to the guide on page 31, I need to load
> String driver = "org.apache.derby.jdbc.EmbeddedDriver";
> although that class cannot be found on the classpath - and this despite I
> configured maven with
> {{ }}
> {{ org.apache.derby}}
> {{ derby}}
> {{ 10.15.2.0}}
> {{ }}
> When looking at derby-10.15.2.0.jar I find the file
> /META-INF.services/java.sql.Driver, and the content is
> {{org.apache.derby.iapi.jdbc.AutoloadedDriver}}
> Should that not be the driver name to be loaded for the tutorial? If not,
> where is the missing class?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DERBY-7111) Mention location of JDBC driver
[ https://issues.apache.org/jira/browse/DERBY-7111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17320582#comment-17320582 ] Bryan Pendleton commented on DERBY-7111: I agree that this is a common problem, and that it's often come up on StackOverflow, so trying to improve the Derby docs to make it easier to find the information seems valuable. So perhaps you could specify some of the various places in the Derby docs where you looked, and where you expected to find some documentation about this detail, but didn't find the information. It's sometimes hard to know where to put the doc to make it easily findable, and it would help if you could suggest some places that you looked for this information, but failed to find it. > Mention location of JDBC driver > --- > > Key: DERBY-7111 > URL: https://issues.apache.org/jira/browse/DERBY-7111 > Project: Derby > Issue Type: Improvement > Components: Documentation >Reporter: Leopold J >Priority: Minor > > I have read through several documentations but couldn't find out what JAR > file(s) contain the JDBC driver classes. Finally I found some help in > stackoverflow ([https://stackoverflow.com/a/11534013).] But it appears that > the JAR file with the driver has changed over a different version of Derby. > The documentation should make it clear and easy to find. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7108) Make derby graalvm friendly
[ https://issues.apache.org/jira/browse/DERBY-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305083#comment-17305083 ] Bryan Pendleton commented on DERBY-7108: In a query such as "SELECT LAST_NAME,MANAGER FROM EMPLOYEE WHERE FIRST_NAME = 'BRYAN'", the generated code implements behaviors such as * Project (extract just the LAST_NAME and MANAGER columns from the row) * Restrict (execute the comparison to check if the FIRST_NAME column equals "BRYAN") So we generally don't know these details until the query is actually just ready to be executed, since the SQL statements arrive dynamically over the JDBC connection, and the specific values in the restriction can be set via '?' parameters in PreparedStatements, etc. > Make derby graalvm friendly > --- > > Key: DERBY-7108 > URL: https://issues.apache.org/jira/browse/DERBY-7108 > Project: Derby > Issue Type: Task >Affects Versions: 10.16.0.0 >Reporter: Romain Manni-Bucau >Priority: Major > Attachments: outs.zip > > > Hi, > It would be neat to be able to use derby embedded with graalvm. > Some work started at [https://github.com/apache/geronimo-arthur/tree/openjpa] > (see [https://www.mail-archive.com/dev@geronimo.apache.org/msg97748.html)] > but I faced some weird issue about derby context. > Wonder how derby community considers graalvm (h2 for example explicitly said > it will never care about it and is happy with having broken graal support in > a minor version which is their choice but also means there is no point > integrating it since work can be to redo for each minor). > If you are interested I'm happy to collaborate if needed to try to make it > supported through arthur or native native-image configuration (can sit in the > derby jar to work OOTB too). > Side note: if it helps we can chat on asf slack. > Romain -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7107) NetworkServerControl fails to connect to server started on INADDR_ANY
[
https://issues.apache.org/jira/browse/DERBY-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305048#comment-17305048
]
Bryan Pendleton commented on DERBY-7107:
Can there be a variant of the patch that makes the new behavior enable-able,
but also keeps the current behavior as the default? So sites could select which
behavior was preferable for them?
> NetworkServerControl fails to connect to server started on INADDR_ANY
> -
>
> Key: DERBY-7107
> URL: https://issues.apache.org/jira/browse/DERBY-7107
> Project: Derby
> Issue Type: Bug
> Components: Network Server
>Affects Versions: 10.14.2.0, 10.15.2.0
>Reporter: Holger Rehn
>Priority: Critical
> Attachments: DERBY-7107.diff
>
>
> If starting a NetworkServerControl on INADDR_ANY (0.0.0.0) it also uses this
> address when connecting to the running server instance (e.g. in method
> ping(), ...).
> Strictly speaking, INADDR_ANY isn't a valid target address. However, under
> normal circumstances, this works anyway. But if you have any "security"
> software in place that blocks such connections (Firewall or VPN, e.g. Cisco
> AnyConnect), you end up with an IOException:
> {code}Could not connect to Derby Network Server on host 0.0.0.0, port 1527:
> Permission denied: connect.{code}
> One simple fix would be to explicitly check the host address 'hostAddress' in
> NetworkServerControlImpl.setUpSocket() and if this is INADDR_ANY, use
> 'localhost' instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DERBY-7108) Make derby graalvm friendly
[ https://issues.apache.org/jira/browse/DERBY-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305027#comment-17305027 ] Bryan Pendleton commented on DERBY-7108: Derby's code generation behavior has been a problem for other variant Java implementations in the past. For example, DERBY-4458 was a hard blocker for use of Derby with the "Dalvik" variant of Java. As far as I know, if this is the problem with "graalvm", then it may be a pretty big challenge, as Derby is quite dependent on being able to dynamically generate and subsequently execute bytecode. > Make derby graalvm friendly > --- > > Key: DERBY-7108 > URL: https://issues.apache.org/jira/browse/DERBY-7108 > Project: Derby > Issue Type: Task >Affects Versions: 10.16.0.0 >Reporter: Romain Manni-Bucau >Priority: Major > Attachments: outs.zip > > > Hi, > It would be neat to be able to use derby embedded with graalvm. > Some work started at [https://github.com/apache/geronimo-arthur/tree/openjpa] > (see [https://www.mail-archive.com/dev@geronimo.apache.org/msg97748.html)] > but I faced some weird issue about derby context. > Wonder how derby community considers graalvm (h2 for example explicitly said > it will never care about it and is happy with having broken graal support in > a minor version which is their choice but also means there is no point > integrating it since work can be to redo for each minor). > If you are interested I'm happy to collaborate if needed to try to make it > supported through arthur or native native-image configuration (can sit in the > derby jar to work OOTB too). > Side note: if it helps we can chat on asf slack. > Romain -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7107) NetworkServerControl fails to connect to server started on INADDR_ANY
[
https://issues.apache.org/jira/browse/DERBY-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17302814#comment-17302814
]
Bryan Pendleton commented on DERBY-7107:
Great! Can you contribute your patch, perhaps one of the committers can pick it
up and get it into the code base.
> NetworkServerControl fails to connect to server started on INADDR_ANY
> -
>
> Key: DERBY-7107
> URL: https://issues.apache.org/jira/browse/DERBY-7107
> Project: Derby
> Issue Type: Bug
> Components: Network Server
>Affects Versions: 10.14.2.0, 10.15.2.0
>Reporter: Holger Rehn
>Priority: Critical
>
> If starting a NetworkServerControl on INADDR_ANY (0.0.0.0) it also uses this
> address when connecting to the running server instance (e.g. in method
> ping(), ...).
> Strictly speaking, INADDR_ANY isn't a valid target address. However, under
> normal circumstances, this works anyway. But if you have any "security"
> software in place that blocks such connections (Firewall or VPN, e.g. Cisco
> AnyConnect), you end up with an IOException:
> {code}Could not connect to Derby Network Server on host 0.0.0.0, port 1527:
> Permission denied: connect.{code}
> One simple fix would be to explicitly check the host address 'hostAddress' in
> NetworkServerControlImpl.setUpSocket() and if this is INADDR_ANY, use
> 'localhost' instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DERBY-7107) NetworkServerControl fails to connect to server started on INADDR_ANY
[
https://issues.apache.org/jira/browse/DERBY-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17302569#comment-17302569
]
Bryan Pendleton commented on DERBY-7107:
Oh, I see, I misunderstood. You're not suggesting that it should be wrong to
start the Network Server on 0.0.0.0; you're suggesting that the ping command
should be smart enough to know to avoid trying to connect to 0.0.0.0.
It's an interesting idea. We've certainly had lots of problems with the
loopback ping before. I think the ping command is really designed to test a
client-to-server connection, not to have the server looping back to itself.
See Derby-6853 for an example of a similar suggestion.
I guess I'd see this Jira as more of an enhancement request than a bug report,
though?
> NetworkServerControl fails to connect to server started on INADDR_ANY
> -
>
> Key: DERBY-7107
> URL: https://issues.apache.org/jira/browse/DERBY-7107
> Project: Derby
> Issue Type: Bug
> Components: Network Server
>Affects Versions: 10.14.2.0, 10.15.2.0
>Reporter: Holger Rehn
>Priority: Critical
>
> If starting a NetworkServerControl on INADDR_ANY (0.0.0.0) it also uses this
> address when connecting to the running server instance (e.g. in method
> ping(), ...).
> Strictly speaking, INADDR_ANY isn't a valid target address. However, under
> normal circumstances, this works anyway. But if you have any "security"
> software in place that blocks such connections (Firewall or VPN, e.g. Cisco
> AnyConnect), you end up with an IOException:
> {code}Could not connect to Derby Network Server on host 0.0.0.0, port 1527:
> Permission denied: connect.{code}
> One simple fix would be to explicitly check the host address 'hostAddress' in
> NetworkServerControlImpl.setUpSocket() and if this is INADDR_ANY, use
> 'localhost' instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (DERBY-7107) NetworkServerControl fails to connect to server started on INADDR_ANY
[
https://issues.apache.org/jira/browse/DERBY-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17302560#comment-17302560
]
Bryan Pendleton edited comment on DERBY-7107 at 3/16/21, 2:14 PM:
--
INADDR_ANY means the socket will be bound to all local interfaces.
See: [https://man7.org/linux/man-pages/man7/ip.7.html]
Why do you think this behavior is a bug?
It seems to me that if you have security software which is blocking this, you
should simply specify an explicit interface on which to listen.
was (Author: bpendleton):
INADDR_ANY means the socket will be bound to all local interfaces.
See: [https://man7.org/linux/man-pages/man7/ip.7.html]
Why do you think this behavior is a bug?
> NetworkServerControl fails to connect to server started on INADDR_ANY
> -
>
> Key: DERBY-7107
> URL: https://issues.apache.org/jira/browse/DERBY-7107
> Project: Derby
> Issue Type: Bug
> Components: Network Server
>Affects Versions: 10.14.2.0, 10.15.2.0
>Reporter: Holger Rehn
>Priority: Critical
>
> If starting a NetworkServerControl on INADDR_ANY (0.0.0.0) it also uses this
> address when connecting to the running server instance (e.g. in method
> ping(), ...).
> Strictly speaking, INADDR_ANY isn't a valid target address. However, under
> normal circumstances, this works anyway. But if you have any "security"
> software in place that blocks such connections (Firewall or VPN, e.g. Cisco
> AnyConnect), you end up with an IOException:
> {code}Could not connect to Derby Network Server on host 0.0.0.0, port 1527:
> Permission denied: connect.{code}
> One simple fix would be to explicitly check the host address 'hostAddress' in
> NetworkServerControlImpl.setUpSocket() and if this is INADDR_ANY, use
> 'localhost' instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (DERBY-7107) NetworkServerControl fails to connect to server started on INADDR_ANY
[
https://issues.apache.org/jira/browse/DERBY-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17302560#comment-17302560
]
Bryan Pendleton edited comment on DERBY-7107 at 3/16/21, 2:13 PM:
--
INADDR_ANY means the socket will be bound to all local interfaces.
See: [https://man7.org/linux/man-pages/man7/ip.7.html]
Why do you think this behavior is a bug?
was (Author: bpendleton):
INADDR_ANY means the socket will be bound to all local interfaces.
See: https://man7.org/linux/man-pages/man7/ip.7.html
> NetworkServerControl fails to connect to server started on INADDR_ANY
> -
>
> Key: DERBY-7107
> URL: https://issues.apache.org/jira/browse/DERBY-7107
> Project: Derby
> Issue Type: Bug
> Components: Network Server
>Affects Versions: 10.14.2.0, 10.15.2.0
>Reporter: Holger Rehn
>Priority: Critical
>
> If starting a NetworkServerControl on INADDR_ANY (0.0.0.0) it also uses this
> address when connecting to the running server instance (e.g. in method
> ping(), ...).
> Strictly speaking, INADDR_ANY isn't a valid target address. However, under
> normal circumstances, this works anyway. But if you have any "security"
> software in place that blocks such connections (Firewall or VPN, e.g. Cisco
> AnyConnect), you end up with an IOException:
> {code}Could not connect to Derby Network Server on host 0.0.0.0, port 1527:
> Permission denied: connect.{code}
> One simple fix would be to explicitly check the host address 'hostAddress' in
> NetworkServerControlImpl.setUpSocket() and if this is INADDR_ANY, use
> 'localhost' instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DERBY-7107) NetworkServerControl fails to connect to server started on INADDR_ANY
[
https://issues.apache.org/jira/browse/DERBY-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17302560#comment-17302560
]
Bryan Pendleton commented on DERBY-7107:
INADDR_ANY means the socket will be bound to all local interfaces.
See: https://man7.org/linux/man-pages/man7/ip.7.html
> NetworkServerControl fails to connect to server started on INADDR_ANY
> -
>
> Key: DERBY-7107
> URL: https://issues.apache.org/jira/browse/DERBY-7107
> Project: Derby
> Issue Type: Bug
> Components: Network Server
>Affects Versions: 10.14.2.0, 10.15.2.0
>Reporter: Holger Rehn
>Priority: Critical
>
> If starting a NetworkServerControl on INADDR_ANY (0.0.0.0) it also uses this
> address when connecting to the running server instance (e.g. in method
> ping(), ...).
> Strictly speaking, INADDR_ANY isn't a valid target address. However, under
> normal circumstances, this works anyway. But if you have any "security"
> software in place that blocks such connections (Firewall or VPN, e.g. Cisco
> AnyConnect), you end up with an IOException:
> {code}Could not connect to Derby Network Server on host 0.0.0.0, port 1527:
> Permission denied: connect.{code}
> One simple fix would be to explicitly check the host address 'hostAddress' in
> NetworkServerControlImpl.setUpSocket() and if this is INADDR_ANY, use
> 'localhost' instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DERBY-7098) Derby issues an ERROR java.sql.SQLException: ResultSet not open. Operation 'next' not permitted. Verify that autocommit is off
[
https://issues.apache.org/jira/browse/DERBY-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17278900#comment-17278900
]
Bryan Pendleton commented on DERBY-7098:
Thanks for the followup, Ed, much appreciated! Maybe as you get farther, you
could join the derby-user mailing list and share some of your other experiences
with developing your app using Derby.
> Derby issues an ERROR java.sql.SQLException: ResultSet not open. Operation
> 'next' not permitted. Verify that autocommit is off
>
>
> Key: DERBY-7098
> URL: https://issues.apache.org/jira/browse/DERBY-7098
> Project: Derby
> Issue Type: Bug
>Affects Versions: 10.14.2.0
> Environment: NetBeans IDE 12.0
> GLASSFISH
> Java: 1.8.0_265; OpenJDK 64-Bit Server VM 25.265-b01
> Runtime: OpenJDK Runtime Environment 1.8.0_265-b01
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb)
>Reporter: Ed lang
>Priority: Major
> Fix For: 10.14.2.0
>
>
> While running queries derby issues: java.sql.SQLException: ResultSet not
> open. Operation 'next' not permitted. Verify that autocommit is off
>
> This error appears to be unfounded.
> The process it is in has run about 15 queries prior to this. Each Prepared
> statement and result set is closed after use.
>
> Here are particulars:
> *Manifest-Version: 1.0*
> Ant-Version: Apache Ant 1.9.5
> Created-By: 1.8.0_151-b12 (Oracle Corporation)
> Bundle-Vendor: Apache Software Foundation
> Bundle-Name: Apache Derby 10.14
> Bundle-Version: 10.14.200.1828579
> Bundle-ManifestVersion: 2
> Sealed: true
> Bundle-Activator: org.apache.derby.osgi.EmbeddedActivator
> Bundle-SymbolicName: derby
> DynamicImport-Package: *
> Export-Package: org.apache.derby.authentication,org.apache.derby.datab
> ase,org.apache.derby.io,org.apache.derby.jdbc,org.apache.derby.vti
> Class-Path: derbyLocale_cs.jar derbyLocale_de_DE.jar derbyLocale_es.ja
> r derbyLocale_fr.jar derbyLocale_hu.jar derbyLocale_it.jar derbyLocal
> e_ja_JP.jar derbyLocale_ko_KR.jar derbyLocale_pl.jar derbyLocale_pt_B
> R.jar derbyLocale_ru.jar derbyLocale_zh_CN.jar derbyLocale_zh_TW.jar
> Name: org/apache/derby/impl/tools/sysinfo/
> Sealed: false
> Name: org/apache/derby/iapi/services/context/
> Sealed: false
> Name: org/apache/derby/iapi/services/info/
> Sealed: false
> Name: org/apache/derby/jdbc/
> Sealed: false
> Name: org/apache/derby/info/
> Sealed: false
> Name: org/apache/derby/iapi/services/i18n/
> Sealed: false
> Name: org/apache/derby/shared/common/error/
> Sealed: false
> Name: org/apache/derby/shared/common/sanity/
> Sealed: false
> Name: org/apache/derby/iapi/tools/i18n/
> Sealed: false
> Name: org/apache/derby/loc/
> Sealed: false
> Name: org/apache/derby/tools/
> Sealed: false
>
> *At Server Level:*
> DP - database.Dictionary : USER : Derby Started at Address:
> localhost/127.0.0.1 Port: 1527|#]
> DP - database.Dictionary : USER PROPERTIES :
> \{derby.drda.traceDirectory=E:\opt\avnoc\JAVADB, derby.drda.maxThreads=0,
> derby.drda.sslMode=off, derby.drda.keepAlive=true, derby.drda.minThreads=0,
> derby.drda.portNumber=1527, derby.drda.logConnections=false,
> derby.drda.timeSlice=0, derby.drda.startNetworkServer=false,
> derby.drda.host=localhost, derby.drda.traceAll=true}|#]
> DP - database.Dictionary : USER runTimeInfo : --- Derby Network Server
> Runtime Information ---
> -- Session Information - Session Information
> ---Session #
> :9-# Connection
> Threads : 1# Active Sessions : 1# Waiting Sessions : 0Total Memory :
> 257425408 Free Memory : 255180496|#]
>
> *At query level:*
> autocommit: false warnings: null FreeMemory: 100835432|#]
>
> *The Code:*
>
> System.out.println("autocommit: " + this.conn.getAutoCommit() + " warnings: "
> + this.conn.getWarnings() + " FreeMemory: " +
> Runtime.getRuntime().freeMemory());
>
> RUNTIME: autocommit: false warnings: null FreeMemory: 100835432|#]
>
> PreparedStatement psNHG2 = this.conn.prepareStatement("select * from ASSETS
> where ID = ? and NAGNOTIFICATIONENABLED = '1' order by ASTSEQ");
> psNHG2.setString(1, this.custid);
> ResultSet rsNHG2 = psNHG2.executeQuery();
> while (rsNHG2.next()) {
>
> I noticed in 2011 there was a similar issue but considered it to be
> irrevelent as so many versions have transpired.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DERBY-7093) Download Link for 10.15.2.0 is broken
[
https://issues.apache.org/jira/browse/DERBY-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241840#comment-17241840
]
Bryan Pendleton commented on DERBY-7093:
Much appreciated! You have your holiday karma boost already!
> Download Link for 10.15.2.0 is broken
> -
>
> Key: DERBY-7093
> URL: https://issues.apache.org/jira/browse/DERBY-7093
> Project: Derby
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 10.15.2.0
>Reporter: Kevin Young
>Priority: Minor
> Attachments: derby-7093-01-aa-renameCGIscriptsAndDownloadPages.diff
>
>
> The link to download 10.15.2.0 from this page
> [https://db.apache.org/derby/derby_downloads.html
> |https://db.apache.org/derby/derby_downloads.html] incorrectly brings the
> user to
> [https://db.apache.org/derby/releases/release-10.15.2.0.{color:#FF}cgi{color}]{color:#FF}
> i{color}nstead of
> [https://db.apache.org/derby/releases/release-10.15.2.0.html] additionally
> when the user forces the page to the html site, the download links for the
> binaries bring the user to this broken link
> https://db.apache.org/derby/releases/{color:#FF}[preferred]{color}/db/derby/db-derby-10.15.2.0/db-derby-10.15.2.0-bin.zip
>
> if someone points me to where this is all set, i could attempt to fix it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DERBY-7093) Download Link for 10.15.2.0 is broken
[
https://issues.apache.org/jira/browse/DERBY-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241807#comment-17241807
]
Bryan Pendleton commented on DERBY-7093:
Well, that's a bit unfortunate. One of the original principles of the web is to
try to avoid changing URLs that are already widely known
[https://www.w3.org/Provider/Style/URI]
But, I suspect we are at the mercy of the mysterious "security enhancements".
Bummer.
Thanks for pushing at this rock, Rick.
> Download Link for 10.15.2.0 is broken
> -
>
> Key: DERBY-7093
> URL: https://issues.apache.org/jira/browse/DERBY-7093
> Project: Derby
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 10.15.2.0
>Reporter: Kevin Young
>Priority: Minor
>
> The link to download 10.15.2.0 from this page
> [https://db.apache.org/derby/derby_downloads.html
> |https://db.apache.org/derby/derby_downloads.html] incorrectly brings the
> user to
> [https://db.apache.org/derby/releases/release-10.15.2.0.{color:#FF}cgi{color}]{color:#FF}
> i{color}nstead of
> [https://db.apache.org/derby/releases/release-10.15.2.0.html] additionally
> when the user forces the page to the html site, the download links for the
> binaries bring the user to this broken link
> https://db.apache.org/derby/releases/{color:#FF}[preferred]{color}/db/derby/db-derby-10.15.2.0/db-derby-10.15.2.0-bin.zip
>
> if someone points me to where this is all set, i could attempt to fix it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DERBY-7093) Download Link for 10.15.2.0 is broken
[
https://issues.apache.org/jira/browse/DERBY-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17237696#comment-17237696
]
Bryan Pendleton commented on DERBY-7093:
What little I understand about this part of the release distribution process is
documented here:
* [https://cwiki.apache.org/confluence/display/DERBY/ReleasePublication]
* https://issues.apache.org/jira/browse/DERBY-6875
> Download Link for 10.15.2.0 is broken
> -
>
> Key: DERBY-7093
> URL: https://issues.apache.org/jira/browse/DERBY-7093
> Project: Derby
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 10.15.2.0
>Reporter: Kevin Young
>Priority: Minor
>
> The link to download 10.15.2.0 from this page
> [https://db.apache.org/derby/derby_downloads.html
> |https://db.apache.org/derby/derby_downloads.html] incorrectly brings the
> user to
> [https://db.apache.org/derby/releases/release-10.15.2.0.{color:#FF}cgi{color}]{color:#FF}
> i{color}nstead of
> [https://db.apache.org/derby/releases/release-10.15.2.0.html] additionally
> when the user forces the page to the html site, the download links for the
> binaries bring the user to this broken link
> https://db.apache.org/derby/releases/{color:#FF}[preferred]{color}/db/derby/db-derby-10.15.2.0/db-derby-10.15.2.0-bin.zip
>
> if someone points me to where this is all set, i could attempt to fix it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DERBY-7091) Times Inserted Incorrectly Around Daylight Savings Time Change in Spring
[ https://issues.apache.org/jira/browse/DERBY-7091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17232159#comment-17232159 ] Bryan Pendleton commented on DERBY-7091: Can you attach a simple program that demonstrates the behavior? Start with the CREATE TABLE statement, then show a variety of INSERT statements with different values, then show the code that fetches the values back, etc. > Times Inserted Incorrectly Around Daylight Savings Time Change in Spring > > > Key: DERBY-7091 > URL: https://issues.apache.org/jira/browse/DERBY-7091 > Project: Derby > Issue Type: Bug >Affects Versions: 10.14.2.0 > Environment: Java 14.0.1 >Reporter: Larry Melvin Lemons >Priority: Critical > Attachments: Timezone_Data_Inconsistencies.odt > > > When inserting date/times into the timestamp field around the daylight > savings time change in the Spring, the times are inconsistent. I am in/use > the New York EST/EDT timezone, but the data I am inserting is Standard time > and not Daylight Savings Time > All the times are correct up to 1:48AM, then when it inserts 2:00 AM the data > in the database is 3:00AM. That could be alright if it kept switching the > time to Daylight Savings Time, however going from inserting 2:48AM and > getting 3:48AM in the database, when it inserts 3:00AM it shows 3:00AM in the > database, not the expected 4:00AM. Then in the fall whatever is inserted in > the database is what shows in the database around the daylight savings time > switch to standard time. See the attached Open Document Text file for > examples of what is actually inserted and what is showing in the database. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7088) Make it possible to build and test Derby using JDK 16
[ https://issues.apache.org/jira/browse/DERBY-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219155#comment-17219155 ] Bryan Pendleton commented on DERBY-7088: Thanks Rick! Java is now older than Derby, and almost as old as my granddaughter! But I think Java is cheating, it seems to be aging by two every year... > Make it possible to build and test Derby using JDK 16 > - > > Key: DERBY-7088 > URL: https://issues.apache.org/jira/browse/DERBY-7088 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.16.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > > Make sure that Derby builds and tests cleanly with JDK 16, starting with the > early access versions. This issue should be kept open until JDK 16 goes GA. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-6998) Make it possible to build Derby cleanly using JDK 10
[
https://issues.apache.org/jira/browse/DERBY-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17217183#comment-17217183
]
Bryan Pendleton commented on DERBY-6998:
Your suggestion seems fine to me!
> Make it possible to build Derby cleanly using JDK 10
>
>
> Key: DERBY-6998
> URL: https://issues.apache.org/jira/browse/DERBY-6998
> Project: Derby
> Issue Type: Bug
> Components: Build tools
>Affects Versions: 10.15.1.3
>Reporter: Richard N. Hillegas
>Priority: Major
> Attachments: derby-6998-01-ab-tightenReturnType.diff,
> derby-6998-02-aa-supportForJDK11.diff,
> derby-6998-03-aa-reenableEncryptionTestsOnJDK11.diff,
> derby-6998-04-aa-increaseCertificateLifetime.diff,
> derby-6998-05-aa-use-java.specification.version.diff,
> derby-6998-05-ab-use-java.specification.version.diff, sslHandshake.tar
>
>
> When I build Derby using JDK 10, I get the following warning:
> {noformat}
> [javac]
> /Users/rhillegas/derby/mainline/trunk/java/engine/org/apache/derby/iapi/types/SqlXmlUtil.java:728:
> warning: [unchecked] getPrefixes(String) in NullNamespaceContext implements
> getPrefixes(String) in NamespaceContext
> [javac] public Iterator getPrefixes(String namespaceURI) {
> [javac] ^
> [javac] return type requires unchecked conversion from Iterator to
> Iterator
> [javac] 1 warning
> {noformat}
> I will clean this up.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DERBY-7084) Identity column data import does not increment generator
[ https://issues.apache.org/jira/browse/DERBY-7084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17153737#comment-17153737 ] Bryan Pendleton commented on DERBY-7084: As a workaround, you can use ALTER TABLE ... RESTART WITH ... to set the generator to the desired value after you import the data. [https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/ref/rrefsqlj81859.html] > Identity column data import does not increment generator > > > Key: DERBY-7084 > URL: https://issues.apache.org/jira/browse/DERBY-7084 > Project: Derby > Issue Type: Bug >Reporter: Makkus B. >Priority: Major > > When importing table data containing identity column vales (defined as > GENERATED BY DEFAULT AS IDENTITY) via SYSCS_IMPORT_DATA (or > SYSCS_IMPORT_TABLE) the data will be imported (when identity column was > defined as GENERATED BY DEFAULT AS IDENTITY) , but the (internal) table index > generator will not be updated. If the column is further defined as UNIQUE (or > PRIMARY KEY) new data might not be added to the table (if the internal index > will match an imported one). > The expected behaviour would be that the internal index would always stay > ahead of identity values inserted to the table. This is: for a new table the > index defaults to 1. If data is imported to a new table, the index should not > stay at 1 but become 1+max(imported_index). So the table can be continued to > be used after the import. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7077) Erreurs page de documentation
[ https://issues.apache.org/jira/browse/DERBY-7077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17115372#comment-17115372 ] Bryan Pendleton commented on DERBY-7077: I think it's awkward that we have both [https://db.apache.org/derby/papers/DerbyTut/index.html] and [http://db.apache.org/derby/docs/10.15/getstart/] There is considerable overlap between the two sets of materials, but each have a bit of their own charms. Can we see a way forward that simplifies this, while still maintaining all the useful material in these documents? > Erreurs page de documentation > - > > Key: DERBY-7077 > URL: https://issues.apache.org/jira/browse/DERBY-7077 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.15.2.0 >Reporter: Vasile CIUMAC >Priority: Major > Attachments: image-2020-05-19-11-28-05-728.png, > image-2020-05-19-11-32-59-105.png > > > Bonjour, > J'ai identifié 2 erreurs dans la page de documentation: > [https://db.apache.org/derby/papers/DerbyTut/ns_intro.html#ns_intro] > > Il faut des backslash > !image-2020-05-19-11-28-05-728.png! > Manque le "point" avant la commande startNetworkServer: > !image-2020-05-19-11-32-59-105.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7074) Update the links to checksums and signatures on the 10.15.2.0 and 10.14.2.0 download pages
[ https://issues.apache.org/jira/browse/DERBY-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082676#comment-17082676 ] Bryan Pendleton commented on DERBY-7074: Thanks Rick! > Update the links to checksums and signatures on the 10.15.2.0 and 10.14.2.0 > download pages > -- > > Key: DERBY-7074 > URL: https://issues.apache.org/jira/browse/DERBY-7074 > Project: Derby > Issue Type: Task > Components: Web Site >Affects Versions: 10.14.2.0, 10.15.2.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7074-01-aa-updateChecksumLinks.diff > > > According to the Apache board, references to https://www.apache.org/dist/ > are deprecated and need to be replaced by references to > https://downloads.apache.org/. This affects the PGP, MD5, and SHA-512 links > in the mirroring stanzas of the 10.14.2.0 and 10.15.2.0 download pages. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7066) Tasks for releasing 10.15.2
[ https://issues.apache.org/jira/browse/DERBY-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042732#comment-17042732 ] Bryan Pendleton commented on DERBY-7066: Many thanks for getting the release out, Rick! > Tasks for releasing 10.15.2 > --- > > Key: DERBY-7066 > URL: https://issues.apache.org/jira/browse/DERBY-7066 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.15.2.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7066-01-aa-releaseNotes-firstRev.diff, > derby-7066-02-aa-releaseNotes-secondRev.diff, > derby-7066-03-aa-updateIndex.diff, derby-7066-04-aa-updateDocsCopyright.diff > > > Placeholder for activity related to producing a 10.15.2 release. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7065) repo1.maven.org, apparently, won't support http anymore
[
https://issues.apache.org/jira/browse/DERBY-7065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010329#comment-17010329
]
Bryan Pendleton commented on DERBY-7065:
Thank you! I will look at this over next weekend, unless somebody else gets to
it first.
> repo1.maven.org, apparently, won't support http anymore
>
>
> Key: DERBY-7065
> URL: https://issues.apache.org/jira/browse/DERBY-7065
> Project: Derby
> Issue Type: Improvement
> Components: Build tools
>Affects Versions: 10.15.1.3
>Reporter: Davide Grandi
>Priority: Major
> Attachments: repo1_protocol_update.diff
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> {{Sonatype Ops (@sonatype_ops) tweet}}
> {{ [https://twitter.com/sonatype_ops/status/1214235276006047744]}}
> {{state that}}
> {{ "Great progress, but still many users that need to update their}}
> {{ environments prior to the *January 15 HTTPS cutover date*"}}
> {{and referring to}}
> {{
> [https://central.sonatype.org/articles/2019/Apr/30/http-access-to-repo1mavenorg-and-repomavenapacheorg-is-being-deprecated/]}}
> {{ Main derby's build.xml download junit.jar from}}
> {{ value="_*[http://repo1.maven.org/maven2/junit/junit/3.8.2/junit-3.8.2.jar]*_"/>}}
> {{ This url should be, at least, prudently updated with "https" instead of
> "http".}}
> {{An "ant clobber + ant all + ant buildjars" sequence succeeds with https.}}
> Patch repo1_protocol_update.diff attached
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DERBY-6809) Java 1.8 feature use
[ https://issues.apache.org/jira/browse/DERBY-6809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17007710#comment-17007710 ] Bryan Pendleton commented on DERBY-6809: Glad to see you back, happy new year! Yes, the trunk branch is the correct one to use for developing new features > Java 1.8 feature use > > > Key: DERBY-6809 > URL: https://issues.apache.org/jira/browse/DERBY-6809 > Project: Derby > Issue Type: Improvement > Components: Network Server >Affects Versions: 11.0.0.0 >Reporter: sagar >Priority: Major > Attachments: 2017-12-04-143613_1366x768_scrot.png, latest.png > > > Suggestion ... > Is it possible to auto modify the existing source code using tools like > Netbeans, and take advantage of the new features in JDK 1.8 for better > multiuser performance and better utilization of current day multicore > processors? > Plainly put, can we have from 11.0 onwards a version of derby which takes > advantage of the advancements and new features in java 1.8 ... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (DERBY-7061) Fix web site links to old Derby wiki
[ https://issues.apache.org/jira/browse/DERBY-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton resolved DERBY-7061. Resolution: Fixed I think I found all the wiki links from the web site pages. Resolving. > Fix web site links to old Derby wiki > > > Key: DERBY-7061 > URL: https://issues.apache.org/jira/browse/DERBY-7061 > Project: Derby > Issue Type: Bug > Components: Web Site >Reporter: Bryan Pendleton >Assignee: Bryan Pendleton >Priority: Major > > The Derby wiki was migrated from MoinMoin to Confluence, and all the wiki > page links have changed. > We need to update the Derby website to point wiki links to the new Confluence > wiki. > > The change is, I think, quite mechanical -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7063) Cannot connect using squirrel 3.3.0
[ https://issues.apache.org/jira/browse/DERBY-7063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17006149#comment-17006149 ] Bryan Pendleton commented on DERBY-7063: If you are using the scripts to start the Network Server, then I don't think you need to manage the classpath manually. If you find that is not true, and classpath is still a problem even with the scripts, please let us know. > Cannot connect using squirrel 3.3.0 > --- > > Key: DERBY-7063 > URL: https://issues.apache.org/jira/browse/DERBY-7063 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Server >Affects Versions: 10.15.1.3 >Reporter: sagar >Priority: Major > > The derbyclient.jar file does not have the > org.apache.derby.jdbc.ClientDriver.class > > When I add the jar file in squirrel, ssquirrel automatically detects the > driver but since this class is missing it does not detect it. > Till now I was using 10.11.1.1 database. Now I have decided to upgrade and > this issue cropped up. > > Yes Derby has switched to the module system from 10.15.1.3 but the derby > documentation mentions connection to Network Server similar to previous as > using the > org.apache.derby.jdbc.ClientDriver and this class is missing from the new > derbyclient.jar. > > > Squirrel is running on Java 1.8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7063) Cannot connect using squirrel 3.3.0
[ https://issues.apache.org/jira/browse/DERBY-7063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17005327#comment-17005327 ] Bryan Pendleton commented on DERBY-7063: See : [https://stackoverflow.com/a/57221011/193453] Have you tried adding derbyshared.jar as an additional jar file in your Squirrel driver configuration? Where do you recommend we should document this new behavior? It is documented here: [http://db.apache.org/derby/releases/release-10.15.1.3.cgi] Note that if you are running Java 1.8, you can also consider just using Derby 10.14, rather than Derby 10.15. > Cannot connect using squirrel 3.3.0 > --- > > Key: DERBY-7063 > URL: https://issues.apache.org/jira/browse/DERBY-7063 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Server >Affects Versions: 10.15.1.3 >Reporter: sagar >Priority: Major > > The derbyclient.jar file does not have the > org.apache.derby.jdbc.ClientDriver.class > > When I add the jar file in squirrel, ssquirrel automatically detects the > driver but since this class is missing it does not detect it. > Till now I was using 10.11.1.1 database. Now I have decided to upgrade and > this issue cropped up. > > Yes Derby has switched to the module system from 10.15.1.3 but the derby > documentation mentions connection to Network Server similar to previous as > using the > org.apache.derby.jdbc.ClientDriver and this class is missing from the new > derbyclient.jar. > > > Squirrel is running on Java 1.8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7061) Fix web site links to old Derby wiki
[ https://issues.apache.org/jira/browse/DERBY-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004848#comment-17004848 ] Bryan Pendleton commented on DERBY-7061: Hi Rick, I made an attempt at updating the web site to correct the wiki links. Can you have a look at your convenience? > Fix web site links to old Derby wiki > > > Key: DERBY-7061 > URL: https://issues.apache.org/jira/browse/DERBY-7061 > Project: Derby > Issue Type: Bug > Components: Web Site >Reporter: Bryan Pendleton >Assignee: Bryan Pendleton >Priority: Major > > The Derby wiki was migrated from MoinMoin to Confluence, and all the wiki > page links have changed. > We need to update the Derby website to point wiki links to the new Confluence > wiki. > > The change is, I think, quite mechanical -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (DERBY-7061) Fix web site links to old Derby wiki
Bryan Pendleton created DERBY-7061: -- Summary: Fix web site links to old Derby wiki Key: DERBY-7061 URL: https://issues.apache.org/jira/browse/DERBY-7061 Project: Derby Issue Type: Bug Components: Web Site Reporter: Bryan Pendleton Assignee: Bryan Pendleton The Derby wiki was migrated from MoinMoin to Confluence, and all the wiki page links have changed. We need to update the Derby website to point wiki links to the new Confluence wiki. The change is, I think, quite mechanical -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7060) XSDG2 Invalid checksum on Page occurs in 10.6.1.0 version
[
https://issues.apache.org/jira/browse/DERBY-7060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003425#comment-17003425
]
Bryan Pendleton commented on DERBY-7060:
Thank you for the follow-up.
Please let us know, after you have had some time to write and run some tests,
what your results are, they will help others who may struggle with this issue
in the future.
> XSDG2 Invalid checksum on Page occurs in 10.6.1.0 version
> -
>
> Key: DERBY-7060
> URL: https://issues.apache.org/jira/browse/DERBY-7060
> Project: Derby
> Issue Type: Bug
> Components: Network Server
>Affects Versions: 10.6.1.0
> Environment: OS: Linux version 3.0.35.
> java version: Java 1.8.
> framework:Knopflerfish OSGi. equinox 3.5.2.
> Derby Server address: localhost.
>Reporter: motomi inoue
>Priority: Major
> Attachments: derby.log
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> Our products use Derby 10.6.1.0.
> Our products have experienced three similar symptoms to the known issue
> DERBY-3611.
> Once it occurs, then The [Cleanup action starting] log appears multiple
> times, but the phenomenon does not recover.
> We looked at the dump and found nothing wrong.
> It works fine after restarting Derby. with same data.
> The derby.log when an error occurs is as follows.
> (I omit the folder path and the contents of the dump.)
> Is this an issue that has already been fixed?
> If so, what version should I update to?
> --
> 2019-09-21 19:17:34.500 GMT : Apache Derby Network Server - 10.6.1.0 -
> (938214) started and ready to accept connections on port 1527
>
> 2019-09-21 19:17:35.391 GMT:
> Booting Derby version The Apache Software Foundation - Apache Derby -
> 10.6.1.0 - (938214): instance a816c00e-016d-5542-0890-4542b78a
> on database directory (Omit directory path.) with class loader
> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@10ad4ff[org.apache.derby.libraries:10.6.1.0(id=60)]
> Database Class Loader started - derby.database.classpath=''
> BEGIN SHUTDOWN ERROR STACK -
> ERROR XSDG2: Invalid checksum on Page Page(9,Container(0, 3280)),
> expected=1,738,070,319, on-disk version=1,221,251,861, page dump follows: Hex
> dump:
> (Omit the dump data.)
> at org.apache.derby.iapi.error.StandardException.newException(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.StoredPage.validateChecksum(Unknown
> Source)
> at org.apache.derby.impl.store.raw.data.StoredPage.initFromData(Unknown
> Source)
> at org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(Unknown
> Source)
> at org.apache.derby.impl.services.cache.ConcurrentCache.find(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.FileContainer.getUserPage(Unknown Source)
> at org.apache.derby.impl.store.raw.data.FileContainer.getPage(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.BaseContainerHandle.getPage(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.OverflowInputStream.fillByteHolder(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.BufferedByteHolderInputStream.read(Unknown
> Source)
> at java.io.DataInputStream.read(Unknown Source)
> at org.apache.derby.iapi.types.SQLClob.getStreamWithDescriptor(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedClob.(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedResultSet.getClob(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedResultSet.getObject(Unknown Source)
> at
> org.apache.derby.impl.drda.DRDAConnThread.getObjectForWriteFdoca(Unknown
> Source)
> at org.apache.derby.impl.drda.DRDAConnThread.writeFDODTA(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.writeQRYDTA(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown
> Source)
> at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
> END SHUTDOWN ERROR STACK -
> 2019-10-25 06:54:18.082 GMT Thread[DRDAConnThread_40,5,derby.daemons] (XID =
> 23029299), (SESSIONID = 10761), (DATABASE = mdm), (DRDAID =
> NF01.DA33-868348731172564756{5379}), Cleanup action starting
> 2019-10-25 06:54:18.083 GMT Thread[DRDAConnThread_40,5,derby.daemons] (XID =
> 23029299), (SESSIONID = 10761), (DATABASE = mdm), (DRDAID =
> NF01.DA33-868348731172564756{5379}), Failed Statement is: call
> SYSIBM.SQLCAMESSAGE(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
> java.lang.NullPointerException
> at
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown
> Source)
> at
>
[jira] [Commented] (DERBY-7060) XSDG2 Invalid checksum on Page occurs in 10.6.1.0 version
[ https://issues.apache.org/jira/browse/DERBY-7060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002397#comment-17002397 ] Bryan Pendleton commented on DERBY-7060: I am sorry you are having these problems. 10.6 is definitely quite an old release at this point, so it would certainly be worth investigating whether you can upgrade. However, I'm not sure that there have been many changes to this part of the system in a very long time. A good place for you to start would be if you could review the comments and discussion in DERBY-6425, which was a more recent issue and one that we never really got to the bottom of. There are some excellent suggestions and observations in the DERBY-6425 discussion threads that could give you some ideas about how to narrow down the problem and perhaps gather more details so that we can get to the bottom of it. Also, there are some suggestions about system configuration settings you can experiment with that could perhaps make the problem go away. > XSDG2 Invalid checksum on Page occurs in 10.6.1.0 version > - > > Key: DERBY-7060 > URL: https://issues.apache.org/jira/browse/DERBY-7060 > Project: Derby > Issue Type: Bug > Components: Network Server >Affects Versions: 10.6.1.0 > Environment: OS: Linux version 3.0.35. > java version: Java 1.8. > framework:Knopflerfish OSGi. equinox 3.5.2. > Derby Server address: localhost. >Reporter: motomi inoue >Priority: Major > Attachments: derby.log > > Original Estimate: 504h > Remaining Estimate: 504h > > Our products use Derby 10.6.1.0. > Our products have experienced three similar symptoms to the known issue > DERBY-3611. > Once it occurs, then The [Cleanup action starting] log appears multiple > times, but the phenomenon does not recover. > We looked at the dump and found nothing wrong. > It works fine after restarting Derby. with same data. > The derby.log when an error occurs is as follows. > (I omit the folder path and the contents of the dump.) > Is this an issue that has already been fixed? > If so, what version should I update to? > -- > 2019-09-21 19:17:34.500 GMT : Apache Derby Network Server - 10.6.1.0 - > (938214) started and ready to accept connections on port 1527 > > 2019-09-21 19:17:35.391 GMT: > Booting Derby version The Apache Software Foundation - Apache Derby - > 10.6.1.0 - (938214): instance a816c00e-016d-5542-0890-4542b78a > on database directory (Omit directory path.) with class loader > org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@10ad4ff[org.apache.derby.libraries:10.6.1.0(id=60)] > Database Class Loader started - derby.database.classpath='' > BEGIN SHUTDOWN ERROR STACK - > ERROR XSDG2: Invalid checksum on Page Page(9,Container(0, 3280)), > expected=1,738,070,319, on-disk version=1,221,251,861, page dump follows: Hex > dump: > (Omit the dump data.) > at org.apache.derby.iapi.error.StandardException.newException(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.StoredPage.validateChecksum(Unknown > Source) > at org.apache.derby.impl.store.raw.data.StoredPage.initFromData(Unknown > Source) > at org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(Unknown > Source) > at org.apache.derby.impl.services.cache.ConcurrentCache.find(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.FileContainer.getUserPage(Unknown Source) > at org.apache.derby.impl.store.raw.data.FileContainer.getPage(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.BaseContainerHandle.getPage(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.OverflowInputStream.fillByteHolder(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.BufferedByteHolderInputStream.read(Unknown > Source) > at java.io.DataInputStream.read(Unknown Source) > at org.apache.derby.iapi.types.SQLClob.getStreamWithDescriptor(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedClob.(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedResultSet.getClob(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedResultSet.getObject(Unknown Source) > at > org.apache.derby.impl.drda.DRDAConnThread.getObjectForWriteFdoca(Unknown > Source) > at org.apache.derby.impl.drda.DRDAConnThread.writeFDODTA(Unknown Source) > at org.apache.derby.impl.drda.DRDAConnThread.writeQRYDTA(Unknown Source) > at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown > Source) > at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source) > END SHUTDOWN ERROR STACK - > 2019-10-25 06:54:18.082 GMT
[jira] [Resolved] (DERBY-7054) Website references old email address
[ https://issues.apache.org/jira/browse/DERBY-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton resolved DERBY-7054. Resolution: Fixed The updated web page is live on the site, resolving. > Website references old email address > > > Key: DERBY-7054 > URL: https://issues.apache.org/jira/browse/DERBY-7054 > Project: Derby > Issue Type: Bug > Components: Web Site >Reporter: Sebb >Assignee: Bryan Pendleton >Priority: Major > Attachments: logo.html, logo.patch > > > The page https://db.apache.org/derby/logo.html references the prc@ mailing > list which was closed down many years ago (Mar 2010?). > Please update as necessary/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7054) Website references old email address
[ https://issues.apache.org/jira/browse/DERBY-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938152#comment-16938152 ] Bryan Pendleton commented on DERBY-7054: Hi Rick, can you have a quick check of the attached logo.patch and the formatted logo.html ? > Website references old email address > > > Key: DERBY-7054 > URL: https://issues.apache.org/jira/browse/DERBY-7054 > Project: Derby > Issue Type: Bug > Components: Web Site >Reporter: Sebb >Assignee: Bryan Pendleton >Priority: Major > Attachments: logo.html, logo.patch > > > The page https://db.apache.org/derby/logo.html references the prc@ mailing > list which was closed down many years ago (Mar 2010?). > Please update as necessary/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (DERBY-7054) Website references old email address
[ https://issues.apache.org/jira/browse/DERBY-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton updated DERBY-7054: --- Attachment: logo.html > Website references old email address > > > Key: DERBY-7054 > URL: https://issues.apache.org/jira/browse/DERBY-7054 > Project: Derby > Issue Type: Bug > Components: Web Site >Reporter: Sebb >Assignee: Bryan Pendleton >Priority: Major > Attachments: logo.html, logo.patch > > > The page https://db.apache.org/derby/logo.html references the prc@ mailing > list which was closed down many years ago (Mar 2010?). > Please update as necessary/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (DERBY-7054) Website references old email address
[ https://issues.apache.org/jira/browse/DERBY-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton reassigned DERBY-7054: -- Assignee: Bryan Pendleton > Website references old email address > > > Key: DERBY-7054 > URL: https://issues.apache.org/jira/browse/DERBY-7054 > Project: Derby > Issue Type: Bug > Components: Web Site >Reporter: Sebb >Assignee: Bryan Pendleton >Priority: Major > > The page https://db.apache.org/derby/logo.html references the prc@ mailing > list which was closed down many years ago (Mar 2010?). > Please update as necessary/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (DERBY-7054) Website references old email address
[ https://issues.apache.org/jira/browse/DERBY-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton updated DERBY-7054: --- Attachment: logo.patch > Website references old email address > > > Key: DERBY-7054 > URL: https://issues.apache.org/jira/browse/DERBY-7054 > Project: Derby > Issue Type: Bug > Components: Web Site >Reporter: Sebb >Assignee: Bryan Pendleton >Priority: Major > Attachments: logo.patch > > > The page https://db.apache.org/derby/logo.html references the prc@ mailing > list which was closed down many years ago (Mar 2010?). > Please update as necessary/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7054) Website references old email address
[ https://issues.apache.org/jira/browse/DERBY-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937724#comment-16937724 ] Bryan Pendleton commented on DERBY-7054: Or, better, as suggested by the current VP Brand, If you would like to use the Derby logo outside Apache – for example, for a t-shirt, poster, flier, or whatever – please check the guidance and resources provided by the Apache Brand Management Committee at https://www.apache.org/foundation/marks/ Rick, how does that sound? > Website references old email address > > > Key: DERBY-7054 > URL: https://issues.apache.org/jira/browse/DERBY-7054 > Project: Derby > Issue Type: Bug > Components: Web Site >Reporter: Sebb >Priority: Major > > The page https://db.apache.org/derby/logo.html references the prc@ mailing > list which was closed down many years ago (Mar 2010?). > Please update as necessary/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7054) Website references old email address
[ https://issues.apache.org/jira/browse/DERBY-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937379#comment-16937379 ] Bryan Pendleton commented on DERBY-7054: Perhaps the sentence should read: If you would like to use the Derby logo outside Apache -- for example, for a t-shirt, poster, flier, or whatever -- first obtain permission from the Apache Brand Management Committee by emailing your request to trademarks apache.org. > Website references old email address > > > Key: DERBY-7054 > URL: https://issues.apache.org/jira/browse/DERBY-7054 > Project: Derby > Issue Type: Bug > Components: Web Site >Reporter: Sebb >Priority: Major > > The page https://db.apache.org/derby/logo.html references the prc@ mailing > list which was closed down many years ago (Mar 2010?). > Please update as necessary/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7049) OutOfMemoryError: Compressed class space
[
https://issues.apache.org/jira/browse/DERBY-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16891496#comment-16891496
]
Bryan Pendleton commented on DERBY-7049:
If you specify `-XX:+HeapDumpOnOutOfMemoryError` then your program might
produce a heap dump when it runs out of memory, and you might be able to run
`mat` to analyse the dump and see where the memory is going and what is
referring to it.
> OutOfMemoryError: Compressed class space
>
>
> Key: DERBY-7049
> URL: https://issues.apache.org/jira/browse/DERBY-7049
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.13.1.1
>Reporter: Marco
>Priority: Major
>
> After a few days of working with an embedded Derby database (currently
> version 10.13.1.1 on Oracle Java 1.8.0_201-b09), the following error occurs:
> *java.lang.OutOfMemoryError: Compressed class space*
> {code:java}
> java.lang.OutOfMemoryError: Compressed class space
> at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
> at
> org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement42.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.jdbc.Driver42.newEmbedPreparedStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.datanucleus.store.rdbms.datasource.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:259)
> ~[datanucleus-rdbms-4.0.12.jar:na]{code}
> I tried to solve the problem by periodically shutting down the database,
> because I read that the generated classes as well as all other allocated
> resources should be released when the DB is shut-down.
> I thus perform the following code once per roughly 20 minutes:
> {code:java}
> String shutdownConnectionURL = connectionURL + ";shutdown=true";
> try {
> DriverManager.getConnection(shutdownConnectionURL);
> } catch (SQLException e) {
> int errorCode = e.getErrorCode();
> if (DERBY_ERROR_CODE_SHUTDOWN_DATABASE_SUCCESSFULLY != errorCode &&
> DERBY_ERROR_CODE_SHUTDOWN_DATABASE_WAS_NOT_RUNNING != errorCode) {
> throw new RuntimeException(e);
> }
> }
> {code}
> Unfortunately, this has no effect :( The OutOfMemoryError still occurs after
> about 2 days. Do I assume correctly that the above code _should_ properly
> shut-down the database? And do I assume correctly that this shut-down should
> release the generated classes?
> IMHO, it is already a bug in Derby that I need to shut-down the database at
> all in order to prevent it from piling up generated classes. Shouldn't it
> already release the generated classes at the end of each transaction? But
> even if I really have to shut-down the DB, it is certainly a bug that the
> classes are still kept in "compressed class space" even after the shut-down.
> I searched the release notes and the existing bugs (here in JIRA) and did not
> find anything related to this {{OutOfMemoryError}}. Hence, I open this
> bug-report, now.
> This issue was originally reported in
> [subshare#74|https://github.com/subshare/subshare/issues/74], but it is IMHO
> clearly a Derby bug.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (DERBY-7049) OutOfMemoryError: Compressed class space
[
https://issues.apache.org/jira/browse/DERBY-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890984#comment-16890984
]
Bryan Pendleton commented on DERBY-7049:
Can you attach a reproducible test case? For example, a simple JDBC program
that can be run, over a period of, say, an hour or two, which provokes this
exception?
> OutOfMemoryError: Compressed class space
>
>
> Key: DERBY-7049
> URL: https://issues.apache.org/jira/browse/DERBY-7049
> Project: Derby
> Issue Type: Bug
>Affects Versions: 10.13.1.1
>Reporter: Marco
>Priority: Major
>
> After a few days of working with an embedded Derby database (currently
> version 10.13.1.1 on Oracle Java 1.8.0_201-b09), the following error occurs:
> *java.lang.OutOfMemoryError: Compressed class space*
> {code:java}
> java.lang.OutOfMemoryError: Compressed class space
> at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
> at
> org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement42.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.jdbc.Driver42.newEmbedPreparedStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.datanucleus.store.rdbms.datasource.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:259)
> ~[datanucleus-rdbms-4.0.12.jar:na]{code}
> I tried to solve the problem by periodically shutting down the database,
> because I read that the generated classes as well as all other allocated
> resources should be released when the DB is shut-down.
> I thus perform the following code once per roughly 20 minutes:
> {code:java}
> String shutdownConnectionURL = connectionURL + ";shutdown=true";
> try {
> DriverManager.getConnection(shutdownConnectionURL);
> } catch (SQLException e) {
> int errorCode = e.getErrorCode();
> if (DERBY_ERROR_CODE_SHUTDOWN_DATABASE_SUCCESSFULLY != errorCode &&
> DERBY_ERROR_CODE_SHUTDOWN_DATABASE_WAS_NOT_RUNNING != errorCode) {
> throw new RuntimeException(e);
> }
> }
> {code}
> Unfortunately, this has no effect :( The OutOfMemoryError still occurs after
> about 2 days. Do I assume correctly that the above code _should_ properly
> shut-down the database? And do I assume correctly that this shut-down should
> release the generated classes?
> IMHO, it is already a bug in Derby that I need to shut-down the database at
> all in order to prevent it from piling up generated classes. Shouldn't it
> already release the generated classes at the end of each transaction? But
> even if I really have to shut-down the DB, it is certainly a bug that the
> classes are still kept in "compressed class space" even after the shut-down.
> I searched the release notes and the existing bugs (here in JIRA) and did not
> find anything related to this {{OutOfMemoryError}}. Hence, I open this
> bug-report, now.
> This issue was originally reported in
> [subshare#74|https://github.com/subshare/subshare/issues/74], but it is IMHO
> clearly a Derby bug.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (DERBY-7046) NoClassDefFoundError on 'java -jar derbynet.jar'
[
https://issues.apache.org/jira/browse/DERBY-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872423#comment-16872423
]
Bryan Pendleton commented on DERBY-7046:
Rick, do you think we need a regression test in the Network Server test suites
that verifies that
java -jar derbynet.jar start
works as desired?
> NoClassDefFoundError on 'java -jar derbynet.jar'
>
>
> Key: DERBY-7046
> URL: https://issues.apache.org/jira/browse/DERBY-7046
> Project: Derby
> Issue Type: Bug
> Components: Network Server
>Affects Versions: 10.15.1.3
> Environment: openjdk version "11.0.3" 2019-04-16
> db-derby-10.15.1.3-bin
>Reporter: Piotr Zygielo
>Assignee: Rick Hillegas
>Priority: Major
> Attachments: derby-7046-01-aa-addToolsJarToServerManifest.diff
>
>
> {{derbynet.jar}} seems to be runnable jar - it has
> {code}
> Main-Class: org.apache.derby.drda.NetworkServerControl
> {code}
> but
> {code}
> Class-Path: derby.jar derbyshared.jar
> {code}
> does not include {{derbytools.jar}}.
> So on running {code:sh}java -jar derbynet.jar{code} following is presented:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/derby/iapi/tools/i18n/LocalizedOutput
> at
> org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:319)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.derby.iapi.tools.i18n.LocalizedOutput
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 1 more
> {code}
> It works fine with previous version (10.14.2.0).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DERBY-7034) Derby's sync() handling can lead to database corruption (at least on Linux)
[
https://issues.apache.org/jira/browse/DERBY-7034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855272#comment-16855272
]
Bryan Pendleton commented on DERBY-7034:
Hi David, sorry your questions kind of fell through the cracks. Derby
development has a bit quiet of late, and so we haven't tuned up our "new
contributor" docs in a while, but perhaps you can help us update them and fix
any rough edges.
Here are some places to start:
# https://cwiki.apache.org/confluence/display/DERBY/ForNewDevelopers
# https://cwiki.apache.org/confluence/display/DERBY/DerbyContributorChecklist
# https://cwiki.apache.org/confluence/display/DERBY/DerbyCommitProcess
In terms of how to "panic" when such an error arises, the first thing that
occurs to me is to follow the code path taken by a "Sane" build when it hits an
"Assert", and see if that gives us reasonable crash behavior.
> Derby's sync() handling can lead to database corruption (at least on Linux)
> ---
>
> Key: DERBY-7034
> URL: https://issues.apache.org/jira/browse/DERBY-7034
> Project: Derby
> Issue Type: Bug
> Components: Store
>Affects Versions: 10.14.2.0
>Reporter: David Sitsky
>Priority: Major
>
> I recently read about "fsyncgate 2018" that the Postgres team raised:
> https://wiki.postgresql.org/wiki/Fsync_Errors.
> https://lwn.net/Articles/752063/ has a good overview of the issue relating to
> fsync() behaviour on Linux. The short summary is on some versions of Linux
> if you retry fsync() after it failed, it will succeed and you will end up
> with corrupted data on disk.
> At a quick glance at the Derby code, I have already seen two places where
> sync() is retried in a loop which is clearly dangerous. There could be other
> areas too.
> In LogAccessFile:
> {code}
> /**
> * Guarantee all writes up to the last call to flushLogAccessFile on disk.
> *
> * A call for clients of LogAccessFile to insure that all data written
> * up to the last call to flushLogAccessFile() are written to disk.
> * This call will not return until those writes have hit disk.
> *
> * Note that this routine may block waiting for I/O to complete so
> * callers should limit the number of resource held locked while this
> * operation is called. It is expected that the caller
> * Note that this routine only "writes" the data to the file, this does
> not
> * mean that the data has been synced to disk. The only way to insure
> that
> * is to first call switchLogBuffer() and then follow by a call of sync().
> *
> **/
> public void syncLogAccessFile()
> throws IOException, StandardException
> {
> for( int i=0; ; )
> {
> // 3311: JVM sync call sometimes fails under high load against
> NFS
> // mounted disk. We re-try to do this 20 times.
> try
> {
> synchronized( this)
> {
> log.sync();
> }
> // the sync succeed, so return
> break;
> }
> catch( SyncFailedException sfe )
> {
> i++;
> try
> {
> // wait for .2 of a second, hopefully I/O is done by now
> // we wait a max of 4 seconds before we give up
> Thread.sleep( 200 );
> }
> catch( InterruptedException ie )
> {
> InterruptStatus.setInterrupted();
> }
> if( i > 20 )
> throw StandardException.newException(
> SQLState.LOG_FULL, sfe);
> }
> }
> }
> {code}
> And LogToFile has similar retry code.. but without handling for
> SyncFailedException:
> {code}
> /**
> * Utility routine to call sync() on the input file descriptor.
> *
> */
> private void syncFile( StorageRandomAccessFile raf)
> throws StandardException
> {
> for( int i=0; ; )
> {
> // 3311: JVM sync call sometimes fails under high load against
> NFS
> // mounted disk. We re-try to do this 20 times.
> try
> {
> raf.sync();
> // the sync succeed, so return
> break;
> }
> catch (IOException ioe)
> {
> i++;
> try
> {
> // wait for .2 of a second, hopefully I/O is done by now
> // we wait a max of 4 seconds before we give up
> Thread.sleep(200);
> }
>
