Skip to main content
Kofax

Slow import caused by misconfiguration to poll 1 MC with multiple CoreWorkers

3023459

Question / Problem: 

Messages seem to be stuck or need very long to import.
Although the message size is small, in the MC monitor is a "blue arrow" in the column "Transfer to KC" to see (inbound status/active) waiting that
it gets removed from the active queue and it gets a "green check" icon to indicate that the import was successful (inbound status/processed). 

Answer / Solution: 

Because there is often a misunderstanding, we need to clarify that 1 message connector can only be polled by 1 CoreWorker.
If more CoreWorker are polling from the same message connector, you would notice that the imported message seems to be stuck in the transfer to KC status (blue arrow). 
Checking the logs if this would be the cause is difficult because it’s not written. If there are only a few machines, you could check on each if some CoreWorkers have the same message connector URL or are pointing to the same MC configured. Another possibility which is more feasible for an environment with many CoreWorkers running and you cannot check them all manually, is the MC port test. Although the customer is saying they are sure that no other CoreWorker is polling the same MC, there could be leftovers from other VMs etc.
It’s recommended to do this test anyway.

By the default is the MC port set to 25086. You can check this in the “advanced” MC configuration:
clipboard_e4c3bed59bdcdfb8c993bf9a4554fe45b.png

And in the KTA import connection settings is the MC URL:
clipboard_eeb6bd7b0a877032a0f17795a533f208c.png

In my case are both installed on the same machine and I can open the MC Web Portal or rather MC Monitor with the following URL:
clipboard_e47e2040f3d4936cad2a1ea9169e14628.png

Because the default port is mostly used, other CoreWorker instances might have similar settings and could connect to the same MC + port as well.
To make it exclusively connectable for 1 instance, we change the MC port so that no other CoreWorker is able to access this MC.

Just change the MC port to e.g. 25089 in the MC config and in the MC URL like shown in the screenshots above.
Restart the MC and CoreWorker service and we can test if it’s helping. Don’t forget that the access to the MC Monitor site got changed as well.
You need to adapt the URL with the chosen port. Messages which are already in the “stuck” status needs to be resend or deleted if they aren’t needed anymore.
The new setting or rather config has no effect on already imported messages.

Be sure that no other application is using this port. E.g. 25087 and 25088 are already reserved for the Web-Service Input and 25099 for MC Cluster.
If you aren’t sure about the available free ports, just enter netstat -a in a command prompt and check if the wanted port is in used or not. 

Here is a walkthrough with the steps as screenshots changing the port to 25089: 
clipboard_e331a97f038f867ad49aa4b9be6bc24d5.png

clipboard_e89408e6d5fb3c43f186899bcd92f818d.png

clipboard_e962d6e31fb1bc8a480bf59f94bea9a8e.png

clipboard_eada9375d3e3e67bdf37f2fbe3379e400.png

clipboard_eb7392609c8d80ac3a594104c04f885f9.png

clipboard_e6cfdba767d6bc4fc0a414c0042afe80a.png

In newer KTA versions you might not need to restart the CoreWorker service after import setting/config changes, clicking OK is enough.
For older versions or if you aren't sure that the new settings are applied, restart the service: 
clipboard_e5b3f932729d9c65762af3b41c863fee9.png

After all changes, check if the MC Monitor is accessible with the new URL(+new port): 
clipboard_eab3377d1ab5bef5d5d0bc698fb637277.png

And check of course with new message imports if they are imported quickly as expected.

Applies to:  

Product Version
KTA 7.3+