|
Jon Drukman
2012-05-15, 20:33
Michael Della Bitta
2012-05-15, 21:07
Jon Drukman
2012-05-15, 21:12
Dyer, James
2012-05-15, 21:35
Jon Drukman
2012-05-15, 21:42
Jon Drukman
2012-05-15, 23:10
Shawn Heisey
2012-05-17, 20:55
Dyer, James
2012-05-17, 21:01
Shawn Heisey
2012-05-17, 21:47
|
-
Exception in DataImportHandler (stack overflow)Jon Drukman 2012-05-15, 20:33
I have a machine which does a full update using DataImportHandler every
hour. It worked up until a little while ago. I did not change the dataconfig.xml or version of Solr. Here is the beginning of the error in the log (the real thing runs for thousands of lines) 2012-05-15 12:44:30.724166500 SEVERE: Full Import failed:org.apache.solr.handler.dataimport.DataImportHandlerException: java.lang.StackOverflowError 2012-05-15 12:44:30.724168500 at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:669) 2012-05-15 12:44:30.724169500 at org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:268) 2012-05-15 12:44:30.724171500 at org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:187) 2012-05-15 12:44:30.724219500 at org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:359) 2012-05-15 12:44:30.724221500 at org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:427) 2012-05-15 12:44:30.724223500 at org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:408) 2012-05-15 12:44:30.724224500 Caused by: java.lang.StackOverflowError 2012-05-15 12:44:30.724225500 at java.lang.String.checkBounds(String.java:404) 2012-05-15 12:44:30.724234500 at java.lang.String.<init>(String.java:450) 2012-05-15 12:44:30.724235500 at java.lang.String.<init>(String.java:523) 2012-05-15 12:44:30.724236500 at java.net.SocketOutputStream.socketWrite0(Native Method) 2012-05-15 12:44:30.724238500 at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109) 2012-05-15 12:44:30.724239500 at java.net.SocketOutputStream.write(SocketOutputStream.java:153) 2012-05-15 12:44:30.724253500 at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) 2012-05-15 12:44:30.724254500 at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) 2012-05-15 12:44:30.724256500 at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3345) 2012-05-15 12:44:30.724257500 at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1983) 2012-05-15 12:44:30.724259500 at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2163) 2012-05-15 12:44:30.724267500 at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2618) 2012-05-15 12:44:30.724268500 at com.mysql.jdbc.StatementImpl.executeSimpleNonQuery(StatementImpl.java:1644) 2012-05-15 12:44:30.724270500 at com.mysql.jdbc.RowDataDynamic.close(RowDataDynamic.java:198) 2012-05-15 12:44:30.724271500 at com.mysql.jdbc.ResultSetImpl.realClose(ResultSetImpl.java:7617) 2012-05-15 12:44:30.724273500 at com.mysql.jdbc.ResultSetImpl.close(ResultSetImpl.java:907) 2012-05-15 12:44:30.724280500 at com.mysql.jdbc.StatementImpl.realClose(StatementImpl.java:2478) 2012-05-15 12:44:30.724282500 at com.mysql.jdbc.ConnectionImpl.closeAllOpenStatements(ConnectionImpl.java:1584) 2012-05-15 12:44:30.724283500 at com.mysql.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:4364) 2012-05-15 12:44:30.724285500 at com.mysql.jdbc.ConnectionImpl.cleanup(ConnectionImpl.java:1360) 2012-05-15 12:44:30.724286500 at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2652) 2012-05-15 12:44:30.724321500 at com.mysql.jdbc.StatementImpl.executeSimpleNonQuery(StatementImpl.java:1644) 2012-05-15 12:44:30.724322500 at com.mysql.jdbc.RowDataDynamic.close(RowDataDynamic.java:198) 2012-05-15 12:44:30.724324500 at com.mysql.jdbc.ResultSetImpl.realClose(ResultSetImpl.java:7617) 2012-05-15 12:44:30.724325500 at com.mysql.jdbc.ResultSetImpl.close(ResultSetImpl.java:907) 2012-05-15 12:44:30.724327500 at com.mysql.jdbc.StatementImpl.realClose(StatementImpl.java:2478) 2012-05-15 12:44:30.724334500 at com.mysql.jdbc.ConnectionImpl.closeAllOpenStatements(ConnectionImpl.java:1584) 2012-05-15 12:44:30.724335500 at com.mysql.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:4364) 2012-05-15 12:44:30.724336500 at com.mysql.jdbc.ConnectionImpl.cleanup(ConnectionImpl.java:1360) 2012-05-15 12:44:30.724338500 at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2652) 2012-05-15 12:44:30.724339500 at com.mysql.jdbc.StatementImpl.executeSimpleNonQuery(StatementImpl.java:1644) 2012-05-15 12:44:30.724345500 at com.mysql.jdbc.RowDataDynamic.close(RowDataDynamic.java:198) 2012-05-15 12:44:30.724347500 at com.mysql.jdbc.ResultSetImpl.realClose(ResultSetImpl.java:7617) 2012-05-15 12:44:30.724348500 at com.mysql.jdbc.ResultSetImpl.close(ResultSetImpl.java:907) 2012-05-15 12:44:30.724350500 at com.mysql.jdbc.StatementImpl.realClose(StatementImpl.java:2478) 2012-05-15 12:44:30.724351500 at com.mysql.jdbc.ConnectionImpl.closeAllOpenStatements(ConnectionImpl.java:1584) 2012-05-15 12:44:30.724363500 at com.mysql.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:4364) 2012-05-15 12:44:30.724364500 at com.mysql.jdbc.ConnectionImpl.cleanup(ConnectionImpl.java:1360) 2012-05-15 12:44:30.724366500 at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2652) 2012-05-15 12:44:30.724367500 at com.mysql.jdbc.StatementImpl.executeSimpleNonQuery(StatementImpl.java:1644) 2012-05-15 12:44:30.724369500 at com.mysql.jdbc.RowDataDynamic.close(RowDataDynamic.java:198)
-
Re: Exception in DataImportHandler (stack overflow)Michael Della Bitta 2012-05-15, 21:07
Hi, Jon:
Well, you don't see that every day! Is it possible that you have something weird going on in your DDL and/or queries, like a tree schema that now suddenly has a cyclical reference? Michael On Tue, May 15, 2012 at 4:33 PM, Jon Drukman <[EMAIL PROTECTED]> wrote: > I have a machine which does a full update using DataImportHandler every > hour. It worked up until a little while ago. I did not change the > dataconfig.xml or version of Solr. > > Here is the beginning of the error in the log (the real thing runs for > thousands of lines) > > 2012-05-15 12:44:30.724166500 SEVERE: Full Import > failed:org.apache.solr.handler.dataimport.DataImportHandlerException: > java.lang.StackOverflowError > 2012-05-15 12:44:30.724168500 at > org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:669) > 2012-05-15 12:44:30.724169500 at > org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:268) > 2012-05-15 12:44:30.724171500 at > org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:187) > 2012-05-15 12:44:30.724219500 at > org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:359) > 2012-05-15 12:44:30.724221500 at > org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:427) > 2012-05-15 12:44:30.724223500 at > org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:408) > 2012-05-15 12:44:30.724224500 Caused by: java.lang.StackOverflowError > 2012-05-15 12:44:30.724225500 at > java.lang.String.checkBounds(String.java:404) > 2012-05-15 12:44:30.724234500 at java.lang.String.<init>(String.java:450) > 2012-05-15 12:44:30.724235500 at java.lang.String.<init>(String.java:523) > 2012-05-15 12:44:30.724236500 at > java.net.SocketOutputStream.socketWrite0(Native Method) > 2012-05-15 12:44:30.724238500 at > java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109) > 2012-05-15 12:44:30.724239500 at > java.net.SocketOutputStream.write(SocketOutputStream.java:153) > 2012-05-15 12:44:30.724253500 at > java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) > 2012-05-15 12:44:30.724254500 at > java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) > 2012-05-15 12:44:30.724256500 at > com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3345) > 2012-05-15 12:44:30.724257500 at > com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1983) > 2012-05-15 12:44:30.724259500 at > com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2163) > 2012-05-15 12:44:30.724267500 at > com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2618) > 2012-05-15 12:44:30.724268500 at > com.mysql.jdbc.StatementImpl.executeSimpleNonQuery(StatementImpl.java:1644) > 2012-05-15 12:44:30.724270500 at > com.mysql.jdbc.RowDataDynamic.close(RowDataDynamic.java:198) > 2012-05-15 12:44:30.724271500 at > com.mysql.jdbc.ResultSetImpl.realClose(ResultSetImpl.java:7617) > 2012-05-15 12:44:30.724273500 at > com.mysql.jdbc.ResultSetImpl.close(ResultSetImpl.java:907) > 2012-05-15 12:44:30.724280500 at > com.mysql.jdbc.StatementImpl.realClose(StatementImpl.java:2478) > 2012-05-15 12:44:30.724282500 at > com.mysql.jdbc.ConnectionImpl.closeAllOpenStatements(ConnectionImpl.java:1584) > 2012-05-15 12:44:30.724283500 at > com.mysql.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:4364) > 2012-05-15 12:44:30.724285500 at > com.mysql.jdbc.ConnectionImpl.cleanup(ConnectionImpl.java:1360) > 2012-05-15 12:44:30.724286500 at > com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2652) > 2012-05-15 12:44:30.724321500 at > com.mysql.jdbc.StatementImpl.executeSimpleNonQuery(StatementImpl.java:1644) > 2012-05-15 12:44:30.724322500 at > com.mysql.jdbc.RowDataDynamic.close(RowDataDynamic.java:198) > 2012-05-15 12:44:30.724324500 at > com.mysql.jdbc.ResultSetImpl.realClose(ResultSetImpl.java:7617) > 2012-05-15 12:44:30.724325500 at > com.mysql.jdbc.ResultSetImpl.close(ResultSetImpl.java:907) > 2012-05-15 12:44:30.724327500 at > com.mysql.jdbc.StatementImpl.realClose(StatementImpl.java:2478)
-
Re: Exception in DataImportHandler (stack overflow)Jon Drukman 2012-05-15, 21:12
i don't think so, my config is straightforward:
<dataConfig> <dataSource type="JdbcDataSource" driver="com.mysql.jdbc.Driver" url="jdbc:mysql://xxxxx/xxxxxx" user="xxxxx" password="xxxxx" batchSize="-1" /> <document> <entity name="content" query="select content_id, description, title, add_date from content_solr where active = '1'"> <entity name="tag" query="select tag_id from tags_assoc where content_id '${content.content_id}'" /> <entity name="likes" query="select count(1) as likes from votes where content_id '${content.content_id}'" /> <entity name="views" query="select sum(views) as views from media_views mv join content_media cm USING (media_id) WHERE cm.content_id '${content.content_id}'" /> </entity> </document> </dataConfig> i'm triggering the import with: http://localhost:8983/solr/dataimport?command=full-import&clean=true&commit=true On Tue, May 15, 2012 at 2:07 PM, Michael Della Bitta < [EMAIL PROTECTED]> wrote: > Hi, Jon: > > Well, you don't see that every day! > > Is it possible that you have something weird going on in your DDL > and/or queries, like a tree schema that now suddenly has a cyclical > reference? > > Michael > > On Tue, May 15, 2012 at 4:33 PM, Jon Drukman <[EMAIL PROTECTED]> wrote: > > I have a machine which does a full update using DataImportHandler every > > hour. It worked up until a little while ago. I did not change the > > dataconfig.xml or version of Solr. > > > > Here is the beginning of the error in the log (the real thing runs for > > thousands of lines) > > > > 2012-05-15 12:44:30.724166500 SEVERE: Full Import > > failed:org.apache.solr.handler.dataimport.DataImportHandlerException: > > java.lang.StackOverflowError > > 2012-05-15 12:44:30.724168500 at > > > org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:669) > > 2012-05-15 12:44:30.724169500 at > > > org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:268) > > 2012-05-15 12:44:30.724171500 at > > > org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:187) > > 2012-05-15 12:44:30.724219500 at > > > org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:359) > > 2012-05-15 12:44:30.724221500 at > > > org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:427) > > 2012-05-15 12:44:30.724223500 at > > > org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:408) > > 2012-05-15 12:44:30.724224500 Caused by: java.lang.StackOverflowError > > 2012-05-15 12:44:30.724225500 at > > java.lang.String.checkBounds(String.java:404) > > 2012-05-15 12:44:30.724234500 at java.lang.String.<init>(String.java:450) > > 2012-05-15 12:44:30.724235500 at java.lang.String.<init>(String.java:523) > > 2012-05-15 12:44:30.724236500 at > > java.net.SocketOutputStream.socketWrite0(Native Method) > > 2012-05-15 12:44:30.724238500 at > > java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109) > > 2012-05-15 12:44:30.724239500 at > > java.net.SocketOutputStream.write(SocketOutputStream.java:153) > > 2012-05-15 12:44:30.724253500 at > > java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) > > 2012-05-15 12:44:30.724254500 at > > java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) > > 2012-05-15 12:44:30.724256500 at > > com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3345) > > 2012-05-15 12:44:30.724257500 at > > com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1983) > > 2012-05-15 12:44:30.724259500 at > > com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2163) > > 2012-05-15 12:44:30.724267500 at > > com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2618) > > 2012-05-15 12:44:30.724268500 at > > > com.mysql.jdbc.StatementImpl.executeSimpleNonQuery(StatementImpl.java:1644) > > 2012-05-15 12:44:30.724270500 at > > com.mysql.jdbc.RowDataDynamic.close(RowDataDynamic.java:198) > > 2012-05-15 12:44:30.724271500 at
-
RE: Exception in DataImportHandler (stack overflow)Dyer, James 2012-05-15, 21:35
Shot in the dark here, but try adding readOnly="true" to your dataSource tag.
<dataSource readOnly="true" type="JdbcDataSource" ... /> This sets autocommit to true and sets the Holdability to ResultSet.CLOSE_CURSORS_AT_COMMIT. DIH does not explicitly close resultsets and maybe if your JDBC driver also manages this poorly you could end up with strange conditions like the one you're getting? It could be a case where your data has grown just over the limit your setup can handle under such an unfortunate circumstance. Let me know if this solves it. If so, we probably should open a bug report and get this fixed in DIH. James Dyer E-Commerce Systems Ingram Content Group (615) 213-4311 -----Original Message----- From: Jon Drukman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 15, 2012 4:12 PM To: [EMAIL PROTECTED] Subject: Re: Exception in DataImportHandler (stack overflow) i don't think so, my config is straightforward: <dataConfig> <dataSource type="JdbcDataSource" driver="com.mysql.jdbc.Driver" url="jdbc:mysql://xxxxx/xxxxxx" user="xxxxx" password="xxxxx" batchSize="-1" /> <document> <entity name="content" query="select content_id, description, title, add_date from content_solr where active = '1'"> <entity name="tag" query="select tag_id from tags_assoc where content_id '${content.content_id}'" /> <entity name="likes" query="select count(1) as likes from votes where content_id '${content.content_id}'" /> <entity name="views" query="select sum(views) as views from media_views mv join content_media cm USING (media_id) WHERE cm.content_id '${content.content_id}'" /> </entity> </document> </dataConfig> i'm triggering the import with: http://localhost:8983/solr/dataimport?command=full-import&clean=true&commit=true On Tue, May 15, 2012 at 2:07 PM, Michael Della Bitta < [EMAIL PROTECTED]> wrote: > Hi, Jon: > > Well, you don't see that every day! > > Is it possible that you have something weird going on in your DDL > and/or queries, like a tree schema that now suddenly has a cyclical > reference? > > Michael > > On Tue, May 15, 2012 at 4:33 PM, Jon Drukman <[EMAIL PROTECTED]> wrote: > > I have a machine which does a full update using DataImportHandler every > > hour. It worked up until a little while ago. I did not change the > > dataconfig.xml or version of Solr. > > > > Here is the beginning of the error in the log (the real thing runs for > > thousands of lines) > > > > 2012-05-15 12:44:30.724166500 SEVERE: Full Import > > failed:org.apache.solr.handler.dataimport.DataImportHandlerException: > > java.lang.StackOverflowError > > 2012-05-15 12:44:30.724168500 at > > > org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:669) > > 2012-05-15 12:44:30.724169500 at > > > org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:268) > > 2012-05-15 12:44:30.724171500 at > > > org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:187) > > 2012-05-15 12:44:30.724219500 at > > > org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:359) > > 2012-05-15 12:44:30.724221500 at > > > org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:427) > > 2012-05-15 12:44:30.724223500 at > > > org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:408) > > 2012-05-15 12:44:30.724224500 Caused by: java.lang.StackOverflowError > > 2012-05-15 12:44:30.724225500 at > > java.lang.String.checkBounds(String.java:404) > > 2012-05-15 12:44:30.724234500 at java.lang.String.<init>(String.java:450) > > 2012-05-15 12:44:30.724235500 at java.lang.String.<init>(String.java:523) > > 2012-05-15 12:44:30.724236500 at > > java.net.SocketOutputStream.socketWrite0(Native Method) > > 2012-05-15 12:44:30.724238500 at > > java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109) > > 2012-05-15 12:44:30.724239500 at > > java.net.SocketOutputStream.write(SocketOutputStream.java:153)
-
Re: Exception in DataImportHandler (stack overflow)Jon Drukman 2012-05-15, 21:42
I fixed it for now by upping the wait_timeout on the mysql server.
Apparently Solr doesn't like having its connection yanked out from under it and/or isn't smart enough to reconnect if the server goes away. I'll set it back the way it was and try your readOnly option. Is there an option with DataImportHandler to have it transmit one or more arbitrary SQL statements after connecting? If there was, I could just send "SET wait_timeout=86400;" after connecting. That would probably prevent this issue. -jsd- On Tue, May 15, 2012 at 2:35 PM, Dyer, James <[EMAIL PROTECTED]>wrote: > Shot in the dark here, but try adding readOnly="true" to your dataSource > tag. > > <dataSource readOnly="true" type="JdbcDataSource" ... /> > > This sets autocommit to true and sets the Holdability to > ResultSet.CLOSE_CURSORS_AT_COMMIT. DIH does not explicitly close > resultsets and maybe if your JDBC driver also manages this poorly you could > end up with strange conditions like the one you're getting? It could be a > case where your data has grown just over the limit your setup can handle > under such an unfortunate circumstance. > > Let me know if this solves it. If so, we probably should open a bug > report and get this fixed in DIH. > > James Dyer > E-Commerce Systems > Ingram Content Group > (615) 213-4311 > > > -----Original Message----- > From: Jon Drukman [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 15, 2012 4:12 PM > To: [EMAIL PROTECTED] > Subject: Re: Exception in DataImportHandler (stack overflow) > > i don't think so, my config is straightforward: > > <dataConfig> > <dataSource type="JdbcDataSource" driver="com.mysql.jdbc.Driver" > url="jdbc:mysql://xxxxx/xxxxxx" > user="xxxxx" password="xxxxx" batchSize="-1" /> > <document> > <entity name="content" > query="select content_id, description, title, add_date from > content_solr where active = '1'"> > <entity name="tag" > query="select tag_id from tags_assoc where content_id > '${content.content_id}'" /> > <entity name="likes" > query="select count(1) as likes from votes where content_id > '${content.content_id}'" /> > <entity name="views" > query="select sum(views) as views from media_views mv join > content_media cm USING (media_id) WHERE cm.content_id > '${content.content_id}'" /> > </entity> > </document> > </dataConfig> > > i'm triggering the import with: > > http://localhost:8983/solr/dataimport?command=full-import&clean=true&commit=true > > > > On Tue, May 15, 2012 at 2:07 PM, Michael Della Bitta < > [EMAIL PROTECTED]> wrote: > > > Hi, Jon: > > > > Well, you don't see that every day! > > > > Is it possible that you have something weird going on in your DDL > > and/or queries, like a tree schema that now suddenly has a cyclical > > reference? > > > > Michael > > > > On Tue, May 15, 2012 at 4:33 PM, Jon Drukman <[EMAIL PROTECTED]> wrote: > > > I have a machine which does a full update using DataImportHandler every > > > hour. It worked up until a little while ago. I did not change the > > > dataconfig.xml or version of Solr. > > > > > > Here is the beginning of the error in the log (the real thing runs for > > > thousands of lines) > > > > > > 2012-05-15 12:44:30.724166500 SEVERE: Full Import > > > failed:org.apache.solr.handler.dataimport.DataImportHandlerException: > > > java.lang.StackOverflowError > > > 2012-05-15 12:44:30.724168500 at > > > > > > org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:669) > > > 2012-05-15 12:44:30.724169500 at > > > > > > org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:268) > > > 2012-05-15 12:44:30.724171500 at > > > > > > org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:187) > > > 2012-05-15 12:44:30.724219500 at > > > > > > org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:359) > > > 2012-05-15 12:44:30.724221500 at > > > > > > org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:427)
-
Re: Exception in DataImportHandler (stack overflow)Jon Drukman 2012-05-15, 23:10
OK, setting the wait_timeout back to its previous value and adding readOnly
didn't help, I got the stack overflow again. I re-upped the mysql timeout value again. -jsd- On Tue, May 15, 2012 at 2:42 PM, Jon Drukman <[EMAIL PROTECTED]> wrote: > I fixed it for now by upping the wait_timeout on the mysql server. > Apparently Solr doesn't like having its connection yanked out from under > it and/or isn't smart enough to reconnect if the server goes away. I'll > set it back the way it was and try your readOnly option. > > Is there an option with DataImportHandler to have it transmit one or more > arbitrary SQL statements after connecting? If there was, I could just send > "SET wait_timeout=86400;" after connecting. That would probably prevent > this issue. > > -jsd- > > On Tue, May 15, 2012 at 2:35 PM, Dyer, James <[EMAIL PROTECTED]>wrote: > >> Shot in the dark here, but try adding readOnly="true" to your dataSource >> tag. >> >> <dataSource readOnly="true" type="JdbcDataSource" ... /> >> >> This sets autocommit to true and sets the Holdability to >> ResultSet.CLOSE_CURSORS_AT_COMMIT. DIH does not explicitly close >> resultsets and maybe if your JDBC driver also manages this poorly you could >> end up with strange conditions like the one you're getting? It could be a >> case where your data has grown just over the limit your setup can handle >> under such an unfortunate circumstance. >> >> Let me know if this solves it. If so, we probably should open a bug >> report and get this fixed in DIH. >> >> James Dyer >> E-Commerce Systems >> Ingram Content Group >> (615) 213-4311 >> >> >> -----Original Message----- >> From: Jon Drukman [mailto:[EMAIL PROTECTED]] >> Sent: Tuesday, May 15, 2012 4:12 PM >> To: [EMAIL PROTECTED] >> Subject: Re: Exception in DataImportHandler (stack overflow) >> >> i don't think so, my config is straightforward: >> >> <dataConfig> >> <dataSource type="JdbcDataSource" driver="com.mysql.jdbc.Driver" >> url="jdbc:mysql://xxxxx/xxxxxx" >> user="xxxxx" password="xxxxx" batchSize="-1" /> >> <document> >> <entity name="content" >> query="select content_id, description, title, add_date from >> content_solr where active = '1'"> >> <entity name="tag" >> query="select tag_id from tags_assoc where content_id >> '${content.content_id}'" /> >> <entity name="likes" >> query="select count(1) as likes from votes where content_id >> '${content.content_id}'" /> >> <entity name="views" >> query="select sum(views) as views from media_views mv join >> content_media cm USING (media_id) WHERE cm.content_id >> '${content.content_id}'" /> >> </entity> >> </document> >> </dataConfig> >> >> i'm triggering the import with: >> >> http://localhost:8983/solr/dataimport?command=full-import&clean=true&commit=true >> >> >> >> On Tue, May 15, 2012 at 2:07 PM, Michael Della Bitta < >> [EMAIL PROTECTED]> wrote: >> >> > Hi, Jon: >> > >> > Well, you don't see that every day! >> > >> > Is it possible that you have something weird going on in your DDL >> > and/or queries, like a tree schema that now suddenly has a cyclical >> > reference? >> > >> > Michael >> > >> > On Tue, May 15, 2012 at 4:33 PM, Jon Drukman <[EMAIL PROTECTED]> >> wrote: >> > > I have a machine which does a full update using DataImportHandler >> every >> > > hour. It worked up until a little while ago. I did not change the >> > > dataconfig.xml or version of Solr. >> > > >> > > Here is the beginning of the error in the log (the real thing runs for >> > > thousands of lines) >> > > >> > > 2012-05-15 12:44:30.724166500 SEVERE: Full Import >> > > failed:org.apache.solr.handler.dataimport.DataImportHandlerException: >> > > java.lang.StackOverflowError >> > > 2012-05-15 12:44:30.724168500 at >> > > >> > >> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:669) >> > > 2012-05-15 12:44:30.724169500 at >> > > >> > >> org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:268)
-
Re: Exception in DataImportHandler (stack overflow)Shawn Heisey 2012-05-17, 20:55
On 5/15/2012 3:42 PM, Jon Drukman wrote:
> I fixed it for now by upping the wait_timeout on the mysql server. > Apparently Solr doesn't like having its connection yanked out from under > it and/or isn't smart enough to reconnect if the server goes away. I'll > set it back the way it was and try your readOnly option. I use DIH with MySQL. The only time I ran into timeouts while importing was related to segment merging. A first level merge happens when the number of segments reaches mergeFactor. A second level merge happens when the number of merged segments reaches mergeFactor. A third level merge happens when you get enough segments created by second level merges. It's probably possible for this to extend to fourth level and beyond, though I have not seen that personally. When there are multiple merges happening at the same time (on 3.4 and earlier, 3.5 may have changed this), only one of them actually runs, the others are paused. Eventually, if you have a slow I/O system (SATA RAID1 or slower) and a big enough index, your full-import can reach a state where you have all three levels happening at the same time. When this happens, indexing stops. If it stops for long enough, the server will close the connection and DIH will fail once it begins indexing again. Since my DIH config consists of a single SELECT statement that runs for the entire three hour duration of the import, adding reconnect capability to DIH would not help. The only way to make it work right is to configure things such that Solr never stops indexing. I did this by increasing my mergeFactor, and when I installed Solr 3.5, used maxMergeAtOnce, segmentsPerTier, and maxMergeAtOnceExplicit. I also increased maxMergeCount under mergeScheduler. Here's my current indexDefaults section: <indexDefaults> <useCompoundFile>false</useCompoundFile> <mergePolicy class="org.apache.lucene.index.TieredMergePolicy"> <int name="maxMergeAtOnce">35</int> <int name="segmentsPerTier">35</int> <int name="maxMergeAtOnceExplicit">105</int> </mergePolicy> <mergeScheduler class="org.apache.lucene.index.ConcurrentMergeScheduler"> <int name="maxMergeCount">4</int> </mergeScheduler> <ramBufferSizeMB>128</ramBufferSizeMB> <maxFieldLength>32768</maxFieldLength> <writeLockTimeout>1000</writeLockTimeout> <commitLockTimeout>10000</commitLockTimeout> <lockType>native</lockType> </indexDefaults> Thanks, Shawn
-
RE: Exception in DataImportHandler (stack overflow)Dyer, James 2012-05-17, 21:01
Shawn,
Do you think this behavior is because, while the indexing is paused, you reach some type of timeout so either your db or the jdbc cuts the connection? Or, ar you thinking something in the DIH/JDBCDataSource code is causing the connection to drop under these circumstances? James Dyer E-Commerce Systems Ingram Content Group (615) 213-4311 -----Original Message----- From: Shawn Heisey [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 17, 2012 3:56 PM To: [EMAIL PROTECTED] Subject: Re: Exception in DataImportHandler (stack overflow) On 5/15/2012 3:42 PM, Jon Drukman wrote: > I fixed it for now by upping the wait_timeout on the mysql server. > Apparently Solr doesn't like having its connection yanked out from under > it and/or isn't smart enough to reconnect if the server goes away. I'll > set it back the way it was and try your readOnly option. I use DIH with MySQL. The only time I ran into timeouts while importing was related to segment merging. A first level merge happens when the number of segments reaches mergeFactor. A second level merge happens when the number of merged segments reaches mergeFactor. A third level merge happens when you get enough segments created by second level merges. It's probably possible for this to extend to fourth level and beyond, though I have not seen that personally. When there are multiple merges happening at the same time (on 3.4 and earlier, 3.5 may have changed this), only one of them actually runs, the others are paused. Eventually, if you have a slow I/O system (SATA RAID1 or slower) and a big enough index, your full-import can reach a state where you have all three levels happening at the same time. When this happens, indexing stops. If it stops for long enough, the server will close the connection and DIH will fail once it begins indexing again. Since my DIH config consists of a single SELECT statement that runs for the entire three hour duration of the import, adding reconnect capability to DIH would not help. The only way to make it work right is to configure things such that Solr never stops indexing. I did this by increasing my mergeFactor, and when I installed Solr 3.5, used maxMergeAtOnce, segmentsPerTier, and maxMergeAtOnceExplicit. I also increased maxMergeCount under mergeScheduler. Here's my current indexDefaults section: <indexDefaults> <useCompoundFile>false</useCompoundFile> <mergePolicy class="org.apache.lucene.index.TieredMergePolicy"> <int name="maxMergeAtOnce">35</int> <int name="segmentsPerTier">35</int> <int name="maxMergeAtOnceExplicit">105</int> </mergePolicy> <mergeScheduler class="org.apache.lucene.index.ConcurrentMergeScheduler"> <int name="maxMergeCount">4</int> </mergeScheduler> <ramBufferSizeMB>128</ramBufferSizeMB> <maxFieldLength>32768</maxFieldLength> <writeLockTimeout>1000</writeLockTimeout> <commitLockTimeout>10000</commitLockTimeout> <lockType>native</lockType> </indexDefaults> Thanks, Shawn
-
Re: Exception in DataImportHandler (stack overflow)Shawn Heisey 2012-05-17, 21:47
On 5/17/2012 3:01 PM, Dyer, James wrote:
> Do you think this behavior is because, while the indexing is paused, you reach some type of timeout so either your db or the jdbc cuts the connection? Or, ar you thinking something in the DIH/JDBCDataSource code is causing the connection to drop under these circumstances? I'm almost positive that it's the db or jdbc that cuts the connection, probably the former. The last time I ran into it (which was before Solr 3.5), Solr's indexing was paused for eight minutes while merges finished, and I think we have a five minute timeout. I don't think I saw the same exception that Jon is seeing, but I don't have a record, so I can't check. My test server is SATA RAID1, and I have also done some indexing onto a USB2/SATA drive, which is SLOW. I've never run into the timeout problem on my production system, but those machines are running six 1TB drives in RAID10. Lots of IOPS. With an effective mergeFactor of 35, I merge much less often and I never see a third-level merge. I haven't calculated how big my index has to get before I will see a third level merge, but with my settings (see below, because I modified the config snippet I pasted in earlier) I should keep indexing even with three merges happening. Solr 3.6 API for ConcurrentMergeScheduler: http://bit.ly/JNmNY4 I did remove one line from my indexDefaults that I pasted in - I also set maxThreadCount to 4, even though I am not doing a multithreaded DIH. I removed it because I thought it might be confusing to have it there. Turns out that was a bad idea. After looking at the 3.6 source code for ConcurrentMergeScheduler, I believe that maxThreadCount is required, but maxMergeCount defaults to maxThreadCount plus two, so it actually would not be required, as long as maxThreadCount is set to at least 4. Without the explicit configuration, maxThreadCount would default to three or less, depending on how many CPUs you have. private int maxThreadCount = Math.max(1, Math.min (3, Runtime.getRuntime().availableProcessors()/2)); private int maxMergeCount = maxThreadCount+2; <indexDefaults> <useCompoundFile>false</useCompoundFile> <mergePolicy class="org.apache.lucene.index.TieredMergePolicy"> <int name="maxMergeAtOnce">35</int> <int name="segmentsPerTier">35</int> <int name="maxMergeAtOnceExplicit">105</int> </mergePolicy> <mergeScheduler class="org.apache.lucene.index.ConcurrentMergeScheduler"> <int name="maxMergeCount">4</int> <int name="maxThreadCount">4</int> </mergeScheduler> <ramBufferSizeMB>128</ramBufferSizeMB> <maxFieldLength>32768</maxFieldLength> <writeLockTimeout>1000</writeLockTimeout> <commitLockTimeout>10000</commitLockTimeout> <lockType>native</lockType> </indexDefaults> |