Warning about URS performing a lot of attach data actions

[pspenning]

Good Day Everyone,
We are seeing a lot of warnings in our logs about a lot of attach data actions taking place.  The actual error is:

Attention! interaction 020902464c2xxxxx is performing a lot of attach data actions

Would someone be able to please point me in the direction of some documentation explaining this message?  I know what it means, but I don't know the parameters by which it is triggered.  I would like to optimize our data attach process but am not exactly sure the best approach until I know the threshold I need to be under.

Thanks for any advice.
Perry

[cavagnaro]

No document, by logic you would follow that Interaction and which Apps are doing the attach data. Seems a bad design, probably a custom software or strategy

[pspenning]

Thanks for the info...
The error is coming from URS and I am certain that it's not a custom error message.  That being said, a thought just occurred to take a look at the standard alarm error code...  (I should have done this before posting)

I still don't have the answer as to what about the attached data triggers this but I will simply look for more efficient ways of attaching data and go from there...  Thanks for the help...

The error is 15-21006.
[b]Level[/b]
STANDARD

[b]Text[/b]
Attention! interaction [interaction ID] is performing a lot of %s actions

[b]Attributes[/b]
[interaction ID]
Connection identifier
%s
either "attach data" or "treatment"

[b]Description[/b]
While processing the interaction, URS detected a large number of actions.

[b]Action[/b]
Consider a redesign of the call flow. The current one results in a significant consumption of network resources and is not scalable.

[cavagnaro]

URS is not generating the error, it is warning you only.
Pick that connection ID and follow it over logs (TServer/URS) and find the application that is making it fail....as a CIV you should know that

[pspenning]

I am very clear as to the strategy that is causing this.  It's not really a mystery to me.
My original question is "What are the parameters by which this Standard notification is generated?"
What constitutes "A Lot Of Attach Data Actions"?
By knowing this, I will better know how to optimize the strategy.  Currently, the original design has a bunch of UData operations happening one after the other.  This was not my design.

Sadly, the original design makes no use of Transaction Lists either so we have over 100 strategies that will need to be touched.  Don't get me started on that one... 

I'm a smart CIV - I promise! 

[terry]

URS can not know for sure is designed solution good or bad.
This message is no more then warning (that solution might be wrong so you better to recheck it) and if you believe solution is good then just ignore it.

Scalability warning tracks numer of actions like attaching data or applying treatments,
was added as part of special SIP solution for extremely big environments and in for those environemtns "limits" are quite strict and flow can even be interrupted in some cases.

It works for normal cases (= by default) too though here it is nothing more then message in log, prineted by URS one time when number of attaching data requests for some call reaches 25. 
Just in case - bunch of Update actions packed into single updating request (with Multiattach objects or SetDellayedAttach function) is counted as 1.

[pspenning]

Thanks for the detailed information.  I could not locate the information that you have.  But it's much appreciated.
This helps me with my optimization.

Thanks,
Perry

[GMG]

Hello Perry,

Can you share the URS and Sip logs.

Did you find anything matching in SIP logs, in actual, URS can send the request to SIP, to attached the data, and actual attachment done by SIP/Tserver.

As of now, you have no harm with this warning message, as you have already seen in other responses . But I like to see the logs if possible.


GMG
CIV 8X

[Dionysis]

There is a hard limit, URS warns you about it, but T Server / SIP Server will actually stop accepting requests.  Check the trequest and udata limits in the T Server / SIP Server options and make sure they are high enough, Kazimir is a good way to count how many requests you've received.

I've had situations where the SIP Server has actually stopped accepting TLib Requests all together (which is just as catastrophic as you'd imagine ) with the default values for these options, so they should be tuned.