-
Title
A Shareplex process complains about "Internal error: 10403 - que_write() que_NOPRIV: User is wron -
Description
When you have multiple instances of Shareplex on a server, you may have problem starting one or more of these instances with the following type of messages showing up in event log:
02/04/04 21:47 Error: Error cleaning up previous shared memory segment 2278 [sp_cop(shs)/9709]
02/04/04 21:47 Error: Cannot delete because there are users attached [sp_cop(shs)/9709]
02/04/04 21:47 Error: Check if SharePlex processes are running and kill them if necessary [sp_cop(shs)/9709]
02/04/04 21:47 Error: cant setup shared memory statistics capability - exiting [sp_cop/9709]
02/04/04 21:48 Notice: Result 22 calling shmget to get shared memory segment (3001) [sp_cop(shs)/9747]
02/04/04 21:48 Notice: The size of segment (67108864) exceeds system limits or is greater than on existing shared memory segment key 0x44940800 [sp_cop(shs)/9747]
02/04/04 21:48 Error: Could not create shared memory [sp_cop(que)/9747]
02/04/04 21:48 Error: queue initialization failed - exiting [sp_cop/9747]
02/04/04 21:48 Error: Error cleaning up previous shared memory segment 2278 [qview(shs)/9757]
02/04/04 21:48 Error: Cannot delete because there are users attached [qview(shs)/9757]
02/04/04 21:48 Error: Check if SharePlex processes are running and kill them if necessary [qview(shs)/9757]
or
02/05/04 16:47 Internal error: 10403 - que_write() que_NOPRIV: User is wrong type [sp_ocap/11217]
02/05/04 16:47 Notice: dumping data to /<path>/opc-2 [sp_ocap/11217]
02/05/04 16:47 Process exited sp_ocap (for o.SID) [pid = 11217] - exit(1)
02/05/04 16:48 SharePlex was shutdown
02/05/04 16:48 Error: Error cleaning up previous shared memory segment 4278 [qview(shs)/11324]
02/05/04 16:48 Error: Cannot delete because there are users attached [qview(shs)/11324]
02/05/04 16:48 Error: Check if SharePlex processes are running and kill them if necessary [qview(shs)/11324] -
Resolution
The problem is typical on a system where there may be multiple Shareplex instances running whereby it may not be possible to ensure that each cop has its own unique shared memory and semaphore. This can be addressed by configuring the parameters SP_QUE_IPCKEY and SP_SHS_IPCKEY ( Deprecated parameters as of 7.0.x). When one runs multiple instances of Shareplex on the same server, these parameters may be helpful. Here is the description of the parameters:
SP_QUE_IPCKEY This parameter ( Deprecated parameter as of 7.0.x) creates a unique key for the SharePlex queues. This value must be different than the value set for the SP_SHS_IPCKEY parameter.
Default: D
Range of valid values: a character string
Takes effect: as soon as it is activated
SP_SHS_IPCKEY This parameter ( Deprecated parameter as of 7.0.x) creates a unique key for the statistics shared memory segment and semaphore. This value must be different than the value set for the SP_QUE_IPCKEY parameter.
.
Default: A
Range of valid values: a character string
Takes effect: as soon as it is activated
To implement it, one need to shutdown Shareplex on the machine, configure the parameter by adding it in paramdb or via sp_ctrl. For example if you have two instances of Shareplex running on port 2101 and 2102 respectively, you can configure the parameters as:
2101:
SP_QUE_IPCKEY "A" ### ( Deprecated parameter as of 7.0.x)
SP_SHS_IPCKEY "a" ### ( Deprecated parameter as of 7.0.x)
2102:
SP_QUE_IPCKEY "B" ### ( Deprecated parameter as of 7.0.x)
SP_SHS_IPCKEY "b" ### ( Deprecated parameter as of 7.0.x)
The choice of the key value on an instance is arbitrary and the only requirement is that is should be unique and not clash with the key value on another instance.