2

削減部分のcassandraキースペースに接続するHadoopプロセスがあります。データはplayORMによって保存されます。何が起こるか：私はこのhadoopプロセスとcassandraを同じマシンで実行しているので、playORMはローカルホスト上のcassandraに接続するだけです。少量のデータを処理する場合、プロセスは完全に正常に実行されますが、大量のデータ（この場合は50万レコードのみ）を処理すると、次の例外が発生します。astyanaxプール構成（playORMによって行われるため、これらの設定を変更する方法がわかりません）に問題があるのでしょうか、それともplayORM自体またはCassandra構成に問題があるのでしょうか。現在、すべてが単一のホストで実行されており、クラスターを構成すると、多くのHadoopマシンが多くのcassandraマシンに接続するため、状況が悪化する可能性があると思います。

何が間違っているのかについてのヒントはありますか？

CF=[tablename=Localization] persist rowkey=1bd9b46a-5b66-41ae-9756-dd91f44194ea
CF=User index persist(cf=[tablename=User])=[rowkey=/User/id] (table found, colmeta not found)
CF=[tablename=User] persist rowkey=1bd9b46a-5b66-41ae-9756-dd91f44194ea
java.lang.RuntimeException: com.netflix.astyanax.connectionpool.exceptions.ConnectionAbortedException: ConnectionAbortedException: [host=localhost(127.0.0.1):9160, latency=611(611), attempts=1] org.apache.thrift.t
ransport.TTransportException: java.net.SocketException: Connection reset
        at com.alvazan.orm.layer9z.spi.db.cassandra.CassandraSession.sendChanges(CassandraSession.java:110)
        at com.alvazan.orm.logging.NoSqlRawLogger.sendChanges(NoSqlRawLogger.java:50)
        at com.alvazan.orm.layer5.nosql.cache.NoSqlWriteCacheImpl.flush(NoSqlWriteCacheImpl.java:125)
        at com.alvazan.orm.layer5.nosql.cache.NoSqlReadCacheImpl.flush(NoSqlReadCacheImpl.java:178)
        at com.alvazan.orm.layer0.base.BaseEntityManagerImpl.flush(BaseEntityManagerImpl.java:182)
        at com.s1mbi0se.dmp.da.dao.UserDao.insertOrUpdateUser(UserDao.java:24)
        at com.s1mbi0se.dmp.da.dao.UserDao.insertOrUpdateUserLocalization(UserDao.java:75)
        at com.s1mbi0se.dmp.da.service.DataAccessService.insertLocalizationForUser(DataAccessService.java:44)
        at com.s1mbi0se.dmp.module.LocalizationModule.persistData(LocalizationModule.java:218)
        at com.s1mbi0se.dmp.processor.mapred.SelectorReducer.reduce(SelectorReducer.java:60)
        at com.s1mbi0se.dmp.processor.mapred.SelectorReducer.reduce(SelectorReducer.java:1)
        at org.apache.hadoop.mapreduce.Reducer.run(Reducer.java:176)
        at org.apache.hadoop.mapred.ReduceTask.runNewReducer(ReduceTask.java:649)
        at org.apache.hadoop.mapred.ReduceTask.run(ReduceTask.java:417)
        at org.apache.hadoop.mapred.LocalJobRunner$Job.run(LocalJobRunner.java:260)
Caused by: com.netflix.astyanax.connectionpool.exceptions.ConnectionAbortedException: ConnectionAbortedException: [host=localhost(127.0.0.1):9160, latency=611(611), attempts=1] org.apache.thrift.transport.TTranspo
rtException: java.net.SocketException: Connection reset
        at com.netflix.astyanax.thrift.ThriftConverter.ToConnectionPoolException(ThriftConverter.java:193)
        at com.netflix.astyanax.thrift.AbstractOperationImpl.execute(AbstractOperationImpl.java:60)
        at com.netflix.astyanax.thrift.AbstractOperationImpl.execute(AbstractOperationImpl.java:27)
        at com.netflix.astyanax.thrift.ThriftSyncConnectionFactoryImpl$1.execute(ThriftSyncConnectionFactoryImpl.java:131)
        at com.netflix.astyanax.connectionpool.impl.AbstractExecuteWithFailoverImpl.tryOperation(AbstractExecuteWithFailoverImpl.java:52)
        at com.netflix.astyanax.connectionpool.impl.AbstractHostPartitionConnectionPool.executeWithFailover(AbstractHostPartitionConnectionPool.java:229)
        at com.netflix.astyanax.thrift.ThriftKeyspaceImpl.executeOperation(ThriftKeyspaceImpl.java:455)
        at com.netflix.astyanax.thrift.ThriftKeyspaceImpl.access$400(ThriftKeyspaceImpl.java:62)
        at com.netflix.astyanax.thrift.ThriftKeyspaceImpl$1.execute(ThriftKeyspaceImpl.java:115)
        at com.alvazan.orm.layer9z.spi.db.cassandra.CassandraSession.sendChangesImpl(CassandraSession.java:131)
        at com.alvazan.orm.layer9z.spi.db.cassandra.CassandraSession.sendChanges(CassandraSession.java:108)
        ... 14 more
Caused by: org.apache.thrift.transport.TTransportException: java.net.SocketException: Connection reset
        at org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:129)
        at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
        at org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.java:129)
        at org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:101)
        at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
        at org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:378)
        at org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:297)
        at org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:204)
        at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:69)
        at org.apache.cassandra.thrift.Cassandra$Client.recv_batch_mutate(Cassandra.java:913)
        at org.apache.cassandra.thrift.Cassandra$Client.batch_mutate(Cassandra.java:899)
        at com.netflix.astyanax.thrift.ThriftKeyspaceImpl$1$1.internalExecute(ThriftKeyspaceImpl.java:121)
        at com.netflix.astyanax.thrift.ThriftKeyspaceImpl$1$1.internalExecute(ThriftKeyspaceImpl.java:118)
        at com.netflix.astyanax.thrift.AbstractOperationImpl.execute(AbstractOperationImpl.java:55)
        ... 23 more
Caused by: java.net.SocketException: Connection reset
        at java.net.SocketInputStream.read(Unknown Source)
        at java.net.SocketInputStream.read(Unknown Source)
        at org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:127)
        ... 36 more
4

1 に答える 1

2

注：私もこれに一度遭遇し、astyanaxのタイムアウトまたは接続プールのサイズを上げたと思いますが、それは消えたので、それも試してみてください（ただし、接続のリセットは一般的にファーサーバーの障害です...つまりcassandra）。

確かに接続がリセットされるのは、通常、相手側 (cassandra) が接続を閉じたためです。100% 確実にするには、wireshark を実行する場合、どちらの端がソケットを閉じているかを確認する必要があります。

ここでこの投稿を読むことに注意してください...

java.net.SocketException: 接続のリセット

でも基本的にminやnetty等が存在する前にsourceforgeでchannelmanagerを書いていました。ほとんどの場合、もう一方の端が適切にソケットを閉じると、-1 が返されます。彼らはいくつかのパケットを送信する必要があります。それらが消えただけの場合、接続のリセットなどのきちんとした例外が発生する可能性があります。

astyanax 接続プールをいじることをお勧めします。ただし、wireshark を見て、tcp ティアダウンがどのように発生するかをググって、cassandra が適切にティアダウンしなかったかどうかを確認してください。

Linux を使用している場合は、netstat -anp | を試してください。grep {pid} を実行すると、クライアント プロセスが使用しているポートを確認し、Wireshark でそれらのパケットを探すことができます。また、astyanax がプールを正しく維持していることを確認するテストを行います。つまり、プロセス中に netstat コマンドを数回実行して、astyanax がソケットを作成していないことを確認し、それらを削除してから再度作成します (1 つを削除したかのように)。次に、それに書き込むと、上記のエラーが発生する可能性があります）

Java nio のものは、カバーの下で完全に信頼できるものではありませんでした...今日まで、さまざまな OS の nio ライブラリのバグを示す単体テストがまだあります。

好奇心から、書き込みを行っていることに気づき、書き込みが成功したかどうかにかかわらず、読み取りは基本的にステータスの取得に失敗したため、パイプをどれだけフラッシュしていますか。

今後数か月以内に、マップ/リデュース コードに実際のエンティティをフィードする汎用のマップ/リデュースを作成したいと考えています。私たちは最終的に新しい開発者を見つけ、仕事を手伝ってくれる新しい開発者にオファーを送信しています。

読むべき別の良い投稿はこれです

http://kb.realvnc.com/questions/75/I%27m+recoming+the+error+%22Connection+reset+by+peer+%2810054%29%22.+

Wireshark は、tcp レイヤーで何が起こったのかを詳細に教えてくれます。astyanax か cassandra のせいか、もっと詳しく調べるつもりだったのですが、時間がありませんでした。

ディーン

于 2012-11-09T20:14:05.217 に答える