We are seeing this error massage continuously written on webMethods(9.8) IS server. Not sure about the error. Any help on this will be appreciated
Hi Raghavendra,
can you please provide the complete Error message as well as the Fix level you have applied to IS 9.8?
Did you try to search the community forums for this error message?
Hopefully, you will find some older posts here which are referring to this issue as well.
Regards,
Holger
Hi Holger,
we are on fix 22
IS_9.8_Core_Fix22
Yes i did search community forms related to this error but didnt find anything similar
and about the error message this is what we are seeing in logs piling up
[1114]2020-11-13 08:42:24 GMT [ISC.0072.0023E] Failed to initialize the bundle for encoder “esapi”
Hi Raghavendra,
the latest Fix for 9.8 I am aware of is IS_9.8_Core_Fix30.
In the readme I could find the following entry:
PIE-40027 (IS_9.8_Core_Fix7)
Integration Server logs the wrong message when it cannot find
the encoder "esapi".
When Integration Server cannot find the encoder "esapi", it logs
the following wrong error message:
[ISC.0072.0023E] Couldnt initialize encoder "{0}".
Whereas, Integration Server should log the following message:
ISC.0072.0023E] Failed to initialize the bundle for encoder
'esapi'.
This issue is resolved now.
As you are above of Fix7 by using Fix22 (as indicated by the error message), you should check why the IS is not able to find the encoder.
Might be a Class-Loading issue.
Is there any thing related to this in the wrapper.log of this instance?
Was this working once in the past?
If yes, were there any changes to this installation lately?
Regards,
Holger
Does this problem occur on newly created IS instance or an existing one? Can you please make sure that you have installed latest OSGi platform fixes in your env?
Thanks,
-Kalpesh.
Yes correct occurs on new created IS instance
Regards,
Raghavendra
Yes correct occurs on newly created IS instance
Regards,
Raghavendra
to add more this new instance has been installed on same server where already has an existing IS Instance is working fine
Hi Raghavendra,
is this a complete new installation in a different wM Root directory or just a second instance to the existing installation?
The first one (as long as you keep the instance name as “default”) should work while applying Fixes.
The second one might have issues when the instance name is differing.
See the Readmes for further informations on this.
Regards,
Holger
1 Like
I found this issue in our archives for wM IS 9.8. It was reported April 2017.
Here’s a summary explanation of the problem and solution:
“If a new IS instance was created after fix installation, the OSGI patches from fixes are not copied. Therefore, the OSGI patches need to be re-installed in new instances. Please use Update Manager to over install the IS core fixes again, and OSGI patches will be updated in the new instance”
Note: the file containing the bundle info for an instance is stored under:
\profiles\IS_\configuration\org.eclipse.equinox.simpleconfigurator\ bundles.info
This is for your information. This file will be updated with the proper files after running SUM.
Wayne
Software AG wM Principal Instructor
2 Likes
Sorry, the path to bundles.info should be:
\profiles\<IS_instance>\configuration\org.eclipse.equinox.simpleconfigurator\ bundles.info
2 Likes
Hi Holger,
yes its just a second instance added to the existing installation, As explained by you and Wayne below i will try to reinstall the corefix and let know the results
really appreciate for your suggestions
Thanks,
Raghavendra
Hi Wayne,
Yes i think this is something we didnt do after creating a new instance, as suggested will try to reinstall the corefix and let know the results
Thanks
Raghavendra
Hi Wayne,
Reinstallation of fix resolved the issue
Thanks 
Regards,
Raghavendra
Hello,
We have a new issue now
the schedulers which are running on the existing instance are getting suspended with the below error
WTEESB05.axa-uk-test.intraxa:6666)Unknown Service: ie.axai.esb.events.emailNotifications:process. Scheduled task will not run.
The old instance is running on Port 5555
in the new instance we can see schedulers are created by themselves
we tried to specify with server to use specific hostname watt.server.scheduler.logical.hostname=InstanceName
but still some schedulers are failing because they run on server level logs
Hi Holger,
We have a new issue now
the schedulers which are running on the existing instance are getting suspended with the below error
WTEESB05.axa-uk-test.intraxa:6666)Unknown Service: ie.axai.esb.events.emailNotifications:process. Scheduled task will not run.
The old instance is running on Port 5555
in the new instance we can see schedulers are created by themselves
we tried to specify with server to use specific hostname watt.server.scheduler.logical.hostname=InstanceName
but still some schedulers are failing because they run on server level logs
Hi Raghavendra,
did you try to restart the “old” instance afterwards?
Or you might have to reactivate the scheduled tasks in IS Admin UI.
Regards,
Holger
Hi Holger,
yes i did restart the old instance
I reactivated the tasks in IS Admin UI but it fails with same error
one more observation what i am seeing is if i am creating any new task on new instance it gets created on old instance also
Hi Raghavendra,
are the two instances sharing the same database schema?
As long as the instances are not meant for being clustered, they should be using dedicated schemas (one for each instance).
Regards,
Holger
yes both the instances share the same database schema