You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Stefan Thieme <st...@gmx.ch> on 2015/02/18 16:07:46 UTC
Aw: Re: [PATCH] [OAK-1914] RDB: Oracle support
(resend as text mail)
Dear Julian,
I have retried the test case (curl5) for the error I got when inserting a previously deleted node on an Oracle 12c EE database.
I do get the same java.sql.SQLIntegrityConstraintViolation as initially described for Oracle 11g.
See below for the table description / constraint on Oracle 12c.
Is there a way we could handle this Exception more gracefully, e.g. by throwing a DocumentStoreException ?
For the earlier questions:
> a) workaround FETCH FIRST as Oracle 11g2 needsRowNumSubquery.
> Oracle 12c implicitly uses the same workaround internally by Query
> Transformation of FETCH FIRST.
> http://oracle-base.com/articles/12c/row-limiting-clause-for-top-n-queries-12cr1.php#query-transformation
This patch would allow to support both Oracle 12c and Oracle 11g2 databases.
For me Oracle 12c is still not a common sight, though undeniable it is the future.
I can basically live with my small patch on top of OAK-Trunk.
> b) MAX_ID_VALUE=";" in NodeDocument triggers a SQL Error on Oracle DB,
> changing to MAX_ID_VALUE="a" as in ClusterNodeInfoDocument.
I understand that ";" is an ASCII char just above digits 0-9, IMHO even ":" would suffice for this purpose.
Can someone explain the reasoning behind MAX_ID_VALUE="a" in ClusterNodeInfoDocument for my own curiosity ?
BTW, I can not reproduce the SQL Error I got initially, which was probably introduced by a couple of conflicting patches.
> c) add Oak-RDB to server in oak-run Main
> adding rdbjdbcuri, rdbjdbcuser and rdbjdbcpassword as OptionalArgs
This has been solved by your update in OAK 1.1.6, thanks!
Kind regards,
Stefan
15:19:19.940 [qtp141373610-14] DEBUG o.a.j.o.p.d.rdb.RDBDocumentStore - insert of [1:/test] failed
java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (OAK.SYS_C009999) violated
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:439) ~[ojdbc6.jar:11.2.0.1.0]
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:395) ~[ojdbc6.jar:11.2.0.1.0]
at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:802) ~[ojdbc6.jar:11.2.0.1.0]
at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:436) ~[ojdbc6.jar:11.2.0.1.0]
at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:186) ~[ojdbc6.jar:11.2.0.1.0]
at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:521) ~[ojdbc6.jar:11.2.0.1.0]
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:205) ~[ojdbc6.jar:11.2.0.1.0]
at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:1008) ~[ojdbc6.jar:11.2.0.1.0]
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1307) ~[ojdbc6.jar:11.2.0.1.0]
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3449) ~[ojdbc6.jar:11.2.0.1.0]
at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3530) ~[ojdbc6.jar:11.2.0.1.0]
at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeUpdate(OraclePreparedStatementWrapper.java:1350) ~[ojdbc6.jar:11.2.0.1.0]
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) ~[oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) ~[oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.dbInsert(RDBDocumentStore.java:1410) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.insertDocuments(RDBDocumentStore.java:1069) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.internalCreate(RDBDocumentStore.java:676) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.create(RDBDocumentStore.java:243) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:321) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:246) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.plugins.document.Commit.applyInternal(Commit.java:215) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.plugins.document.Commit.apply(Commit.java:200) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.persist(DocumentNodeStoreBranch.java:308) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.persist(DocumentNodeStoreBranch.java:278) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.access$200(DocumentNodeStoreBranch.java:51) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:518) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:231) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:169) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:159) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1335) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:245) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:256) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.http.OakServlet.doPost(OakServlet.java:154) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:755) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.apache.jackrabbit.oak.http.OakServlet.service(OakServlet.java:107) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:594) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.eclipse.jetty.server.Server.handle(Server.java:368) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) [oak-run-1.1-SNAPSHOT.jar:1.1-SNAPSHOT]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60]
15:19:19.957 [qtp141373610-14] DEBUG o.a.j.o.plugins.document.CommitQueue - removed r14b9d0eadf6-0-1, head is now null
desc OAK.NODES;
Name Null Type
----------- -------- --------------
ID NOT NULL VARCHAR2(512)
MODIFIED NUMBER
HASBINARY NUMBER
DELETEDONCE NUMBER
MODCOUNT NUMBER
CMODCOUNT NUMBER
DSIZE NUMBER
DATA VARCHAR2(4000)
BDATA BLOB
SELECT * FROM user_constraints WHERE table_name = 'NODES';
OWNER CONSTRAINT_NAME CONSTRAINT_TYPE TABLE_NAME SEARCH_CONDITION SEARCH_CONDITION_VC R_OWNER R_CONSTRAINT_NAME DELETE_RULE STATUS DEFERRABLE DEFERRED VALIDATED GENERATED BAD RELY LAST_CHANGE INDEX_OWNER INDEX_NAME INVALID VIEW_RELATED ORIGIN_CON_ID
-------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------- --------------- -------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------- ----------- -------- -------------- --------- ------------- -------------- --- ---- ----------- -------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------- ------- -------------- -------------
OAK SYS_C009998 C NODES "ID" IS NOT NULL "ID" IS NOT NULL ENABLED NOT DEFERRABLE IMMEDIATE VALIDATED GENERATED NAME 18-FEB-15 0
OAK SYS_C009999 P NODES ENABLED NOT DEFERRABLE IMMEDIATE VALIDATED GENERATED NAME 18-FEB-15 OAK SYS_C009999 0
Gesendet: Mittwoch, 28. Januar 2015 um 09:38 Uhr
Von: "Julian Reschke" <ju...@greenbytes.de>
An: "Stefan Thieme" <st...@gmx.ch>
Betreff: Re: [PATCH] [OAK-1914] RDB: Oracle support
On 2015-01-28 09:34, Stefan Thieme wrote:
> Dear Julian,
> I have been unable to commit to the Jackrabbit OAK Repository myself.
> You are assigned the "[OAK-1914] RDB: Oracle support" hence I am sending
> you this patch.
> I am glad to receive your reply for any comments or feedback.
> Kind regards,
> Stefan Thieme
> ---
> OAK-1914 Oak-RDB for Oracle 11g2
I don't believe we want to support Oracle 11 if it complicates things.
If you disagree please let's have that discussion on the oak-dev mailing
list.
> a) workaround FETCH FIRST as Oracle 11g2 needsRowNumSubquery.
> Oracle 12c implicitly uses the same workaround internally by Query
> Transformation of FETCH FIRST.
> http://oracle-base.com/articles/12c/row-limiting-clause-for-top-n-queries-12cr1.php#query-transformation[http://oracle-base.com/articles/12c/row-limiting-clause-for-top-n-queries-12cr1.php#query-transformation]
> b) MAX_ID_VALUE=";" in NodeDocument triggers a SQL Error on Oracle DB,
> changing to MAX_ID_VALUE="a" as in ClusterNodeInfoDocument.
> c) add Oak-RDB to server in oak-run Main
> adding rdbjdbcuri, rdbjdbcuser and rdbjdbcpassword as OptionalArgs
Could you be more specific about what the problem is? I'm already using
oak-run with RDB, so I'm not sure...
Aw: Re: Re: Re: [PATCH] [OAK-1914] RDB: Oracle support
Posted by Stefan Thieme <st...@gmx.ch>.
> So the code actually works, and the problem is just that an exception is
> logged?
That is my understanding, which I would suggest to have handled more gracefully.
What wonders me is that you are not seeing this exception ?
Kind regards,
Stefan
Re: Aw: Re: Re: [PATCH] [OAK-1914] RDB: Oracle support
Posted by Julian Reschke <ju...@gmx.de>.
On 2015-02-19 10:15, Stefan Thieme wrote:
>
>
> Gesendet: Mittwoch, 18. Februar 2015 um 16:51 Uhr
> Von: "Julian Reschke" <ju...@gmx.de>
> An: "Stefan Thieme" <st...@gmx.ch>
> Cc: oak-dev@jackrabbit.apache.org
> Betreff: Re: Aw: Re: [PATCH] [OAK-1914] RDB: Oracle support
> On 2015-02-18 16:07, Stefan Thieme wrote:
>> (resend as text mail)
>>
>> Dear Julian,
>>
>> I have retried the test case (curl5) for the error I got when inserting a previously deleted node on an Oracle 12c EE database.
>>
>> I do get the same java.sql.SQLIntegrityConstraintViolation as initially described for Oracle 11g.
>> See below for the table description / constraint on Oracle 12c.
>>
>> Is there a way we could handle this Exception more gracefully, e.g. by throwing a DocumentStoreException ?
>
> Again, that exception is not supposed to occur.
>
>
>> I believe it is store.create(NODES, newNodes) that tries to commit/create the root node ("1:/test" in my case) again.
>> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore
>> ...
>> try {
>> if (newNodes.size() > 0) {
>> // set commit root on new nodes
>> if (!store.create(NODES, newNodes)) {
>> // some of the documents already exist:
>> // try to apply all changes one by one
>> for (UpdateOp op : newNodes) {
>> if (op == commitRoot) {
>> ...
>
> As explained in OAK-1914 the exception is raised because the above code tries to (re-)create the node in my case (create, delete and recreate a node).
> Even though I have deleted the node in an earlier step the row is still in my NODES table (which is by design and unquestionable correct), hence the constraint violation when store.create(NODES, newNodes) is called.
> The code then goes on to Update the node which is giving updated results in NODES table, only the exception is left as a trace of the first try to recreate it in my case.
So the code actually works, and the problem is just that an exception is
logged?
> ...
Best regards, Julian
Aw: Re: Re: [PATCH] [OAK-1914] RDB: Oracle support
Posted by Stefan Thieme <st...@gmx.ch>.
Gesendet: Mittwoch, 18. Februar 2015 um 16:51 Uhr
Von: "Julian Reschke" <ju...@gmx.de>
An: "Stefan Thieme" <st...@gmx.ch>
Cc: oak-dev@jackrabbit.apache.org
Betreff: Re: Aw: Re: [PATCH] [OAK-1914] RDB: Oracle support
On 2015-02-18 16:07, Stefan Thieme wrote:
> (resend as text mail)
>
> Dear Julian,
>
> I have retried the test case (curl5) for the error I got when inserting a previously deleted node on an Oracle 12c EE database.
>
> I do get the same java.sql.SQLIntegrityConstraintViolation as initially described for Oracle 11g.
> See below for the table description / constraint on Oracle 12c.
>
> Is there a way we could handle this Exception more gracefully, e.g. by throwing a DocumentStoreException ?
Again, that exception is not supposed to occur.
> I believe it is store.create(NODES, newNodes) that tries to commit/create the root node ("1:/test" in my case) again.
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore
> ...
> try {
> if (newNodes.size() > 0) {
> // set commit root on new nodes
> if (!store.create(NODES, newNodes)) {
> // some of the documents already exist:
> // try to apply all changes one by one
> for (UpdateOp op : newNodes) {
> if (op == commitRoot) {
> ...
As explained in OAK-1914 the exception is raised because the above code tries to (re-)create the node in my case (create, delete and recreate a node).
Even though I have deleted the node in an earlier step the row is still in my NODES table (which is by design and unquestionable correct), hence the constraint violation when store.create(NODES, newNodes) is called.
The code then goes on to Update the node which is giving updated results in NODES table, only the exception is left as a trace of the first try to recreate it in my case.
Please let me know if my understanding is correct and the Exception could be disregarded ?
> For the earlier questions:
>
Re: Aw: Re: [PATCH] [OAK-1914] RDB: Oracle support
Posted by Marcel Reutegger <mr...@adobe.com>.
Hi,
On 18/02/15 16:51, "Julian Reschke" <ju...@gmx.de> wrote:
>
>>> b) MAX_ID_VALUE=";" in NodeDocument triggers a SQL Error on Oracle DB,
>>> changing to MAX_ID_VALUE="a" as in ClusterNodeInfoDocument.
>>
>> I understand that ";" is an ASCII char just above digits 0-9, IMHO even
>>":" would suffice for this purpose.
>>
>> Can someone explain the reasoning behind MAX_ID_VALUE="a" in
>>ClusterNodeInfoDocument for my own curiosity ?
>
>Marcel?
I think this can be changed to a colon (":"). the _id for a
ClusterNodeInfoDocument is always an integer greater than zero.
Regards
Marcel
Re: Aw: Re: [PATCH] [OAK-1914] RDB: Oracle support
Posted by Julian Reschke <ju...@gmx.de>.
On 2015-02-18 16:07, Stefan Thieme wrote:
> (resend as text mail)
>
> Dear Julian,
>
> I have retried the test case (curl5) for the error I got when inserting a previously deleted node on an Oracle 12c EE database.
>
> I do get the same java.sql.SQLIntegrityConstraintViolation as initially described for Oracle 11g.
> See below for the table description / constraint on Oracle 12c.
>
> Is there a way we could handle this Exception more gracefully, e.g. by throwing a DocumentStoreException ?
Again, that exception is not supposed to occur.
> For the earlier questions:
>
>> a) workaround FETCH FIRST as Oracle 11g2 needsRowNumSubquery.
>> Oracle 12c implicitly uses the same workaround internally by Query
>> Transformation of FETCH FIRST.
>> http://oracle-base.com/articles/12c/row-limiting-clause-for-top-n-queries-12cr1.php#query-transformation
>
> This patch would allow to support both Oracle 12c and Oracle 11g2 databases.
> For me Oracle 12c is still not a common sight, though undeniable it is the future.
> I can basically live with my small patch on top of OAK-Trunk.
Understood. I'd like to avoid too many special cases; they make testing
and debugging a pain.
>> b) MAX_ID_VALUE=";" in NodeDocument triggers a SQL Error on Oracle DB,
>> changing to MAX_ID_VALUE="a" as in ClusterNodeInfoDocument.
>
> I understand that ";" is an ASCII char just above digits 0-9, IMHO even ":" would suffice for this purpose.
>
> Can someone explain the reasoning behind MAX_ID_VALUE="a" in ClusterNodeInfoDocument for my own curiosity ?
Marcel?
> BTW, I can not reproduce the SQL Error I got initially, which was probably introduced by a couple of conflicting patches.
>
> > c) add Oak-RDB to server in oak-run Main
>> adding rdbjdbcuri, rdbjdbcuser and rdbjdbcpassword as OptionalArgs
>
> This has been solved by your update in OAK 1.1.6, thanks!
>
> Kind regards,
> Stefan
Best regards, Julian