Windows Server AppFabric打开许多端口并停止工作 [英] Windows Server AppFabric opens many ports and stops working

查看:83
本文介绍了Windows Server AppFabric打开许多端口并停止工作的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用AppFabric Cache帮助解决单点登录解决方案,我希望将来扩展其用途。


但是目前我还是遇到AppFabric Cache不再缓存项目的问题。这个问题每天都会发生,我们甚至还没有进入测试阶段。每当出现这个问题时,我们也确定有很多(200+)个
端口打开/来自:22233。


缓存的项目存储在命名区域中,对新项目使用.Add(),对现有项目使用.Put()。


要使缓存的项目(登录用户)过期,请按.Get()和。更新这些项目。无论什么时候需要Put()。我想在这里使用.ResetObjectTimeout(),但我无法确定AppFabric缓存已经配置的默认超时
to。


我使用乐观的并发模型,因此没有发生锁定。


我没有使用本地缓存(还)。


当问题发生时,我发现了。 Add()成功,但使用powershell我在缓存中找不到任何项目。因此,需要登录用户的下一个调用失败,因为它无法在缓存中找到所需的对象。


在达到这种情况后,使用netstat我发现有大量的连接是打开到端口:22233。


最后:5个已部署的WCF服务正在使用此缓存解决方案,使用相同的代码来解析当前用户的缓存。


我没有找到任何人描述这种特殊的'行为',所以我希望有人可以帮助我。

解决方案

好的,我想我已经解决了这个问题。



使用netstat也显示进程Id,我确定单个客户端应用程序出错了。还没有看过内部,但可能有很多线程都保留了自己的缓存实例。




幸运的是AppFabric Cache异常消息非常有助于确定问题的根源:(。


尝试在独立应用程序中复制问题但我确定:


当从不同的线程/进程访问相同的缓存对象时(如安全对象的情况),使用.Put()会比使用.ResetObjectTimeout()创建更多的并发问题。


因此,每当我只需要延长缓存安全对象的生命周期时,我就会使用.ResetObjectTimeout()。


 


 


I am using AppFabric Cache to help out with a Single Sign On solution, and I would like to expand its usage in the future.

However at the moment I am experiencing a problem where the AppFabric Cache will no longer cache items. This problem occurs daily, and we are not even in testing phase yet. Whenever this problem occurs we have also detemined that there are a lot (200+) of ports open to/from :22233.

Cached items are stored in a named region, using .Add() for new items and .Put() for existing items.

To keep cached items (Logged in users) from expiring, refresh these items by .Get() and .Put() whenever they are needed. I would like to use .ResetObjectTimeout() here, but I am unable to determine the default timeout that AppFabric cache has been configured to.

I use an optimistic Concurrency model, therefore no locking occurs.

I do not make use of local cache (yet).

When the the problem occurs, I find that the .Add() succeeds, but using the powershell I find no items in the cache. The next call needing the logged in user therefore fails, as it cannot find the required object in cache.

After this situation has been reached, using netstat I find that a large number of connections are open to port :22233.

Lastly: This caching solution is being used by 5 deployed WCF services using the same piece of code to resolve the current user from cache.

I haven't found anybody describing this particular 'behavior', so I hope somebody can help me out here.

解决方案

Okay, I think I've solved this already.

Using netstat to also display the process Id's, I've determined that a single client application was at fault. Haven't looked at the internals yet, but probably there are a lot of threads each keeping hold of their own cache instance.


Luckily the AppFabric Cache exception messages were very helpfull in identifying the source of the problem :(.

Trying to replicate the problem in a standalone application I did determine however:

When accessing the same cached object from different threads/processes (as is the case with security objects), using .Put() creates a lot more concurrency problems than using .ResetObjectTimeout().

I therefore now use .ResetObjectTimeout() whenever I only need to prolong the lifetime of the cached security objects.

 

 


这篇关于Windows Server AppFabric打开许多端口并停止工作的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆