我们在应用程序中使用 Pivotal GemFire 进行春季会话管理。
在生产中，当负载增加时，应用程序没有响应(完全挂起)。我们收到一个错误，例如客户端被列入黑名单。我们检查了请求计数，它就像 15k。
应用程序部署在容器中。 使用的协议Http11AprProtocol，最大线程数设置为200。我们检查了线程转储。错误如下。
我们不确定集装箱或 GemFire 无法处理负载量。在 GemFire 中，是否有任何特定参数来确定它可以处理的线程数。任何帮助，不胜感激。
Cache Client Updater Thread on server Id=14397 in RUNNABLE (running in native)
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
- locked java.lang.Object@2f2e340
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:940)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)
- locked sun.security.ssl.AppInputStream@1ce48525
at org.apache.geode.internal.cache.tier.sockets.Message.fetchHeader(Message.java:809)
]
GemFire 每秒处理 15K 个请求应该没有问题(？？)。 不确定您的测量值是什么，但秒/分钟真的无关紧要。 它可能需要一些调整，但 GemFire 应该能够处理它，无论是几分钟还是几秒钟。
需要考虑的几件事：
1)首先，看看这里。
2) 当然，您可以调整客户端/服务器拓扑的两端。
在客户端上，您可以使用PoolFactory来配置设置，例如最小/最大连接数，prSingleHopEnable，socketBufferSize，threadLocalConnections等。
将春季会话用于 Pivotal GemFire，客户端上使用的Pool(Web 应用程序，GemFireClientCache)可以使用 SDGClientCacheFactoryBean类进行配置，如果使用"默认"GemFirePool，您经常声明自己，就像这样，或者如果您使用特定的"命名"Pool与 Pivotal GemFire 的春季会话，则可以使用PoolFactoryBean类， 在这种情况下，它看起来像这样...
@SpringBootApplication
@EnableGemFireHttpSession(poolName = "SessionPool", ...)
class MySpringSessionGemFireClientApplication {
@Bean("SessionPool")
PoolFactoryBean sessionPool() {
PoolFactoryBean sessionPool = new PoolFactoryBean();
sessionPool.setMaxConnections(..);
sessionPool.set...
return sessionPool;
}
}
在服务器上，这实际上取决于你如何启动节点(例如Gfsh，使用Spring等)。 但从本质上讲，它归结为CacheServer上的设置 . 例如：loadPoolInterval、maxConnections、socketBufferSize、maxThreads 等。
3)我还要说，您需要首先收集信息以确定问题可能在哪里，查看服务器日志，统计信息等。 该信息应在上面的#1中推荐。
4)还有其他因素需要考虑，例如数据的大小。
5)从网络的角度来看，你必须考虑一些事情，添加"容器"会增加另一层复杂性，因此它将依赖于UC，架构，基础设施。
无论如何，所有这些都是说，考虑到所有因素(例如拓扑、架构、数据大小、配置、应用程序设计等)，很难确定问题出在哪里。 提供日志、统计数据等可能会有所启发。
不知道为什么你认为上面的线程转储是一个"错误"。 是的，">缓存客户端更新程序线程"持有对象锁，但是，线程也保持可运行(服务中)。 只有当另一个线程(1 个或更多)正在等待或阻塞，等待该锁，并且它开始消耗资源或阻止/降级某些应用程序工作流时，该线程持有锁的事实才是一个问题。
我怀疑您在 GemFire 和容器之间有一些问题，但我不能肯定地说。