Service mapping: Timeout issue

[Raj Mathan]

Hi everyone,

I am facing a peculiar issue with Servicemapping. When I provide Service mapping with the entry point and hostname, it starts discovering and the discovery runs indefinitely.

after an hour or so, it returns a time out ' Task timout expired' , and when I look for discovery logs, there is no data

I checked and found the below in the MID server logs:

But couldn't figure out anything,

MID server Log:

03/07/17 16:18:43 (325) LogStatusMonitor.60 stats threads: 34, memory max: 910.0mb, allocated: 210.0mb, used: 50.0mb, standard.queued: 0 probes, standard.processing: 0 probes expedited.queued: 0 probes, expedited.processing: 0 probes interactive.queued: 0 probes, interactive.processing: 0 probes

03/07/17 16:19:04 (837) Worker-Interactive:HeartbeatProbe Worker starting: HeartbeatProbe

03/07/17 16:19:04 (837) Worker-Interactive:HeartbeatProbe Probing heartbeatprobe

03/07/17 16:19:04 (837) Worker-Interactive:HeartbeatProbe Finished firing the heartbeatprobe

03/07/17 16:19:04 (853) Worker-Interactive:HeartbeatProbe Enqueuing: C:\SM Midserver\agent\work\monitors\ECCSender\output_0\ecc_queue.6d017b6edb1db200ba79712dbf9619a2.xml

03/07/17 16:19:04 (853) Worker-Interactive:HeartbeatProbe Worker completed: HeartbeatProbe time: 0:00:00.000

03/07/17 16:19:04 (931) ECCSender.1 Sending ecc_queue.6d017b6edb1db200ba79712dbf9619a2.xml

03/07/17 16:19:43 (307) LogStatusMonitor.60 stats threads: 34, memory max: 910.0mb, allocated: 210.0mb, used: 50.0mb, standard.queued: 0 probes, standard.processing: 0 probes expedited.queued: 0 probes, expedited.processing: 0 probes interactive.queued: 0 probes, interactive.processing: 0 probes

03/07/17 16:20:43 (320) LogStatusMonitor.60 stats threads: 34, memory max: 910.0mb, allocated: 209.0mb, used: 50.0mb, standard.queued: 0 probes, standard.processing: 0 probes expedited.queued: 0 probes, expedited.processing: 0 probes interactive.queued: 0 probes, interactive.processing: 0 probes

03/07/17 16:21:43 (318) LogStatusMonitor.60 stats threads: 34, memory max: 910.0mb, allocated: 210.0mb, used: 50.0mb, standard.queued: 0 probes, standard.processing: 0 probes expedited.queued: 0 probes, expedited.processing: 0 probes interactive.queued: 0 probes, interactive.processing: 0 probes

But, when I try running discovery module separately ( tried discovering the host server), it is working fine. ( atleast got authentication errors other that timeouts).

Has someone faced a similar issue. Can you help me out how this could be resolved.

[Marlos]

Hi Raj, one simple question: is horizontal discovery working for the host specified in the entry point?

[sarahbr]

Not only horizontal discovery, but what is the status of the host for horizontal discovery?   I had a case where the host was marked retired, horizontal discovery worked fine... then I discovered that service mapping expects an operational status for the host.  

[tednorlander]

Hi,

we had similar issues that Service Mapping Discovery didn't work even though Discovery on its own worked fine.

After reading some docs I found that Service Mapping is choosing MID-server based on IP-ranges assigned to the MID-servers.

If you don't have any valid IP-ranges assigned for the CI's you're trying to Discover the SM Discovery will try to use the default MID-server.

Here's the next caveat, if you haven't set any default MID-server on your instance the discovery (through service mapping) will pick a random MID-server from the list of available MID-servers. We got a hint from the messages in the 'Discovery messages' in Service Mapping where I found that the Discovery was trying to use credentials that was connected to a MID-server used for a totally different IP subnet then the one I tried to discover.

Our solution was to assign the IP-ranges in the current Service Mapping task to the correct MID-server.

Then everything 'magically' started to work as expected.

Another issue worth mentioning is that we had problems with our MID-servers giving time-out and authentication errors even though we knew it was correct.

After some trial-and-error we found that increasing number of threads on the MID-server triggered these problems (even though we increased the memory available for JVM).

Once we went back to default setting of 25 threads everything worked fine without any strange errors and the performance is actually really nice.

I've seen another topic discussing performance and threads where another customer ended up using 40 threads for their MID-server as the optimum setting.