Hi All,
I am using transformation service in a process where in I am using 1 instance of the translation service and using this same instance at the two steps in the process or itinary, what i am seeing sometime the instance is not able to find the file, xsl file that I had specified as runtime parameter in configuration, and it is not at the the normal process/or run.
I would appreciate help on this.
-Thanks
Which Sonic version are you using? I vaguely remember a bug we had in this area at some point. Could you also post a stack trace with the error?
Bug or not: I would recommend to not share service instances since you will introduce a performance bottleneck caused by the number of listeners you have. Sharing instances might also lead to (distributed) deadlocks trying to aquire the service's listener locks. So as best practice: never share!
Thomas
Here is the trace form logs
com.sonicsw.xq.XQServiceException: The stylesheet definition has not been specified for this service. Please specify the stylesheet as an init or runtime parameter.
at com.sonicsw.xq.service.xform.Xformer.apply(Unknown Source)
at com.sonicsw.xq.service.xform.Xformer.processMessage(Unknown Source)
at com.sonicsw.xq.service.xform.Xformer.processRules(Unknown Source)
at com.sonicsw.xq.service.xform.TransformationService.service(Unknown Source)
at com.sonicsw.xqimpl.service.ServiceMessageHandler.callService(Unknown Source)
at com.sonicsw.xqimpl.service.ServiceMessageHandler.handleMessageImmediate(Unknown Source)
at com.sonicsw.xqimpl.service.XQDispatcher.onMessageImmediate(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToServiceImmediate(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToAddressImmediate(Unknown Source)
at com.sonicsw.xqimpl.service.XQDispatchImpl.dispatch(Unknown Source)
at com.sonicsw.xqimpl.service.XQDispatchImpl.dispatch(Unknown Source)
at com.sonicsw.sts.enrichment.EnrichmentService.service(EnrichmentService.java:167)
at com.sonicsw.sts.baseService.BaseServiceImpl.service(BaseServiceImpl.java:231)
at com.sonicsw.xqimpl.service.ServiceMessageHandler.callService(Unknown Source)
at com.sonicsw.xqimpl.service.ServiceMessageHandler.handleMessage(Unknown Source)
at com.sonicsw.xqimpl.service.ProcessMessageHandler.doHandleMessage(Unknown Source)
at com.sonicsw.xqimpl.service.ProcessMessageHandler.handleMessage(Unknown Source)
at com.sonicsw.xqimpl.service.XQDispatcher.onMessage(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToService(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToAddress(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendEnvelopes(Unknown Source)
at com.sonicsw.xqimpl.service.XQDispatcher.onMessage(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToService(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToAddress(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendEnvelopes(Unknown Source)
at com.sonicsw.xqimpl.service.XQDispatcher.onMessage(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToService(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToAddress(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendEnvelopes(Unknown Source)
at com.sonicsw.xqimpl.service.XQDispatcher.onMessage(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToService(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToAddress(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendEnvelopes(Unknown Source)
at com.sonicsw.xqimpl.service.XQDispatcher.onMessage(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToService(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToAddress(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToProcess(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToProcess(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendToAddress(Unknown Source)
at com.sonicsw.xqimpl.service.MessageSendingHelper.sendEnvelopes(Unknown Source)
at com.sonicsw.xqimpl.service.XQDispatcher.onMessage(Unknown Source)
at com.sonicsw.xqimpl.endpoint.container.EndpointContextContainer.onMessage(Unknown Source)
at com.sonicsw.xq.connector.jms.JMSEndpoint$JMSEndpointListener.onMessage(Unknown Source)
at progress.message.jimpl.Session.deliver(Session.java:2952)
at progress.message.jimpl.Session.run(Session.java:2379)
at progress.message.jimpl.Session$SessionThread.run(Session.java:2743)
I am using sonic 7.5.1
I am not sure about that dead, as we are not using any custom code, or not sure if sonic internally does synchronized the access. We do not have much load though I seen this error.
I have a question further more on this after that,
I am using two instances in a intinary, If I would be using 10-12, I am sure it would not be a good idea to have 10-12 instances of the same objects(service), or do you think it is good idea?
Hi,
I think that this is related to SNC00068935 where we don't use DocumentBuilders in a thread safe manner. This is only fixed in 7.6.2, so you might be effected.
As for using many instances: Having 10 or 12 instances of a service object is mostly overhead on the memory usage. In terms of JMS connections and session you can balance the resources yourself by using the right number of listeners and having an entry endpoint or not. If course it makes a difference if you have 1 instance with 10 listeners or 10 instances with 10 listeners each. You should be careful with the latter.
Thomas
I agree that is why we are not using many instances of the service, and using the run time parameter.
Where I can see the details for SNC00068935? I tried from psdn and sonic knowledgebase, but did not find that.
Thanks
The details are in summary that we are reusing a Parser instance across threads. This causes errors like you saw. The fix is to have threadlocal document builders/parsers.
The only known workaround is to set the #listeners to 1 (assuming it is this problem).
The only way to be sure though is to run your tests in an 7.6.2 environment... Do you have the ability to do so?
No, that is the problem we are not migrating to 7.6.2 at this point in time.