manifoldcf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Wright (JIRA)" <>
Subject [jira] [Commented] (CONNECTORS-1312) jcifs.smb.SmbException: Connection reset by peer: socket write error
Date Wed, 04 May 2016 21:49:12 GMT


Karl Wright commented on CONNECTORS-1312:

"Connection reset by peer" sounds like something we can look for and retry on.  However, this
may also mean: (1) you are crawling your server too hard.  We recommend that you reduce the
maximum number of connections for JCIFS to the point where you don't get funky errors like
this all over the place; (2) you might have a network switch which disconnects after a certain
period of time reading data, or when you transfer too large a file.  Saw that in a couple
of installations...

> jcifs.smb.SmbException: Connection reset by peer: socket write error
> --------------------------------------------------------------------
>                 Key: CONNECTORS-1312
>                 URL:
>             Project: ManifoldCF
>          Issue Type: Bug
>          Components: JCIFS connector
>    Affects Versions: ManifoldCF 2.5
>         Environment: Windows x64, java 1.8.x
>            Reporter: Konstantin Avdeev
> hi Karl,
> we've found another JCIFS exception: Windows share jobs stop when encountering a "Connection
reset by peer" error, e.g.:
> {code}
> ERROR 2016-05-03 15:29:24,209 (Worker thread '80') - JCIFS: SmbException tossed processing
> jcifs.smb.SmbException: Connection reset by peer: socket write error
> Connection reset by peer: socket write error
> 	at Method)
> 	at
> 	at
> 	at jcifs.smb.SmbTransport.doSend(
> 	at jcifs.util.transport.Transport.sendrecv(
> 	at jcifs.smb.SmbTransport.send(
> 	at jcifs.smb.SmbSession.send(
> 	at jcifs.smb.SmbTree.send(
> 	at jcifs.smb.SmbFile.send(
> 	at jcifs.smb.SmbFileInputStream.readDirect(
> 	at
> 	at
> 	at
> 	at
> 	at java.nio.file.Files.copy(
> 	at java.nio.file.Files.copy(
> 	at
> 	at
> 	at
> 	at
> 	at org.apache.tika.detect.CompositeDetector.detect(
> 	at org.apache.tika.parser.AutoDetectParser.parse(
> 	at org.apache.manifoldcf.agents.transformation.tika.TikaParser.parse(
> 	at org.apache.manifoldcf.agents.transformation.tika.TikaExtractor.addOrReplaceDocumentWithException(
> 	at org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester$PipelineAddEntryPoint.addOrReplaceDocumentWithException(
> 	at org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester$PipelineAddFanout.sendDocument(
> 	at org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester$PipelineObjectWithVersions.addOrReplaceDocumentWithException(
> 	at org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester.documentIngest(
> 	at org.apache.manifoldcf.crawler.system.WorkerThread$ProcessActivity.ingestDocumentWithException(
> 	at org.apache.manifoldcf.crawler.system.WorkerThread$ProcessActivity.ingestDocumentWithException(
> 	at org.apache.manifoldcf.crawler.connectors.sharedrive.SharedDriveConnector.processDocuments(
> 	at
> {code}
> Current workaround - to start the job again (manually or by the scheduler).
> It is clear, that there are many errors, when it makes no sense to skip a failed URL
and continue the job, e.g.:
> {code}
> Error: SmbAuthException thrown: Logon failure: unknown user name or bad password.
> {code}
> I'm thinking about a general solution, like defining a list (through the UI or properties.xml)
with non severe exceptions, like "file busy" or "symlink detected" etc, so the admins would
be able to specify, when the crawler should stop and when it should retry, skip and go further.
> What do you think?
> Thank you!

This message was sent by Atlassian JIRA

View raw message