title: Is it possible for a .NET Dictionary object to overflow?
body: <p>I now have an event processor class which has a Dictionary to store all the subscriptions. In fact it is a Dictionary of Dictionary. And this process class is communicating with a third-party remote server to make the request for target data. I am asking this question because now we are experiencing some occasionally subscription lost problem. Since for some reason it is hard to verify whether this lost happens in the connection to the remote server, I now have to firstly check whether there is anything wrong with my event processor class. And my first suspect would be if the subscription information is lost due to overflow of this Dictionary object. Does anyone have any idea? Thanks!</p>
  
  <p>UPDATE</p>
  
  <p>perhaps I should tell a little bit more about the scenario, since the code is not really easy to show. We used to have our legacy SW, let's call it A, to communicate with the remote data service, called B, using the API provided by B's vendor. However, since we are changing A to 64 bits SW, but the library provided for B is still 32 bits, our new 64 bits A can't use this library any more. So I am designing a 32 bits SW called C, to use the library to connect to B, while keeping communication with 64 bits A using WCF. Since C is mainly a pub/sub structure, as I mentioned before, I am using a Dictionary of Dictionary to maintain the requests and subscriptions in C. And here comes our problem: we are experiencing some subscription lost (no publication for long time, but after re-initializing subscription we can get the publications) at A. It is not easy for us to check B's feedback to see whether there is any mis-configuration. And my WCF service log doesn't show any error there either. I have to suspect the problem happens at C solely. I am aware of multi-threading issue so I have made a lock to every operation of the Dictionary. But I just can't think of what could be wrong. BTW it is not like C the memory is used up and C got crashed.</p>