Error in Startup service execution during server restart

[prashanth23kota]

I am facing some issue in my current project(IS 8.2 version).If anyone gives input on the below issue would be very helpful .
I have created startup and shutdown services(which creates/Deletes the scheduler) in all the packages.When I run that service manually it will execute and create/delete the scheduler service but when I restart the server it does not create/delete any scheduler service.I am getting the below error .
“[ISS.0098.9013] Dispatcher is not initialized
Caused by: com.wm.app.b2b.server.ServiceException: [ISS.0098.9013] Dispatcher is not initialized
Caused by: com.wm.app.b2b.server.dispatcher.exceptions.CommException: [ISS.0098.9013] Dispatcher is not initialized “
“[ISS.0098.9013] Dispatcher is not initialized
Caused by: com.wm.app.b2b.server.ServiceException: [ISS.0098.9013] Dispatcher is not initialized
Caused by: com.wm.app.b2b.server.dispatcher.exceptions.CommException: [ISS.0098.9013] Dispatcher is not initialized “



Please let me know how this can be handled.Any fix required.If yes at what level and what is that fix.

[DCova]

I do not know the solution to your question, but I did find similar KB Articles for you that might help.

This is not a bug. As per design, the Dispatcher is initialized at very beginning of IS startup but it actually starts its activity of sending towards Broker and receiving events from Broker after all the packages are loaded.

Dispatcher needs the namespace to be loaded before starting the receiving and sending the events. In startup service, we can’t wait for the Dispatcher to start because for the Dispatcher to start the namespace should be loaded.

There is no easy fix for this issue unfortunately. Here is one workaround that has been used.
If you see the server�s logs at startup you will see an early entry that says
Dispatcher initialized

Then all the packages are loaded and startup services called. Then another entry in the logs says

Dispatcher started.

The dispatcher is actually ready to start publishing only after the second entry in the logs shows up i.e. after executing all the startup services. This is because the publish steps cannot happen unless all the documentTypes are loaded which means the server has to wait for all the packages to load and then start the Dispatcher.

In short, startup services cannot publish documents to the broker. Unfortunately, the server loads all the packages and run the startup services in a single thread. So if you put the publish call in a loop to wait till it succeeds, the Integration Server will hang at that service and never startup.

There is a workaround this problem. It is to have your service startup service invoke the publish step in a separate thread. The easiest way is to use Service.doThreadInvoke. Since the Service Threads are allocated once the server is completely up (meaning the Dispatcher is also up) the publish step will succeed in the other thread.

Also, you can decide to use a foolproof mechanism by creating a service that sleeps for a few seconds and publishes the document and put these steps in a RETRY loop. And then call this service from the startup service using Service.doThreadInvoke.

[prashanth23kota]

Thanks for your input .
Let me go through it .I will come if i face anymore issues on the same.

Thanks alot!

@dcova;87622

I do not know the solution to your question, but I did find similar KB Articles for you that might help.

This is not a bug. As per design, the Dispatcher is initialized at very beginning of IS startup but it actually starts its activity of sending towards Broker and receiving events from Broker after all the packages are loaded.

Dispatcher needs the namespace to be loaded before starting the receiving and sending the events. In startup service, we can’t wait for the Dispatcher to start because for the Dispatcher to start the namespace should be loaded.

There is no easy fix for this issue unfortunately. Here is one workaround that has been used.
If you see the server’s logs at startup you will see an early entry that says
Dispatcher initialized

Then all the packages are loaded and startup services called. Then another entry in the logs says

Dispatcher started.

The dispatcher is actually ready to start publishing only after the second entry in the logs shows up i.e. after executing all the startup services. This is because the publish steps cannot happen unless all the documentTypes are loaded which means the server has to wait for all the packages to load and then start the Dispatcher.

In short, startup services cannot publish documents to the broker. Unfortunately, the server loads all the packages and run the startup services in a single thread. So if you put the publish call in a loop to wait till it succeeds, the Integration Server will hang at that service and never startup.

There is a workaround this problem. It is to have your service startup service invoke the publish step in a separate thread. The easiest way is to use Service.doThreadInvoke. Since the Service Threads are allocated once the server is completely up (meaning the Dispatcher is also up) the publish step will succeed in the other thread.

Also, you can decide to use a foolproof mechanism by creating a service that sleeps for a few seconds and publishes the document and put these steps in a RETRY loop. And then call this service from the startup service using Service.doThreadInvoke.

[Rajendar_Annachedu]

Hello,
I’m facing same issue now.Did you find any resolution for this?

[Mahesh_K_Sreenivas]

What is your webMethdos version?

Did you restart your server in order for the dispatcher to load and start automatically?

Did you make sure the broker settings are correct on IS admin under Messaging?

Did you check your dispatch.cnf file in your integration server config directory. See if it matches with your broker settings. If its not you can back up the file, get the IS down and delete it from the config folder and restart the server.

Happy New Year 2015

[Holger_von_Thomsen]

Can you share more details about your requirement please?

If possible some screenshsots would be fine.

Normally it is not neccessary to create/delete the schedulers upon starting/stopping the IS.
Once created they are persisted by the IS.

Regards,
Holger

[lance_k]

I too want to know the requirement here. why you are creating a scheduler and deleting the same when IS restart?

[rmg]

All the scheduler info is stored in the backend table and you can check the status column in it and may be some DB locks are some thing holding the jobs…please check it and do not hesist to take DBA help.

Let us know what you find it from the logs after restart and also clear any corrupted files from the store.

HTH,
RMG