SOSS handle Pool

[keith.dorre]

Hello

We have been doing further investigations into our load problems, and after taking a deep dice into the situation we have the following issue where SOS is waiting within the client library

System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object)
Soss.Client.HandleUtil.HandlePool.InternalGetHandle(Soss.Client.HandleUtil.HandleWrapper*)
Soss.Client.DataAccessor.Delete(Soss.Client.DeleteOptions) ( also .Read, .Put, .Create )
Soss.Client.NamedCache.Remove(Soss.Client.CachedObjectId)
Soss.Client.NamedCache.Remove(System.String)

When this is happening, there are 20 threads that are performing network operations within the SOSS library (mostly Deletes, with some Reads and Puts):

ntdll!ZwWaitForSingleObject+0xa
mswsock!SockWaitForSingleObject+0x46
mswsock!_GSHandlerCheck_SEH+0x685a
ws2_32!recv+0x13c
soss_svccli!Sosslib_use_large_keys+0x3d23f
soss_svccli!Sosslib_use_large_keys+0x19b82
soss_svccli!Sosslib_use_large_keys+0x23e73
clr!DoNDirectCall__PatchGetThreadCall+0x7b
soss_svcdotnet!DomainNeutralILStubClass.IL_STUB_PInvoke(UInt32, SOSS_OBJKEY, Void*)+0x1938fd
soss_svcdotnet!Soss.Client.DataAccessor.Delete(Soss.Client.DeleteOptions)+0x4ad
soss_namedcache!Soss.Client.NamedCache.Remove(Soss.Client.CachedObjectId)+0x5c
soss_namedcache!Soss.Client.NamedCache.Remove(System.String)+0xa0

This lines up with the poolSize limit in this private SOSS library class:

Name: Soss.Client.HandleUtil.HandlePool
MethodTable: 000007ff02e6d430
EEClass: 000007ff02ea13c0
Size: 32(0x20) bytes
File: C:\Windows\Microsoft.Net\assembly\GAC_64\soss_svcdotnet\v4.0_5.0.0.0__a1ec0b86f746a476\soss_svcdotnet.dll
Fields:
MT Field Offset Type VT Attr Value Name
000007fef57ac7d8 4000256 10 System.Int32 1 instance 20 poolSize
000007fef57ac7d8 4000257 14 System.Int32 1 instance 20 inUseCount
000007fef57a6400 4000258 8 PTR 0 instance 00000000087f2480 pool
000007ff02e6d430 4000255 588 ...leUtil.HandlePool 0 shared static handlePoolInstance

Domain:Value 0000000002a9c7e0:NotInit 0000000002b4e1b0:00000001bf6f4ef8 <<

So the big question is, how do we avoid hitting this limit when we’re under load?

regards,
K

 

[admin]

Hi Keith,

The size of that pool of connection handles can be increased by setting the Soss.Client.DataAccessor.ConcurrentRequests property to a higher value. Note that this property must be set when your app first starts up and before any connections to the SOSS service are established, otherwise an InvalidOperationException will be thrown (your Application_Start event in global.asax is good place to set this value).

Also, the default value for that property was increased from 20 to 64 in version 5.0 (released in May, 2012)--you might consider upgrading to the most recent release if you'd like a bigger pool and would also like to get the latest improvements that have been made these past two years.