Has anyone seen this error?  It seems to happen once I get a decent amount of data into my db.  It worked this morning when I had a small subset of my county's TIGER data, but now I imported the full county and it won't dump successfully.  It also happened with 

v0.5, so it isn't a new thing.<br><br>I definitely think mysql is to blame, but there isn't much on google about this error.<br><br>-Al<br><br>Exception in thread "Thread-1-read-mysql" com.bretth.osmosis.OsmosisRuntimeException

: Unable to move to next record.<br>        at com.bretth.osmosis.mysql.impl.EntityReader.readNextValue(EntityReader.java:79)<br>        at com.bretth.osmosis.mysql.impl.EntityReader.next(EntityReader.java:144)<br>        at 

com.bretth.osmosis.mysql.MysqlReader.processWays(MysqlReader.java:129)<br>        at com.bretth.osmosis.mysql.MysqlReader.run(MysqlReader.java:168)<br>        at java.lang.Thread.run(Thread.java:619)<br>Caused by: com.mysql.jdbc.CommunicationsException

: Communications link failure due to underlying exception:  ** BEGIN NESTED EXCEPTION **  java.io.EOFException MESSAGE: Can not read response from server. Expected to read 4 bytes, read 1 bytes before connection was unexpectedly lost.

<br><br>STACKTRACE:<br><br>java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 1 bytes before connection was unexpectedly lost.<br>        at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java

:1997)<br>        at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2411)<br>        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2916)<br>        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java

:885)<br>        at com.mysql.jdbc.MysqlIO.nextRow(MysqlIO.java:1360)<br>        at com.mysql.jdbc.RowDataDynamic.nextRecord(RowDataDynamic.java:366)<br>        at com.mysql.jdbc.RowDataDynamic.next(RowDataDynamic.java:355)

<br>        at com.mysql.jdbc.ResultSet.next(ResultSet.java:7302)<br>        at com.bretth.osmosis.mysql.impl.EntityReader.readNextValue(EntityReader.java:72)<br>        at com.bretth.osmosis.mysql.impl.EntityReader.next(

EntityReader.java:144)<br>        at com.bretth.osmosis.mysql.MysqlReader.processWays(MysqlReader.java:129)<br>        at com.bretth.osmosis.mysql.MysqlReader.run(MysqlReader.java:168)<br>        at java.lang.Thread.run(Thread.java

:619)<br><br><br>** END NESTED EXCEPTION **<br><br><br><br>Last packet sent to the server was 435582 ms ago.<br>        at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2622)<br>        at com.mysql.jdbc.MysqlIO.checkErrorPacket

(MysqlIO.java:2916)<br>        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:885)<br>        at com.mysql.jdbc.MysqlIO.nextRow(MysqlIO.java:1360)<br>        at com.mysql.jdbc.RowDataDynamic.nextRecord(RowDataDynamic.java

:366)<br>        at com.mysql.jdbc.RowDataDynamic.next(RowDataDynamic.java:355)<br>        at com.mysql.jdbc.ResultSet.next(ResultSet.java:7302)<br>        at com.bretth.osmosis.mysql.impl.EntityReader.readNextValue(EntityReader.java

:72)<br>        ... 4 more<br><br><br><div><span class="gmail_quote">On 8/2/07, <b class="gmail_sendername">Brett Henderson</b> <<a href="mailto:brett@bretth.com">brett@bretth.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Dave Stubbs wrote:<br>> Ah, yes, that makes sense. Thanks.<br>><br>> I'm not in any hurry. I can continue using the hacked up "My 1st Rails<br>> Hack" map created using JOSM using nodes segments and ways. The "M" is

> a motorway and the "1" is oneway residential if anyone is > interested... I've even underlined the lot with a river. :-) > Well, that didn't take as long as I thought. This should do the trick ...

<br><a href="http://www.bretth.com/osmosis/osmosis-latest.zip">http://www.bretth.com/osmosis/osmosis-latest.zip</a><br><br>It creates a new user with email address "<a href="mailto:osmosis@bretth.com">osmosis@bretth.com

</a>" (hardcoded<br>for now) which will be used for all edits.<br><br>Overview here:<br><a href="http://wiki.openstreetmap.org/index.php/Osmosis">http://wiki.openstreetmap.org/index.php/Osmosis</a><br><br>Full command line details here (must migrate this to OSM wiki one of

<br>these days):<br><a href="http://www.bretth.com/wiki/Wiki.jsp?page=OpenStreetMap">http://www.bretth.com/wiki/Wiki.jsp?page=OpenStreetMap</a><br><br>If you want to import the whole planet though, patience will be<br>required.  You're looking at around 4 hours for the import, 3 hours of

<br>which seem to be populating the "current" tables.  If anybody has any<br>relatively straightforward suggestions on increasing the speed of<br>copying data into InnoDB tables I'm all ears.  No simple way of

<br>disabling indexes (that I can find), and I have to chunk into<br>"reasonable" sized transactions or nasty runaway rollbacks will occur if<br>the process is interrupted.<br><br>If you want to limit the size of the import, try using the

<br>--bounding-box task to extract the area you want (I often use Australia<br>for testing, approx 120MB).  If dates aren't important, you can further<br>speed things up by applying the enableDateParsing=no option to the

<br>--read-xml task.<br><br>I'm currently running an import on the August 25 planet to test it<br>properly but it will take a while to finish.<br><br><br><br>_______________________________________________<br>dev mailing list

<br><a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br><a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev</a><br></blockquote>

</div><br>