• State Verified Answer
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 48 subscribers
  • Views 2236 views
  • Users 0 members are here
Options
Related

HttpWebRequest hangs in write plugin when publication status is Released

Paul Tyson

I'm developing a write plugin to do some processing when publication status goes to Released. The Run() method invokes an HttpWebRequest to external service. The request works fine when the plugin is called with publication in any status except Released. When the status is Released, the webrequest getResponse() method hangs, which is typically caused by another web request/response that hasn't been closed.

I've tried disabling all the other publication plugins, to verify that it is not another plugin causing the problem.

Is it possible there is some other process going on during publication release that has made a webrequest but didn't clean up after getting the response? It is recommended always to call response.Dispose() to release the connection.

Any other suggestions as to why the request only hangs when publication status is Released?
Rate translation
×
Suggest better translation
×
Parents
  • 0
    Dear Paul,

    Depending on the functionality you want the plugin to execute, a reason could be that you try to update a property which is no longer allowed as your publication is Released.
    Releasing a publication is restricting updates to the properties as well as these properties can influence the content which should be part of the generated output and hence could make the publication setup inconsistent with the output released to the market.

    In order to further investigate I would need answers to the questions below:

    Could you please share a little bit more information about the SDL Knowledge Center version you are developing this plugin against. Is it version 2014 or 2016?
    Could you also please share the functionality that you would like the plugin to perform as a 'Released' publication is rather restrictive in allowing updates in the properties.

    Kind Regards,

    Raf
  • 0 in reply to Raf Snijders
    We are using KC2016 SP2.

    The plugin isn't doing anything with the object properties. It needs the publication baseline to update an external service with status of all the topics. To get the baseline, the plugin makes an httpwebrequest to an infoshare webapp, which is a convenience wrapper for the CM Web services. The method that the plugin calls ultimately gets a Baseline object to get the baseline by its name.

    When the pub status is anything but "Released", everything works fine. When the pub status is "Released", the plugin webrequest apparently blocks the webapp from getting a WS Baseline object. I can see in the log files that after the plugin request times out, the webapp request is fulfilled. The mystery to me is why the publication status affects WS access to Baseline object.

    Thanks for any suggestions.
  • 0 in reply to Paul Tyson
    Hi Paul,

    Let me try to provide some feedback on the design of the IWrite plugins using your plugin flow (if I'm interpreting it correctly):
    * Your plugin will do the following:
    - Upon update of Publication metadata the plugin verifies the status it is being moved to.
    - If the status is different from 'Released' the plugin does not do anything
    - If the status equals 'Released' the plugin triggers a process to read the baseline information and send it to an external service.

    * IWrite plugins run in the transaction of the executed action, in your case a publication metadata update.
    * Releasing a publication will trigger additional checks and functionality like freezing the baseline. This action might include the baseline object in a lock state within the transaction as well.

    So giving the information above, my guess is that your plugin tries to read the baseline through a new 'transaction' while it is still locked by the initiating transaction. Hence it can not provide the information.
    The plugin times out (not throwing an error), the initiating transaction gets closed and the webrequest can provide the information requested.

    One way how you could get around this is by triggering a BackgroundTask request from within the IWrite plugin which will perform you actual requested flow.
    The main advantage is that the object(s) will no longer be locked by any transaction as the iwrite plugin is finished before the Background task is started.

    Do you think this paradigm of moving the actual functionality from your write plugin towards a background task could work?

    Kind Regards,

    Raf
Reply
  • 0 in reply to Paul Tyson
    Hi Paul,

    Let me try to provide some feedback on the design of the IWrite plugins using your plugin flow (if I'm interpreting it correctly):
    * Your plugin will do the following:
    - Upon update of Publication metadata the plugin verifies the status it is being moved to.
    - If the status is different from 'Released' the plugin does not do anything
    - If the status equals 'Released' the plugin triggers a process to read the baseline information and send it to an external service.

    * IWrite plugins run in the transaction of the executed action, in your case a publication metadata update.
    * Releasing a publication will trigger additional checks and functionality like freezing the baseline. This action might include the baseline object in a lock state within the transaction as well.

    So giving the information above, my guess is that your plugin tries to read the baseline through a new 'transaction' while it is still locked by the initiating transaction. Hence it can not provide the information.
    The plugin times out (not throwing an error), the initiating transaction gets closed and the webrequest can provide the information requested.

    One way how you could get around this is by triggering a BackgroundTask request from within the IWrite plugin which will perform you actual requested flow.
    The main advantage is that the object(s) will no longer be locked by any transaction as the iwrite plugin is finished before the Background task is started.

    Do you think this paradigm of moving the actual functionality from your write plugin towards a background task could work?

    Kind Regards,

    Raf
Children