• State Suggested Answer
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 5 subscribers
  • Views 5558 views
  • Users 0 members are here
Options
Related

FileBasedProject.PublishProject() succeeds but Studio indicates publish failed

Chris Pulsifer

We are having intermittent problems using the FIleBasedProject creation API. For some of the created projects we are unable to open in Studio. The error information states:

"The project with ID {0} can not be opened becasue it was not successfully published to the server"

However, the result of the PublishProject() call has a status of PublicationStatus.Published

Why are the projects not openable?
Rate translation
×
Suggest better translation
×
  • 0 in reply to Chris Pulsifer
    Seems like the SQL stored procedure [SDlSystem].[proj].[GetPublishedProjectInformation] is timing out for some reason.
    After a quick look at the SP, I would expect it to take (possibly significantly) longer if a greater number of project is published on the server.
    How many projects do you have on your server?
    Are there possibly any performance issues on the SQL Server?

    PS: Yes, PublicationStatus.Published is odd.
  • 0 in reply to Paul
    This system has been running for more than 3 years through multiple upgrades of both Studio and GroupShare with minimal changes.

    Not sure what you mean by "The file-based solution is not designed to handle heavy volumes with concurrent processing" but I don't think our usage is that heavy a load. This is a free standing program (not a Studio plug-in), which leverages the FileBasedProject APIs. There are at most 10 instances independently processing one project at a time. We typically process on the order of 100-200 projects a day. This seems like it would be a lighter load than a department full of translation analysts.

    Up through GroupShare 2015, we did not see the necessary capabilities available in the REST API. Given that our system was working fine, we did not investigate how far the REST API had advanced to see if it would now cover our needs in GS2017.

    At the beginning of the year, we were running Studio 2015 against GS 2015 with no issues. We later upgraded Studio to 2107 and rebuilt the program against the new version with no code changes and no problems running the system. We recently upgrade from GS2105 to GS 2107 and since the upgrade have seen a high failure rate.

    The first question I have is whether there is any known change that might have caused this impact? While this may not be the best solution model, it was working fine.

    The second issue is more frustrating and more critical. As stated in the question, the API returns a successful result on the Publish call, however GroupShare reports that the project failed to publish successfully. If we are doing something wrong, then by all means go ahead and fail. But it's not (to me) acceptable to return a success when the action failed. If I was using mismatched versions, I could see a disconnect between client code and server code, but this problem started to happen when I got them in sync.
  • 0 in reply to Raphael Batel
    @Raphael, Do you mean a large number of projects already published on the server or a large number being published simultaneously. Our simultaneous load is low but I believe we do have a large number of completed projects.
  • 0 in reply to Chris Pulsifer

    We just took a longer look at your support case and we believe that this may be caused by the total number of projects published.

    However, other simultaneous - especially project related - activities may of course also play a role. However, this depends a bit on how exactly you do things (and may also depend also on the performance of your SQL Server).

     

    Interestingly, the stored procedure that times out according to your log files has not changed at all in GroupShare 2017.

    I believe Adrian will look at a few further details together with you and will discuss the further steps.