I've got a situation here:
I have many frontend services (A-B-C) making call to another Service on the backend.
Now the backend service is an RMI requests on Jboss and it become the logical service container of all request made by service A, B and C.
I would like to split the RMI service this way:
Request of Service-A
Request of Service-B
Request of Service-C
and the criteria would be to split it by RMI classes since they all start like this:
it.service.A.facade (For Service-A)
I tried, with no success, with Custom service detection but it get pretty cumbersome.
Do you have any suggestion or tip?
Solved! Go to Solution.
I don't think you have any other options at the moment. Service detection rules are not (yet) applicable for RMI services. You can try to define custom services based on the classes, but I believe you will achieve just another service behind your RMI service in the service flow and I don't think this is something you want.
Did you consider marking the appropriate RMI classes as key requests for the RMI service?
I know that I can do It [Key request] but I will not achieve my overall goal [to have, instead of an aggregated service, a true splitted service in order to have precise problem opened on it and propagate this problem on precise model of the service - outside of Dynatrace]
Also making Key Request (as a methodical way to work this out) will bring me other concern that I'm unable to evaluate to this day; first of it: how much will It cost me in terms of storage.
Thank you for the answear
I understand what you want to achieve, but I don't think this is possible at the moment. Probably a good RFE if you have a valid use case for that.
In terms of storage for key requests, I think this is pretty close to zero, as it applies only for metrics. Unless you have thousands of key requests, you won't even notice the storage. Marking a request as key does not have any effect on service request data retention (PurePaths).