Splunk Dev

Why is my external results provider written in JAVA is slow to start up?

dharte
New Member

I have an external results provider (ERP) written in Java. When I execute a search the ERP is fired and results returned to Splunk. All of that works fine except there is a speed issue with the ERP. If I do a simple search there is always an overhead to that search. If I view the results of the search via the Job Inspector I see my dispatch.fetch always represents a significant portion (over 90%) of the search time. If I refer to my search log I can identify one line that is taking four seconds to execute, refer below. Note, it doesn't matter how complex or simple the search is, the overhead at the SearchOperator:stdin line below remains around the same time.

02-12-2018 16:34:14.088 INFO UserManager - Unwound user context: admin -> NULL
02-12-2018 16:34:14.088 INFO UserManager - Setting user context: admin
02-12-2018 16:34:14.088 INFO UserManager - Done setting user context: NULL -> admin
02-12-2018 16:34:14.088 INFO UserManager - Unwound user context: admin -> NULL
02-12-2018 16:34:18.168 INFO SearchOperator:stdin - Initializing from configuration

02-12-2018 16:34:18.171 INFO LineBreakingProcessor - Initializing
02-12-2018 16:34:18.179 INFO regexExtractionProcessor - Initializing
02-12-2018 16:34:18.180 INFO PipelineComponent - Launching the pipelines for set 0.

Can you help me that why is this happening or is there a diagnostic I can run to hunt this issue down?

Tags (3)
0 Karma
Get Updates on the Splunk Community!

What the End of Support for Splunk Add-on Builder Means for You

Hello Splunk Community! We want to share an important update regarding the future of the Splunk Add-on Builder ...

Solve, Learn, Repeat: New Puzzle Channel Now Live

Welcome to the Splunk Puzzle PlaygroundIf you are anything like me, you love to solve problems, and what ...

Building Reliable Asset and Identity Frameworks in Splunk ES

 Accurate asset and identity resolution is the backbone of security operations. Without it, alerts are ...