svn error E21004 Malformed network data

[Svend Hansen]

When running a big import, I've gotten this error quite a few times:

IMPORT FAILED
error: svn: E210004: Malformed network data

As far as I can understand it has something to do with svn not responding properly, in time or giving a timeout, etc.

Every time, all I need to do is rerun the import command, however, it often means missing out on the import running over night or a weekend.

I'm considering writing a script that will check the exit code of the import, and if it's non-zero it would re-run the import automatically. However, I'm not sure if there are other cases where it might fail and rerunning would be bad, or just fail immediately causing an infinite loop of retries.

Wouldn't it be possible to catch these types of svn errors somewhere in the tool, and handle them in a robust way by just retrying the commands that failed?

Would be great if it was possible for it to run more reliably for long periods :)

Cheers,

   Svend.

[TMate Software Support]

Hello Svend,

SubGit already performs 3 retries in such cases like this one and fails only if all of them fail. At the moment this number "3" is not configurable.

Does retrying import solves the problem in your case (i.e. after N restarts import translates at least something) or is it just your suggestion that it could help?

If it helps, you will not get the infinite loop of retries. If it doesn't, it's worth looking at the revision for which the problem happens: it might have too much changes regardless of the number of retries.

Dmitry Pavlenko,

TMate Software,

http://tmatesoft.com/ git-svn import & mirror

--
You received this message because you are subscribed to the Google Groups "SubGit Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subgit-users+unsubscribe@googlegroups.com.
To post to this group, send email to subgit...@googlegroups.com.
Visit this group at https://groups.google.com/group/subgit-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/subgit-users/7620195e-6444-4847-b172-9b610805894d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Svend Hansen]

Hello Dmitry,

It has always worked immediately when I start it again, but all the times it has failed have been after I'd gone home (for the night or weekend), so there's been a long break between the error and the retry. I don't know how long it would have taken before a retry would succeed. From what you say, I understand SubGit does three retries, and I presume these are immediate? It's possible that retrying 100 times would also fail, if each retry was performed immediately following the error. I would have to do more experiments to find out (I guess I can just pull my ethernet cable to test it).

I guess there's not much else you can do, except if the number of retries was configurable, though maybe it would have to be possible to set it to "infinite retry" to ensure that it works, and then you'd never get an error if the cable did fall out (or connection was otherwise permanently broken).

I guess you'd know better what solutions are possible and what's more likely to be useful for more people :)

Cheers,

   Svend.

On Thursday, 14 September 2017 13:07:51 UTC+2, TMate Software Support wrote:

Hello Svend,

SubGit already performs 3 retries in such cases like this one and fails only if all of them fail. At the moment this number "3" is not configurable.

Does retrying import solves the problem in your case (i.e. after N restarts import translates at least something) or is it just your suggestion that it could help?

If it helps, you will not get the infinite loop of retries. If it doesn't, it's worth looking at the revision for which the problem happens: it might have too much changes regardless of the number of retries.

Dmitry Pavlenko,

TMate Software,

http://tmatesoft.com/ git-svn import & mirror

[TMate Software Support]

Hello Svend,
These 3 retries are immediate.

I have one more idea to try. There's an option:
[svn]
  httpSpooling = true

Without the option SubGit reacts to XML response immediately when it receives this or that tag. This may slow down the response processing and the server may cut the connection because of timeout.

When the option is set, SubGit records the XML response as is to filesystem and starts processing it only upon receiving. This often helps in case of network problems.

Dmitry Pavlenko,

TMate Software,

http://tmatesoft.com/ git-svn import & mirror

To view this discussion on the web visit https://groups.google.com/d/msgid/subgit-users/d0452555-2571-442c-a734-444180833a8d%40googlegroups.com.