How can I stop my service from being split into Web request, RMI, and Background types?

[james_leatherma]

We have over 250 JVMs that are pretty monolithic. Right now, every single JVM is being split into three service types, but that is not helpful nor accurate for our architecture. How can we prevent this?

[Jordan_Cogan]

Hi James,

Do you have any details on why this isn't accurate for your architecture? One option available to you would be to define your own custom services. This allows you to define any method, class, or interface as the entry point to a service.

[james_leatherma]

The entry point is not an issue. The issue is that we don't derive any value of Dynatrace arbitrarily demarcating parts of our app based on request type. This is all handled internally with highly controlled thread pools.

[Julius_Loman]

AFAIK you don't have any control over this. It's just grouping of services based on the request type. If services are not correctly detected, you can merge services or create new custom ones as @Jordan C. suggests. Does this grouping into categories cause any issues for you?

[james_leatherma]

I'm learning to work around it. But for us folks still supporting legacy systems, it would be nice to have this as a configurable option. Or at least have the Service type listed by the individual services in the Process group view - that would prevent me from opening the wrong service each time I try one of the three.

[hayden_miedema · Accepted solution]

Hi James,

Based on your last comment, something that may help would be setting up custom service naming rules to help you better identify these services from the process group view. This can be done by going to Settings --> Server side service monitoring --> Service naming rules. You could set one up for each service type you're seeing (RMI, web request, background, etc.) and add something to help you better identify which is which in quick manner.

HTH,
Hayden

[michael_kopp]

May I ask, you said you have these 3 services for each JVM. Should those 250 JVMs all be standalone. Or is it that multiple of these JVMs do the same thing and should form a process group? the reason I ask is that process groups split services. a process group is thought to contain many instances (processes/JVMs) of the same deployment. Thus maybe in your case we first need to start adjusting process grouping, the services would then automatically fold as a consequence.

A single service would then have many instances (aka JVMs). It would be treated as such.

Does this make sense?

[gilgi]

@Michael K. I think the most "bothering" issue we see on customer sites is the creation of the background activity service, which, in async environments create a difficulty to isolate flows. It would be great if at least this could be controlled.