home list archives users mailing list
 

Subject: RE: Tomcat OutOfMemoryError with OGSA-DAI clients

Date view Thread view Subject view Author view Attachment view

From: Ally Hume (a.hume@epcc.ed.ac.uk)
Date: May 16, 2006 12:51

Hi Lucas,

So it looks like DQP is being given some characters it cannot
understand. Two reasons spring to mind that may cause this:

1) There really is a bad character in the output of the query that is
not being escaped correctly so it can pass as XML.

2) An error message is appearing the in data being sent to DQP instead
of the real data. DQP then throws an error when paring this error
message.

I'm not too familiar with the internals of DQP but my guess would be
that some bad XML is being passed between services. One path to
solving this may be to using axis's TCP monitor to view the messages
being sent between this DQP server and the OGSA-DAI server(s). When
viewing these messages you may be able to diagnose what is going
wrong.

I'm sorry I cannot offer much more help. Is there any error messages
in the logs of the OGSA-DAI services being accessed by DQP?

Ally

-------------------------------------------------------------
Ally Hume
Software Architect
EPCC, University of Edinburgh
James Clerk Maxwell Building
Mayfield Road E-mail: a.hume@epcc.ed.ac.uk
Edinburgh, EH9 3JZ Phone: + 44 (0) 131 651 3397
United Kingdom Fax: + 44 (0) 131 650 6555
-------------------------------------------------------------

-----Original Message-----
From: Lucas Zamboulis [mailto:lucas@dcs.bbk.ac.uk]
Sent: 16 May 2006 12:27
To: Ally Hume
Cc: users@ogsadai.org.uk
Subject: Re: Tomcat OutOfMemoryError with OGSA-DAI clients

Hi Ally,

I increased the memory for the end-to-end client through the ant file
and it worked - so this is not a DAI problem.

Back to my original problem: I am trying to use the DQP query client.
It
works fine with queries that return small results, but throws the
following error when it's supposed to return large result sets (this
is
from the tomcat log - the error is output after the DQP has returned -

in the log, not the command line - about 4000 tuples).

I wrote the first e-mail because I thought maybe DAI stopped providing

results to DQP, which crashed as a result, giving this error message.
Now it seems it's a DQP issue?

Regards,
Lucas

- Could not parse row: Illegal character or entity reference syntax.
- Could not parse row: Illegal character or entity reference syntax.
org.xml.sax.SAXParseException: Illegal character or entity reference
syntax.
        at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3376)
        at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3364)
        at
org.apache.crimson.parser.Parser2.maybeReferenceInContent(Parser2.java
:2604)
        at
org.apache.crimson.parser.Parser2.content(Parser2.java:2017)
        at
org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1691)
        at
org.apache.crimson.parser.Parser2.content(Parser2.java:1963)
        at
org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1691)
        at
org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:667)
        at org.apache.crimson.parser.Parser2.parse(Parser2.java:337)
        at
org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:448)
        at
uk.org.ogsadai.dqp.gqes.utils.RowHandler.produceVectorFromRow(RowHandl
er.java:137)
        at
uk.org.ogsadai.dqp.gqes.utils.RowListHandler.endElement(RowListHandler
.java:170)
        at
org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1712)
        at
org.apache.crimson.parser.Parser2.content(Parser2.java:1963)
        at
org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1691)
        at
org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:667)
        at org.apache.crimson.parser.Parser2.parse(Parser2.java:337)
        at
org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:448)
        at
uk.org.ogsadai.dqp.gqes.utils.RowListHandler.produceVectorListFromRowL
ist(RowListHandler.java:116)
        at
uk.org.ogsadai.dqp.gqes.operators.AsynchGDSAccessor.run(TableScanOp.ja
va:483)
- 0: Exception in executeAsynchGDSRequest(): Illegal character or
entity
reference syntax.

Ally Hume wrote:
> Hi Lucas,
>
> It does sound like the client is a fault here.
>
> Let's start with the simple stuff first! Have you increased the
> memory heap size for the client? Your notes seem to imply you have
> done this only for the server.
>
> It sounds like you get the error when just using the data browser or
> end to end client to talk to OGSA-DAI. In this case increasing the
> memory of the server and/or the client should remove the out of
memory
> error.
>
> What exactly is the error you are seeing on the client? Do you have
a
> full stack trace?
>
> Regards,
>
> Ally
>
> -------------------------------------------------------------
> Ally Hume
> Software Architect
> EPCC, University of Edinburgh
> James Clerk Maxwell Building
> Mayfield Road E-mail: a.hume@epcc.ed.ac.uk
> Edinburgh, EH9 3JZ Phone: + 44 (0) 131 651 3397
> United Kingdom Fax: + 44 (0) 131 650 6555
> -------------------------------------------------------------
>
>
> -----Original Message-----
> From: owner-users@ogsadai.org.uk [mailto:owner-users@ogsadai.org.uk]
> On Behalf Of Lucas Zamboulis
> Sent: 12 May 2006 21:31
> To: users@ogsadai.org.uk
> Subject: Tomcat OutOfMemoryError with OGSA-DAI clients
>
> Hi,
>
> I'm having trouble retrieving a 200,000 integer result set from a
> MySQL
> database. I'm using OGSA-DAI WSI 2.1 on a Linux FC4 with 2GB RAM. I
> successfully retrieve data from other tables in the same DB (and
from
> the same table when e.g. adding an Id<1000 constraint on the query).

> This is therefore a problem having to do with the size of the result

> set: both databrowser and end-to-end client exit with an
> OutOfMemoryError, although the Tomcat log (see end of mail) .
>
> I then read the related issue in the DAI FAQ, which suggests:
>
> - increase the memory heap size for the virtual machine using the
> Xms<size> flag.
> --- Done that, raised both Xms and Xmx flags in the catalina.sh
file,
> using both CATALINA_OPTS and JAVA_OPTS, problem persists
>
> - may be a JDBC driver issue for specific db (loading whole results
> set
> in memory prior to giving a handle to DAI), try using another DBMS
> --- Using the latest driver, DBMS: MySQL version 4.1.
>
> - Try using asynchronous data transport functionalty to stream the
> data
> to and from the service in chunks
> --- I'm actually trying to use DQP over DAI, so it's out of my
> control,
> but as I understand it, DQP 3 does use asynchronous data transport
> functionalty and I still get an error when issuing the same query on
> DQP
> (that's how I first noticed the problem - although the problem
appears
>
> in a different manner when using DQP).
>
> Do you think the error I'm getting is because neither the
databrowser,
>
> nor the end-to-end client use asynchronous data transport? I'm
asking
> because the start of the log file (showing all three DAI process to
> have
> completed successfully) implies that DAI successfully processed the
> query and the result set, and therefore the error may be in the
> application using DAI.
>
> If not, any ideas?
>
> Regards,
> Lucas
>
>
----------------------------------------------------------------------
> -
> Lucas Zamboulis
> R.A./Ph.D. candidate
> School of Computer Science and Information Systems
> Birkbeck College, University of London
> London Knowledge Lab Tel.: +44 20 7763 2102
> 23-29 Emerald Street Fax: +44 20 7242 2756
> London, WC1N 3QS http://www.dcs.bbk.ac.uk/~lucas
>
>
> May 12, 2006 9:17:33 PM org.apache.catalina.startup.Catalina start
> INFO: Server startup in 4814 ms
> - statementOutputStatus : PROCESSING
> - statementRSToXMLStatus : PROCESSING
> - statementStatus : PROCESSING
> - statementStatus : COMPLETED
> - statementRSToXMLStatus : COMPLETED
> - statementOutputStatus : COMPLETED
> - java.io.IOException:
> ClientAbortException: java.net.SocketException: Connection reset
> at
>
org.apache.coyote.tomcat5.OutputBuffer.realWriteBytes(OutputBuffer.jav
> a:373)
> at
> org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:294)
> at
>
org.apache.coyote.tomcat5.OutputBuffer.writeBytes(OutputBuffer.java:40
> 1)
> at
> org.apache.coyote.tomcat5.OutputBuffer.write(OutputBuffer.java:388)
> at
>
org.apache.coyote.tomcat5.CoyoteOutputStream.write(CoyoteOutputStream.
> java:76)
> at org.apache.axis.utils.ByteArray.writeTo(ByteArray.java:375)
> at org.apache.axis.SOAPPart.writeTo(SOAPPart.java:265)
> at org.apache.axis.Message.writeTo(Message.java:528)
> at
>
org.apache.axis.transport.http.AxisServlet.sendResponse(AxisServlet.ja
> va:902)
> at
>
org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:777
> )
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
> at
>
org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase
> .java:327)
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at
>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
> cationFilterChain.java:237)
> at
>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
> lterChain.java:157)
> at
>
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVa
> lve.java:214)
> at
>
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValve
> Context.java:104)
> at
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java
> :520)
> at
>
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardC
> ontextValve.java:198)
> at
>
org.apache.catalina.core.StandardContextValve.invoke(StandardContextVa
> lve.java:152)
> at
>
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValve
> Context.java:104)
> at
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java
> :520)
> at
>
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.ja
> va:137)
> at
>
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValve
> Context.java:104)
> at
>
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.ja
> va:118)
> at
>
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValve
> Context.java:102)
> at
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java
> :520)
> at
>
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValv
> e.java:109)
> at
>
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValve
> Context.java:104)
> at
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java
> :520)
> at
>
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
> at
>
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160
> )
> at
>
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
> 799)
> at
>
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proces
> sConnection(Http11Protocol.java:705)
> at
>
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:
> 577)
> at
>
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPo
> ol.java:683)
> at java.lang.Thread.run(Thread.java:534)
>
>

Date view Thread view Subject view Author view Attachment view