sql server notification services: I am trying to make the generator run matching rules in parallel by
trying different values for ThreadPoolSize, and restarting the
instance. It seems to have no effect: the rows on NSRuleFirings1
continue to strictly have start times after the previous row end time.
Am I missing something?

Rules can only be run concurrently in NS if they are considered
"compatible". Consider an event rule and a scheduled rule on one
subscription: these two rules are considered incompatible because the
subscriptions view is scoped differently for each of the rules.

Let me know if it is unclear why your rules are being grouped as they are.

- Colin Meek [MSFT]

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm.

[quoted text, click to view]

Thanks Colin. All our matching rules are event rules, running against
separate event tables, writing to separate notification tables (though
some do share a common subscription table). How can I tell what is
'grouped' with what? What are the rules for grouping?

Scheduled and event-driven rules are incompatible. If sub-quantum ordering
is enabled in your application, then NS also groups by event batch.

- Colin Meek [MSFT]

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm.

[quoted text, click to view]

Thanks again Colin. All our rules are event driven, so the scheduled
rule incompatibily should be irrelevant. Is there any other possible
rule incompatibility?

We do have sub-quantum ordering enabled, so I understand that we get
one rule firing per event batch. However, I would have expected some of
these rule firings to overlap when successive batches are associated
with different ruleid's. We did try disabling this, and it didn't
appear to make a difference.

Three of our rules are defined within the same subscription class:
would that stop them being fired in parallel? I tried moving one to a
different class, and it made no difference,
e.g:

<SubscriptionClass>
......
<EventRules>
<EventRule> <RuleName>CrnOtherEventRule</RuleName>
<Action> EXEC
[CJSESubscriptionInstanceCJSESubscription].[dbo].[sp_CrnOtherEventRule]

</Action>
<EventClassName>CrnOtherEvent</EventClassName>
</EventRule>
<EventRule> <RuleName>CaseFileOtherEventRule</RuleName>
<Action> EXEC
[CJSESubscriptionInstanceCJSESubscription].[dbo].[sp_CaseFileOtherEventRule]

</Action>
<EventClassName>CaseFileOtherEvent</EventClassName>
</EventRule>
<EventRule>
<RuleName>DefendantOtherEventRule</RuleName>
<Action>
EXEC
[CJSESubscriptionInstanceCJSESubscription].[dbo].sp_DefendantOtherEventRule]

</Action>
<EventClassName>DefendantOtherEvent</EventClassName>
</EventRule>
</EventRules>
</SubscriptionClass>


Also, is it ok to alter the ThreadPoolSize directly on the database
rather than doing an NSControl update each time I change it? We did
some database differences before and after nscontrol update, and
couldn't see any other differences.


Thanks for your patience,
Ian.

Thanks again Colin. All our rules are event driven, so the scheduled
rule incompatibily should be irrelevant. Is there any other possible
rule incompatibility?

We do have sub-quantum ordering enabled, so I understand that we get
one rule firing per event batch. However, I would have expected some of
these rule firings to overlap when successive batches are associated
with different ruleid's. We did try disabling this, and it didn't
appear to make a difference.

Three of our rules are defined within the same subscription class:
would that stop them being fired in parallel? I tried moving one to a
different class, and it made no difference,
e.g:

<SubscriptionClass>
......
<EventRules>
<EventRule> <RuleName>CrnOtherEventRule</RuleName>
<Action> EXEC
[CJSESubscriptionInstanceCJSESubscription].[dbo].[sp_CrnOtherEventRule]

</Action>
<EventClassName>CrnOtherEvent</EventClassName>
</EventRule>
<EventRule> <RuleName>CaseFileOtherEventRule</RuleName>
<Action> EXEC
[CJSESubscriptionInstanceCJSESubscription].[dbo].[sp_CaseFileOtherEventRule]

</Action>
<EventClassName>CaseFileOtherEvent</EventClassName>
</EventRule>
<EventRule>
<RuleName>DefendantOtherEventRule</RuleName>
<Action>
EXEC
[CJSESubscriptionInstanceCJSESubscription].[dbo].sp_DefendantOtherEventRule]

</Action>
<EventClassName>DefendantOtherEvent</EventClassName>
</EventRule>
</EventRules>
</SubscriptionClass>


Also, is it ok to alter the ThreadPoolSize directly on the database
rather than doing an NSControl update each time I change it? We did
some database differences before and after nscontrol update, and
couldn't see any other differences.


Thanks for your patience,
Ian.

Thanks Colin,

All our rules are event rules, so the scheduled incompatibility should
be irrelevant.

We do have sub-quantum ordering enabled. I understand this will mean
each event batch will have its own row on the NSRuleFirings1 table, but
would have hoped to see some overlap of the times on these when
successive rows are for different rule ids within the same quantum. We
also tried disabling sub-quantum processing, and this didn't seem to
help.

Three of our rules are defined as part of the same subscription class.
Would that affect parallel processing? Tried moving one to a
difference class, and it didn't seem to make any difference.

Can we change the ThreadPoolSize value directly on the database, rather
than having to nscontrol update changes to it? We did a
before-and-after database comparison, and couldn't see any differences
other than this.

Thanks for your patience,

Ian.

[quoted text, click to view]

The only supported way to change a configuration is by changing the
ICF and/or ADF and running NSControl update.

HTH...

--
Joe Webb
SQL Server MVP


~~~
Get up to speed quickly with SQLNS
http://www.amazon.com/exec/obidos/tg/detail/-/0972688811

I support PASS, the Professional Association for SQL Server.
(www.sqlpass.org)


On 3 Jun 2005 01:27:08 -0700, "ian" <ian.rowe.lfh@atosorigin.com>
[quoted text, click to view]