Skip to Content
author's profile photo Former Member
Former Member

[PortalComponentContext.getProfile] Profile provision failed..


I have EP6.20,

Trying to deploy a PAR using the Portal Admin (System Admin -> Support -> Portal Runtime -> Administration Console) I get a "deploy successful" message (on both of the servers I have there...)

But, trying to access a component through the url, say:


I get the above error.

Looking at the log file I get:

<i> Object is invalid, most probably it doesn't exist anymore on the persistency:

at </i>....

Does anyone have an Idea???

Add a comment
10|10000 characters needed characters exceeded

Related questions

2 Answers

  • author's profile photo Former Member
    Former Member
    Posted on Jun 30, 2004 at 10:42 PM

    I faced the same problem, today.

    I couldn't solve it directly, but restart of the portal solved it !!

    If you find any answer, please let us know.

    Prasad Nutalapati

    Message was edited by: Prasad Nutalapati

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Jul 01, 2004 at 07:14 AM

    It seems the SAP are quite aware of this. If you look up OSS note 743857 you can see that HotFix 4 is upposed to resolve it. (SEE BELOW)

    From what I understand now it is a problem of caching and clearing the cache upon removal of the application.

    In other words, app-remover ain't doing what it is supposed to before this hotfix.

    Restarting the server is the only means I have found for now. Make sure you shutdown cleanly (type shutdown in shell) and not kill the shell process.

    Anaway, cheers.



    PAR Upload does not update all servers and therefore some servers keep

    running the previous version of the portal application.

    Other terms

    Files discrepency, MANIFEST, PAR Deployment

    Reason and Prerequisites

    When uploading a PAR file, the deployment process first updates the repository (storing the whole archive in the PCD) and then notifies all servers that a new version of the application is available.

    Each server node then needs to:

    - retrieve the new version from the repository

    - release all objects (components/services) depending on the application

    - update the file system with the new version

    - refresh the application classloader and restart load-on-startup services.

    This deployment process involves a lot of layers:

    - PCD Generic Layer (Persistence layer)

    - SoftCacheService (PCD Cache)

    - Application Repository (PAR Semantic Layer on top of the PCD)

    - Portal Application Broker (Layer responsible for the life-cycle of portal applications)

    - Notification Service/PRT Bridge (Layers used to communicate between sever nodes)

    With EP60 SP2 Patch2 and 3 the deployment process could fail because the notification sent by the PCD GL (to release the PCD cache) is delayed and therefore is received after the notification sent by PRT (to update of the local deployment).

    As a consequence some servers will still be running the old version although the new version is correctly stored in the PCD.

    Impacts at runtime are the following:

    - Components/iViews will still get old property values when using their profiles.

    - The HTML output will still show the old content (even when using JSP)

    - The "local version" column displayed when using the Archive Deploymentchecker will certainly display the MANIFEST version of the old version.

    Please note:

    - Releasing the PCD Cache (using the PCD Admin Tool) and forcing an update of the local deployment could improve the situation.

    - Removing the application using the Archive Remover could also remove the inconsistancy. But this did not work with the very first Patch3 version and led to a "Profile Provision Failed" exception.

    There was also noticed a Browser caching problem when using the PortalAnywhere.ArchiveDeploymentChecker tool. The HTML output was from time to time displaying wrong information because of the Browser cache. This was of course very confusing for the administrator since he/she couldn't trust the information displayed.


    The problem has been solved by EP60 SP2 Patch4 HF4. Actually each layer has been improved in order to make sure the local deployment is correctly updated on each server.

    - The ApplicationRepository now depends on the SoftCacheService and makes sure to trigger the PCD Notifications before sending its own update event.

    - The PCD GL Layer itself has been changed (best cleaning of the PCD cache)

    - Browse Caching has no impact anymore when using the Archive Deployment Cheker tool.

    - The Portal Application Broker has been changed too. Portal Component Context Items are now refreshed properly in order to take into account component profile changes

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.