Search results

Hi, I've tested successfully with a one-line script that looks like this: # auth.ps1 Write-Output "permissions 3 timeout minutes 60" Use the soss.exe command to register this custom auth provider for a namespace: soss.exe set_ns_auth name="My cache name" method=custom path="powershell -F...

There aren't any known issues with auth in 5.12.3.378. There are a few things you'll need to check: 1. From an administrative command prompt, please run: soss.exe show_ns_auth In the output, make sure that the cache(s) that you're using are listed, and verify that the path to your powershell...

Hi, Is this exception coming out of a call to LoginManager.getInstance().Login(...)? If so, the most likely cause is that the back-end auth provider (a custom executable that you've deployed to your ScaleOut server machines) is returning an error when invoked by the ScaleOut service. If this...

The ScaleOut service uses the OpenSSL library for TLS (not Windows schannel), so those registry keys won't have an effect. Version 5.14.1.380 of the ScaleOut service (released 7-Jul-2023) sets the minimum protocol version to TLS 1.2, so it appears that you're running an older version of the...

Hi Caleb, Great question. In the NamedCache library, locks are held on a per-thread basis. (Behind the scenes, the API holds on to a lock ticket for you in thread-local storage.) The idea is that locks can provide consistency across any number of clients, processes, and threads. FYI, the newer...

Yes, that's all that you need to do.

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.

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...

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...

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...

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...

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.)...

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...

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

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...

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...

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

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...

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...

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...