Search results

  1. M

    Missing objects due to restarts of the SOSS engine

    We'll change the service so that it will just log the problem instead of restarting if/when the condition occurs. The next release will be out within the next two weeks.
  2. M

    Missing objects due to restarts of the SOSS engine

    Hi Nadav, This appears to be the same behavior that one of your associates (royial) reported last year: https://community.scaleoutsoftware.com/threads/usage-of-soss-with-nuget.811/ We're interested to know what happened after the original report from last year--did the restarts continue...
  3. M

    Strange slowness

    I see, thanks for clarifying. This is a case of the user's session growing larger and larger--this test case will get slower and slower with any out-of-process provider because of how ASP.NET groups a user's session items into one object. All the items in a user's session dictionary are...
  4. M

    Strange slowness

    I'm afraid don't fully grasp the scenario here--does the slow performance occur only during load tests, or is it when you're manually poking at the site with a web browser (or is the site under other load while you're manually browsing)? Overall memory usage shouldn't affect response times from...
  5. M

    Strange slowness

    Hi Rob, Which session provider are you using? The traditional one that ships with the main product installer, or one of the newer NuGet providers (sync/async)? Also, a few notes about this test (and session state in general): Session data isn't written back to the ScaleOut service after your...
  6. M

    threads blocking on read to scaleout server after moving to .NET 5

    That's a little surprising. Do you have a "hot object" that's accessed much more frequently than any other? (If so, whatever client cache partition it falls into will get hammered and eventually become a bottleneck... so scaling the number of client cache partitions may not help in that case.)...
  7. M

    threads blocking on read to scaleout server after moving to .NET 5

    Hi, thanks for the update. It would appear that the bottleneck moved out of the connection pool and up into the client cache. This might actually be good progress! Try increasing the number of client cache partitions to reduce the contention there. You can do that through the partitionCount...
  8. M

    threads blocking on read to scaleout server after moving to .NET 5

    No, it's the opposite: you want forceManagedLocking to be set to false to get the new, "optimized" locking behavior.
  9. M

    threads blocking on read to scaleout server after moving to .NET 5

    OK, I've posted Scaleout.Client version 4.2.10 on ScaleOut's development NuGet feed. You'll need to add http://nuget.scaleoutsoftware.com/nuget as a package source and then make sure this source is selected in the NuGet package manager. (See Microsoft’s Package Sources topic for details on...
  10. M

    threads blocking on read to scaleout server after moving to .NET 5

    I applied the locking change to our .NET Core build, but it did not improve performance in our tests--we saw that the performance on .NET Core 5/6 was already very good, even slightly better than the optimized .NET Framework behavior under the same load (500 threads vying for resources from a...
  11. M

    threads blocking on read to scaleout server after moving to .NET 5

    Yes, we'll move forward to get that optimization into .NET Core.
  12. M

    threads blocking on read to scaleout server after moving to .NET 5

    I don't think you'll see a difference in performance of the core library functionality if you upgrade to the latest. Most of the changes since 3.1.4 have involved adding support for advanced features in the service (GeoServer, PMI, etc.). There was one important fix in 4.2.7 involving client...
  13. M

    threads blocking on read to scaleout server after moving to .NET 5

    OK, so you're still running with a whole lot of threads. We can research to see if there's a similar optimization available for the .NET Core build. But, if possible, I would try moving to the async Cache methods and at least test to see if there's an improvement. I'm almost certain it'll help...
  14. M

    threads blocking on read to scaleout server after moving to .NET 5

    A few questions: How many threads do you see blocked on GatewayMultiplexer.GetGatewayFor()? Hundreds? What operating system are you running on? Is it possible for you to move to async calls and keep your app's thread count down? For background, I looked through old support cases and pieced...
  15. M

    NullReferenceException at Scaleout.Collections.RecentDictionary

    Hi Nadav, just a one-week check-in: have you had an opportunity to deploy 1.0.4 and determine whether it helped?
  16. M

    NullReferenceException at Scaleout.Collections.RecentDictionary

    Thank you. The line number appears related to the fix we made, so I think there's a very good chance it's resolved. I cannot say it's fixed with 100% certainty because we still aren't able to repro this particular exception--the error here is a result of corruption that occurred in the cache at...
  17. M

    NullReferenceException at Scaleout.Collections.RecentDictionary

    Hello again Nadav, We found and resolved an issue in the Scaleout.Collections NuGet package that may explain the exception that you reported. Please update your project to use version 1.0.4--we'll be interested to hear if this resolves the issue. Thanks!
  18. M

    NullReferenceException at Scaleout.Collections.RecentDictionary

    Hi Nadav, We've reviewed error you reported and haven't yet located the source of the problem. Please copy the Scaleout.Collections.pdb file from the attached zip to the web server(s) that are experiencing this issue--it should be copied to the same folder as the Scaleout.Collections.dll file...
  19. M

    NullReferenceException at Scaleout.Collections.RecentDictionary

    Hi Nadav, Thank you for reporting this and supplying the stack trace. We'll investigate and will let you know what we find.
  20. M

    Usage of SOSS with Nuget

    Update: We're changing the server to return an error to the client instead tripping a consistency check and restarting. The exception thrown back to the Cache caller will help track down which type is causing the problem.
Top