Search results

Yes, SQL Server will work fine: data access to SQL Server is handled entirely in the Write-Behind event callback that is defined in your code, so the ScaleOut service is not directly involved in database communication--it's handled entirely by your application, allowing you to use whatever...

Yes, Write-Behind/Erase-Behind is currently supported on AWS--the core of this functionality does not depend on a specific on-prem/cloud environment. If you share what kind of backing store you intend to write to (and which ScaleOut client library you intend to use) then we may be able to offer...

Hi Robin, It appears that the Object Browser can connect to the services' management port (720)--which is why the Management Console is working--but the exceptions indicate that the server port (721) is blocked on one or both of those two hosts. For starters, I'd suggest using PowerShell's...

Yes, the soss_client_params.txt file contains all the connection information used by remote clients to connect. We recommend deploying ScaleOut remote client components via the MSI package whenever possible--there are native dependencies and registry entries that make manual installation an...

Opening up the ScaleOut Management Console was a good first check--it verified that your remote client machines can reach the ScaleOut service over the network. However, the Management Console only connects to the ScaleOut service's management port. Client applications connect to the service's...

Microsoft's session provider model doesn't make it very easy to get at sessions from external systems. ScaleOut's .NET Core APIs aren't really designed to get at old .NET Framework session data. Option 1 This could be accomplished under the traditional .NET Framework runtime. You'd need to use...

You'll need to use the Scaleout.Client NuGet package--it's our latest client library (a .NET Standard library that can run under .NET Core). The original Soss.Client.NamedCache library that ships with the product will only run under the traditional .NET 4.x Framework. If you're going to use...

Hi Adam, Yes, you've got it exactly right--multicast is only used during discovery, and manually creating a group of candidate IPs is an alternative way to let the hosts find each other when they first start up. After that, everything will work the same.

So, just to verify, I assume the two new VM systems are able to discover each other, correct? If not, I'd recommend getting those two talking first (it's usually a Windows firewall issue in the guest causing problems there). In any case, we don't have specific expertise in Cisco hardware, so we...

The issue is resolved--it was caused by an extra soss_client_params.txt file on the filesystem--it was getting picked up by client libraries during initialization and must have contained some old or invalid parameters (typically there should only be one copy of this file living in the product's...

Hi Tyler, This is an unusual exception--it indicates that you're able to connect to the ScaleOut service but there's something wrong with the "application name" that's being sent to to the session provider. For session state, the application name is the path to your app in the IIS metabase--it...

Hi Satish, You can use an instance of a NamedCache object in a Powershell script--call the Remove(key) method to delete a specific object. For example: # Sample script: Remove-Scaleout-Object.ps1 Param ( [parameter(Mandatory=$true)] [String] $Namespace...

I apologize for the slow reply (we just migrated to a new forum platform and our notifications appear to be misconfigured). 3 reads/second tells us that you're probably facing a connectivity problem between your app and the ScaleOut caching tier--you may be hitting the 250 millisecond timeout...

Summary Recent updates to the .NET Framework (starting with .NET 4.7.1) are incompatible with older versions of ScaleOut's .NET client libraries (versions prior to 5.5, released 2016-Dec-29). This incompatibility stems from recent changes made to .NET's JIT compilation engine. Customer Impact...

This information was recently added to object metadata in version 5.7.0.324. It can be accessed via a call to NamedCache.GetMetadata. Two new properties are available: NamedCacheObjectMetadata.CreateTime: Gets the object creation time (UTC). NamedCacheObjectMetadata.UpdateTime: Get the time of...