Akka .NET连接池超时问题

时间:2017-04-20 13:39:26

标签: sql-server akka.net akka.net-cluster akka.net-persistence

我们正在使用Akka.NET创建一个新系统,并且具有基于分片和持久性的基本群集设置。

我们使用官方文档以及一些Petabridge博客文章来使分片正常工作。但是,我们遇到了分片超过SQL Server连接池允许的最大连接数的问题。因此,我们收到以下消息......

  

2017-04-20 14:04:31.433 +01:00 [警告]"超时已过期。该   从池中获取连接之前经过的超时时间。   这可能是因为所有池连接都在使用中   已达到最大池大小。"

我们相信当分片更新分片日记时会发生这种情况。

为什么分片模块没有正确管理其SQL连接?这里有配置问题吗?

发生此类错误时是否可以重试?目前我们丢失了每个错误实例的消息。

这是相关的HOCON

cluster.sharding {
    journal-plugin-id = "akka.persistence.journal.sharding"
    snapshot-plugin-id = "akka.persistence.snapshot-store.sharding"
}
persistence {
    journal {
        plugin = "akka.persistence.journal.sql-server"
        sql-server {
            class = "Akka.Persistence.SqlServer.Journal.SqlServerJournal, Akka.Persistence.SqlServer"
            connection-string = "Server=.;Database=akkasystem;Integrated Security=true"
            schema-name = dbo
            auto-initialize = on
        }
        # a separate config used by cluster sharding only 
        sharding {
            connection-string = "Server=.;Database=akkasystem;Integrated Security=true"
            auto-initialize = on
            plugin-dispatcher = "akka.actor.default-dispatcher"
            class = "Akka.Persistence.SqlServer.Journal.SqlServerJournal, Akka.Persistence.SqlServer"
            connection-timeout = 30s
            schema-name = dbo
            table-name = ShardingJournal
            timestamp-provider = "Akka.Persistence.Sql.Common.Journal.DefaultTimestampProvider, Akka.Persistence.Sql.Common"
            metadata-table-name = ShardingMetadata
        }
    }
    snapshot-store {
        sharding {
            class = "Akka.Persistence.SqlServer.Snapshot.SqlServerSnapshotStore, Akka.Persistence.SqlServer"
            plugin-dispatcher = "akka.actor.default-dispatcher"
            connection-string = "Server=.;Database=akkasystem;Integrated Security=true"
            connection-timeout = 30s
            schema-name = dbo
            table-name = ShardingSnapshotStore
            auto-initialize = on
        }
    }
}

1 个答案:

答案 0 :(得分:1)

这可能表明SQL日志充斥着传入的事件,连接超时会触发,而事件正在等待池中的下一个连接被释放。

从我的配置中我怀疑,如果您已经开始持续发生事件并创建具有高比率的分片/实体,则可能会发生这种情况。现有的SQL期刊在不久的将来会得到显着的速度提升(见batching journals)。希望这有助于解决您的问题。