6 Replies Latest reply on Jul 26, 2010 5:36 PM by alwu-Oracle

    Oracle RDF / Joseki : issue with large literals

    766393
      Hi,

      I have been using Joseki to query an Oracle RDF model. There seems to be an issue with large literals (according to a few unreliable tests, I would say this concerns literals around and over 4000 chars).

      Here are the two potential behaviours :

      First case:
      If the results contains several lines, one of which contains an overly large literal, there are NO exception on the server side, but the resulting xml is incomplete.

      It misses the "line" containing the large literal, and the xml is stopped there (which means that it also misses the closing </results> and </sparql>. In my case, I am using the results through Jena's sparqlService, which means I get this message :

      XMLStreamException: Unexpected EOF; was expecting a close tag for element <results>
      +at [row,col {unknown-source}]: [31,0]+


      Second case:
      If the query only returns one line which contains an overly large literal, the client receives a simple *"HttpException: 500 Internal Server Error"*
      Here is the error message from my server :

      +INFO [[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] (SPARQL.java:165) - Throwable: we+
      blogic.jdbc.wrapper.Clob_oracle_sql_CLOB cannot be cast to oracle.sql.CLOB
      java.lang.ClassCastException: weblogic.jdbc.wrapper.Clob_oracle_sql_CLOB cannot be cast to oracle.sql.CLOB
      at oracle.spatial.rdf.client.jena.OracleSemIterator.getNodesFromResultSet(OracleSemIterator.java:579)
      at oracle.spatial.rdf.client.jena.OracleSemIterator.next(OracleSemIterator.java:445)
      at oracle.spatial.rdf.client.jena.OracleLeanQueryIter.moveToNextBinding(OracleLeanQueryIter.java:135)
      at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorBase.nextBinding(QueryIteratorBase.java:98)
      at com.hp.hpl.jena.sparql.engine.iterator.QueryIterConvert.moveToNextBinding(QueryIterConvert.java:56)
      at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorBase.nextBinding(QueryIteratorBase.java:98)
      at com.hp.hpl.jena.sparql.engine.iterator.QueryIterRepeatApply.moveToNextBinding(QueryIterRepeatApply.java:76)
      at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorBase.nextBinding(QueryIteratorBase.java:98)
      at com.hp.hpl.jena.sparql.engine.iterator.QueryIterProcessBinding.hasNextBinding(QueryIterProcessBinding.java:54
      +)+
      at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:69)
      at com.hp.hpl.jena.sparql.engine.iterator.QueryIterConvert.hasNextBinding(QueryIterConvert.java:50)
      at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:69)
      at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:30)
      at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:69)
      at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:30)
      at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:69)
      at com.hp.hpl.jena.sparql.engine.ResultSetStream.hasNext(ResultSetStream.java:62)
      at org.joseki.processors.SPARQL.executeQuery(SPARQL.java:309)
      at org.joseki.processors.SPARQL.execQueryWorker(SPARQL.java:288)
      at org.joseki.processors.SPARQL.execQueryProtected(SPARQL.java:126)
      at org.joseki.processors.SPARQL.execOperation(SPARQL.java:120)
      at org.joseki.processors.ProcessorBase.exec(ProcessorBase.java:112)
      at org.joseki.ServiceRequest.exec(ServiceRequest.java:36)
      at org.joseki.Dispatcher.dispatch(Dispatcher.java:59)
      at org.joseki.http.Servlet.doCommon(Servlet.java:177)
      at org.joseki.http.Servlet.doGet(Servlet.java:138)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
      at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
      at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
      at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292)
      at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
      at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3594)
      at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
      at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
      at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2202)
      at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2108)
      at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1432)
      at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
      at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)


      Would there be any fix / workaround ?

      Please let me know if you need further information / tests.

      Thanks,

      Regards,
      Julien
        • 1. Re: Oracle RDF / Joseki : issue with large literals
          alwu-Oracle
          It is quite strange because we are using the same code path for both cases.

          Could you send us a small test data file and corresponding queries that reproduce this problem?
          We have long literal test cases that are running fine in the test suite.

          Please send to alan dot wu at oracle dot com.

          Thanks,

          Zhe Wu
          • 2. Re: Oracle RDF / Joseki : issue with large literals
            766393
            Thanks for your reply.

            While trying to build up a small test case, I found out why there were discrepancies between the two cases I described.

            Indeed, usually, the two cases return the same thing (no exception on the server side, but incomplete resulting XML).

            The exception I described happened when I tried something else. Since I saw that issues were coming from long literals, I used fn:string-length (ARQ) to figure out how long they were.

            The test case resulting in the CLOB-cast-exception is:
            - too large literal
            - only one result "line" containing this literal
            - usage of fn:string-length (which does not change the behaviour in other cases (i.e. no long literals or/and several lines).


            Anyway, you will receive the other test cases shortly.

            Thanks,

            Regards,
            Julien
            • 3. Re: Oracle RDF / Joseki : issue with large literals
              766393
              I hope you received my test case last week.

              Have you been able to reproduce this issue ?

              Please let me know if you need more information on my setup / test case.

              Thanks

              Regards,
              Julien
              • 4. Re: Oracle RDF / Joseki : issue with large literals
                alwu-Oracle
                Update:

                I have run the first three queries and the last one from Jena Adapter, things appear to be fine. Maybe Joseki is doing something different here... Stay tuned.

                Zhe Wu
                • 5. Re: Oracle RDF / Joseki : issue with large literals
                  766393
                  Well, just in case someone else is facing the same issue, here is a "workaround".

                  Using the following line will prevent queries from returning CLOBs. They will only appear as ORALLxxxx instead of their contents.

                  PREFIX ORACLE_SEM_FS_NS: <http://oracle.com/semtech#skip_clob=t>

                  Regards,
                  Julien
                  • 6. Re: Oracle RDF / Joseki : issue with large literals
                    alwu-Oracle
                    Update:

                    The problem is that when Joseki is deployed in WLS, the Clob object retrieved from the
                    database connection is wrapped in a WLS defined object. The consequence is that we can
                    no longer cast this Clob object to Oracle's specific CLOB class. Such a problem does not
                    exist if one runs Jena Adapter in a standalone mode.

                    A fix has already been implemented and the test queries are running fine in Joeski.

                    Zhe Wu