Deployment hung

I was deploying my BC4J JSP app to standalone OC4J on NT server, and got the following message:
Beginning deployment to Oracle9i Application Server...
Invoking Oracle9iAS admin tool...
It stayed like that forever. I tested the connection in JDev and it was OK. What might be wrong?

It could be that the version of admin.jar that you are running in JDeveloper doesn't match the version of OC4J that you are deploying to. These kinds of hangs can occur when the deployment client version doesn't match the server version.
See Infrastructure Serrver is down for a similar discussion.

Similar Messages

Deploy a mapping hung

I am using OWB 11.2. When I deployed a mapping which maps source tables to a dimension (code generation mode: Set Based fail over to row based; both source and destination are Oracle), it hung there without error. DBA checked the database and didn't see any issue on the server side. It looks like the problem on client side, but my computer has 3G RAM and Pentium D CPU 3GHz which should not be a issue.
I had this problem before and I got rid of it by killing OWB and re-login. But this time, it doesn't work. Does it relate to configuration?

try to run the owb in debug mode then check the log file.
Check the link
Re: Internal Error happend: API0264: Cannot request lock....
Cheers
Nawneet

Application deployed from the software center hung at "in Progress"

How can you clear the "In Progress" state. The application has installed but the deployment monitor shows "in progress".

More info:
Troubleshooting Application Deployment in System Center 2012 Configuration Manager
http://social.technet.microsoft.com/wiki/contents/articles/11447.troubleshooting-application-deployment-in-system-center-2012-configuration-manager.aspx
We
are trying to better understand customer views on social support experience, so your participation in this
interview project would be greatly appreciated if you have time.
Thanks for helping make community forums a great place.

Deploy PAR with NWDS SP19

Hi All,
I am trying to deploy the PAR file from NWDS, it brings up the dialog and after i enter my password, the deployment progress is stuck, let us say at 80% and my NWDS is hung. I have to terminate it and reopen it again. I upgraded my NWDS recently from SP15 TO SP19. also my portal is on SP19. is this a bug with NWDS Patch.
Also, Just now I found that I am not able to deploy PAR files from the System Administration > Support> Portal Runtime --> Administration Console on Ep 6.0 SP19.
Did any of you guys encounter the same problems?
Any Help is appreciated.
Thanks
Message was edited by:
Reddy

Hi Reddy,
It sounds like some of the pluggins may be corrupted, have you tried reinstalling the NWDS?
Krishna Reddy

Helps for WLP9.2 in a cluster: deploy errors, propagation errors

I wrote a document for our portal project's production support that details how to fix several recuring problems with WLP9.2 (GA) in cluster. I'm sharing this with the community as a help.
Email me if you'd like updates or have additional scenarios / fixes or you'd like the word doc version.
Curt Smith, Atlanta WLP consultant, [email protected], put HELP WLP as a part of the subject please.
1     WLP 9.2 Environment
The cluster environment where these symptoms are frequently seen is described by the following:
1.     Solaris 9 on 4 cpu sparc boxes. 16Gb Ram. The VM is given ?Xmx1034m.
2.     Bea private patch: RSGT, fixed cluster deployments.
3.     Bea private patch: BG74, fixed session affinity, changed the session tracking cookie name back to the standard name: JSESSIONID.
4.     IBM UDB (DB2) using the Bea DB2 driver. FYI: the problems described below I don?t feel have any relationship to the DB used for a portal.
2     Common problems and their fixes
2.1     Failed deploy (Install) of a new portal application via the cluster console.
Problem symptoms:
After clicking Finish (or) Commit the console displays that there where errors. All errors require this procedure.
Fix steps:
1.     Shut down the whole cluster. Using Bea?s shutdown script takes too long, or doesn?t work if the Admin is down or hung.
a.     Find the PID to kill: lsof ?C | grep <listen port number>
b.     kill <pid>
c.     Run kill again and if the pid is still running then do: kill -9 <pid>
2.     Admin server:
a.     Remove file: <domain>/config/config.lok
b.     Edit file: <domain>/config/config.xml
c.     Remove all elements of: <app-deployment> ? </app-deployment>
d.     Start the Admin server
e.     Make sure it comes up in the running state. Use the console: servers ? admin ? control - resume if needed.
3.     Both Managed servers:
a.     cd <domain>/config
b.     rm ?rf *
This forces the re-down load of the cleaned up config.xml.
c.     cd <domain>/servers/<managed_name>
d.     rm ?rf tmp cache stage data
This cleans up stale or jammed sideways deploys. Be sure to delete all three directorys: tmp, cache, stage and data.
e.     Start each managed server.
f.     Make sure the managed instance comes up in the running state and not admin. Go to server-<instance>-control-Resume to set the run state to running.
You can now use the console to Install your applications.
2.2     The portal throws framework / container exceptions on one managed instance.
Problem symptoms:
If you see exceptions from the classloader re a framework class not found, serialization failure or error etc. In general the symptom is that the container is not stable, running correctly, not making sense or your application works on one managed instance but not on the other.
Fix steps:
1.     Shut down the problem managed instance. Using Bea?s shutdown script takes too long, or doesn?t work if the Admin is down or hung.
a.     Find the PID to kill: lsof ?C | grep <listen port number>
b.     kill <pid>
c.     Run kill again and if the pid is still running then do: kill -9 <pid>
2.     Perform these clean up steps on one or both managed instances:
a.     cd <domain>/config
b.     rm ?rf *
This forces the re-down load of the cleaned up config.xml.
c.     cd <domain>/servers/<managed_name>
d.     rm ?rf tmp cache stage data
This cleans up stale or jammed sideways deploys. Be sure to delete all three directorys: tmp, cache, stage and data.
e.     Start each managed server.
f.     Make sure the managed instance comes up in the running state and not admin. Go to server-<instance>-control-Resume to set the run state to running.
3.     The libraries and applications should auto deploy as the managed instance comes up. Once the managed instance goes into the running state, or you Resume into the running state. Your application should be accessible. Sometimes it takes a few seconds after going into the running state for all applications to be instantiated.
2.3     Content propagation fails on the commit step.
Problem symptoms:
In the log of the managed instance you specified in the propagation ant script you?ll see exceptions regarding not being able to create or instantiate a dynamic delegated role.
There is an underlying bug / robustness issue with WLP9.2 (GA) where periodically you can?t create delegated roles either with the PortalAdmin or via the propagation utility.
Important issue:
This procedure was supplied by Bea which will remove from the internal LDAP and the portal DB your custom / created roles. This will leave your cluster in the new installation state with just the default users and roles: weblogic and portaladmin. The implications are that you?ll have to boot your cluster with console user: weblogic / weblogic. You can then add back your secure console user/password but you?ll have to do this over and over as propagations fail. The observed failure rate is once every 2-3 weeks if you do propagations daily.
Note:
The following assumes that you left the default console user weblogic password to be the default password of: weblogic. The following procedure deletes the local LDAP but leaves the rows in the DB.users table including the SHA-1 hashed passwords. The following procedure should still work if you changed the password for weblogic, but it probably won?t work if you try to substitute your secure console user/pw because there will be no delegated authorization roles mapping to your custom console user. You might experiment with this scenario.
Fix steps:
1.     Shut down the whole cluster. Using Bea?s shutdown script takes too long, or doesn?t work if the Admin is down or hung.
a.     Find the PID to kill: lsof ?C | grep <listen port number>
b.     kill <pid>
c.     Run kill again and if the pid is still running then do: kill -9 <pid>
2.     Admin server:
a.     Remove directory: <domain>/servers/AdminServer/data/ldap
b.     Run this SQL script after you edit it for your schema:
delete from yourschema.P13N_DELEGATED_HIERARCHY;
delete from yourschema.P13N_ENTITLEMENT_POLICY;
delete from yourschema.P13N_ENTITLEMENT_RESOURCE;
delete from yourschema.P13N_ENTITLEMENT_ROLE;
delete from yourschema.P13N_ENTITLEMENT_APPLICATION;
commit;
c.     Start the Admin server
d.     Make sure it comes up in the running state. Use the console: servers ? admin ? control - resume if needed.
3.     Both Managed servers:
a.     cd <domain>/servers/<managed_name>
b.     rm ?rf data
This forces the re-down load of the LDAP directory.
c.     Start each managed server.
d.     Make sure the managed instance comes up in the running state and not admin. Go to server-<instance>-control-Resume to set the run state to running.
2.4     The enterprise portal DB fails and needs to be restored OR switch DB instances
Restoring a portal DB or switching existing DBs are similar scenarios. The issues that you?ll face with WLP9.2 since it now uses a JDBCauthenticator to authenticate and authorize the console / boot user you need to first be able to connect to the DB before the admin and managed instances can boot. If you haven?t properly encrypted the DB user?s password in the <domain>/config/jdbc/*.xml files, then you?ll not be able to boot the admin server since you won?t be able to create a JDBC connection to the DB. The boot messages are not clear as to what the failure is.
You?ll need to know an Admin role user and password that?s in the DB you?re wanting to connect to, to put into boot.properties and on the managed instances in their boot.properties or startManaged scripts. Don?t forget that the managed instances have local credentials which is new for 9.2. They are in the startManaged script in clear text or a local boot.properties.
Note:
The passwords in the DB are SHA-1 hashed and there is no SHA-1 hash generator tool so you can?t change a password via SQL, but you can move the password from one DB to another. This is possible because the domain encryption salt is not used to generate the SHA-1 string. As it turns out, the SHA-1 string is compatible with all 9.2 cluster domains. IE the domain DES3 salt has nothing to do with password verification. The same password SHA-1 string taken from different domains or even same domain but different users will be different, this is just a randomization put into the algorithm yet every domain will be able to validate the given password against the DB?s SHA-1 string. Because of this, I?ve not had any problem moving DB instances between clusters, especially if I?ve given up on security and use weblogic/weblogic as the console user and this user / pw is in every DB.
Steps:
The assumption for restoring a DB is that the DB has been restored but it?s an older version and doesn?t have the console user/pw that is in boot.properties. At this point swaping a DB is the same as restoring an old version of the portal DB.
1.     Edit the console user and password as clear text into: <domain>/servers/AdminServers/security/boot.properties
This is where you may give in and use weblogic/weblogic.
2.     Set the correct DB access password encryption in the jdbc/*.xml files.
a.     cd <domain>/bin
b.     . ./setDomainEnv.sh or if you?re on windows just run: setDomainEnv.cmd
c.     java weblogic.security.Encrypt <the_db_password>
d.     Edit the returned string into every <domain>/config/jdbc/*.xml
e.     Make sure the *.xml files point to the correct DB host, port, schema, DB name, DB user.
3.     Start the Admin server. I should come up. If it doesn?t it has to be not being able to create a connection to the DB, which depends on the *.xml having the correct user and DES-3 encrypted password.
4.     Edit the new console user/password on the managed instance bin/startManaged script or the local boot.properties.
5.     Start the managed instances.
2.5     Install patches on a host that does not have internet access
The short description is to run smart update on a host that does have internet access. Fetch out of the <domain>/utils/bsu/cache_dir     directory the downloaded patch jar and xml. Manually apply the patch to your non-internet accessible hosts.

I wrote a document for our portal project's production support that details how to fix several recuring problems with WLP9.2 (GA) in cluster. I'm sharing this with the community as a help.
Email me if you'd like updates or have additional scenarios / fixes or you'd like the word doc version.
Curt Smith, Atlanta WLP consultant, [email protected], put HELP WLP as a part of the subject please.
1     WLP 9.2 Environment
The cluster environment where these symptoms are frequently seen is described by the following:
1.     Solaris 9 on 4 cpu sparc boxes. 16Gb Ram. The VM is given ?Xmx1034m.
2.     Bea private patch: RSGT, fixed cluster deployments.
3.     Bea private patch: BG74, fixed session affinity, changed the session tracking cookie name back to the standard name: JSESSIONID.
4.     IBM UDB (DB2) using the Bea DB2 driver. FYI: the problems described below I don?t feel have any relationship to the DB used for a portal.
2     Common problems and their fixes
2.1     Failed deploy (Install) of a new portal application via the cluster console.
Problem symptoms:
After clicking Finish (or) Commit the console displays that there where errors. All errors require this procedure.
Fix steps:
1.     Shut down the whole cluster. Using Bea?s shutdown script takes too long, or doesn?t work if the Admin is down or hung.
a.     Find the PID to kill: lsof ?C | grep <listen port number>
b.     kill <pid>
c.     Run kill again and if the pid is still running then do: kill -9 <pid>
2.     Admin server:
a.     Remove file: <domain>/config/config.lok
b.     Edit file: <domain>/config/config.xml
c.     Remove all elements of: <app-deployment> ? </app-deployment>
d.     Start the Admin server
e.     Make sure it comes up in the running state. Use the console: servers ? admin ? control - resume if needed.
3.     Both Managed servers:
a.     cd <domain>/config
b.     rm ?rf *
This forces the re-down load of the cleaned up config.xml.
c.     cd <domain>/servers/<managed_name>
d.     rm ?rf tmp cache stage data
This cleans up stale or jammed sideways deploys. Be sure to delete all three directorys: tmp, cache, stage and data.
e.     Start each managed server.
f.     Make sure the managed instance comes up in the running state and not admin. Go to server-<instance>-control-Resume to set the run state to running.
You can now use the console to Install your applications.
2.2     The portal throws framework / container exceptions on one managed instance.
Problem symptoms:
If you see exceptions from the classloader re a framework class not found, serialization failure or error etc. In general the symptom is that the container is not stable, running correctly, not making sense or your application works on one managed instance but not on the other.
Fix steps:
1.     Shut down the problem managed instance. Using Bea?s shutdown script takes too long, or doesn?t work if the Admin is down or hung.
a.     Find the PID to kill: lsof ?C | grep <listen port number>
b.     kill <pid>
c.     Run kill again and if the pid is still running then do: kill -9 <pid>
2.     Perform these clean up steps on one or both managed instances:
a.     cd <domain>/config
b.     rm ?rf *
This forces the re-down load of the cleaned up config.xml.
c.     cd <domain>/servers/<managed_name>
d.     rm ?rf tmp cache stage data
This cleans up stale or jammed sideways deploys. Be sure to delete all three directorys: tmp, cache, stage and data.
e.     Start each managed server.
f.     Make sure the managed instance comes up in the running state and not admin. Go to server-<instance>-control-Resume to set the run state to running.
3.     The libraries and applications should auto deploy as the managed instance comes up. Once the managed instance goes into the running state, or you Resume into the running state. Your application should be accessible. Sometimes it takes a few seconds after going into the running state for all applications to be instantiated.
2.3     Content propagation fails on the commit step.
Problem symptoms:
In the log of the managed instance you specified in the propagation ant script you?ll see exceptions regarding not being able to create or instantiate a dynamic delegated role.
There is an underlying bug / robustness issue with WLP9.2 (GA) where periodically you can?t create delegated roles either with the PortalAdmin or via the propagation utility.
Important issue:
This procedure was supplied by Bea which will remove from the internal LDAP and the portal DB your custom / created roles. This will leave your cluster in the new installation state with just the default users and roles: weblogic and portaladmin. The implications are that you?ll have to boot your cluster with console user: weblogic / weblogic. You can then add back your secure console user/password but you?ll have to do this over and over as propagations fail. The observed failure rate is once every 2-3 weeks if you do propagations daily.
Note:
The following assumes that you left the default console user weblogic password to be the default password of: weblogic. The following procedure deletes the local LDAP but leaves the rows in the DB.users table including the SHA-1 hashed passwords. The following procedure should still work if you changed the password for weblogic, but it probably won?t work if you try to substitute your secure console user/pw because there will be no delegated authorization roles mapping to your custom console user. You might experiment with this scenario.
Fix steps:
1.     Shut down the whole cluster. Using Bea?s shutdown script takes too long, or doesn?t work if the Admin is down or hung.
a.     Find the PID to kill: lsof ?C | grep <listen port number>
b.     kill <pid>
c.     Run kill again and if the pid is still running then do: kill -9 <pid>
2.     Admin server:
a.     Remove directory: <domain>/servers/AdminServer/data/ldap
b.     Run this SQL script after you edit it for your schema:
delete from yourschema.P13N_DELEGATED_HIERARCHY;
delete from yourschema.P13N_ENTITLEMENT_POLICY;
delete from yourschema.P13N_ENTITLEMENT_RESOURCE;
delete from yourschema.P13N_ENTITLEMENT_ROLE;
delete from yourschema.P13N_ENTITLEMENT_APPLICATION;
commit;
c.     Start the Admin server
d.     Make sure it comes up in the running state. Use the console: servers ? admin ? control - resume if needed.
3.     Both Managed servers:
a.     cd <domain>/servers/<managed_name>
b.     rm ?rf data
This forces the re-down load of the LDAP directory.
c.     Start each managed server.
d.     Make sure the managed instance comes up in the running state and not admin. Go to server-<instance>-control-Resume to set the run state to running.
2.4     The enterprise portal DB fails and needs to be restored OR switch DB instances
Restoring a portal DB or switching existing DBs are similar scenarios. The issues that you?ll face with WLP9.2 since it now uses a JDBCauthenticator to authenticate and authorize the console / boot user you need to first be able to connect to the DB before the admin and managed instances can boot. If you haven?t properly encrypted the DB user?s password in the <domain>/config/jdbc/*.xml files, then you?ll not be able to boot the admin server since you won?t be able to create a JDBC connection to the DB. The boot messages are not clear as to what the failure is.
You?ll need to know an Admin role user and password that?s in the DB you?re wanting to connect to, to put into boot.properties and on the managed instances in their boot.properties or startManaged scripts. Don?t forget that the managed instances have local credentials which is new for 9.2. They are in the startManaged script in clear text or a local boot.properties.
Note:
The passwords in the DB are SHA-1 hashed and there is no SHA-1 hash generator tool so you can?t change a password via SQL, but you can move the password from one DB to another. This is possible because the domain encryption salt is not used to generate the SHA-1 string. As it turns out, the SHA-1 string is compatible with all 9.2 cluster domains. IE the domain DES3 salt has nothing to do with password verification. The same password SHA-1 string taken from different domains or even same domain but different users will be different, this is just a randomization put into the algorithm yet every domain will be able to validate the given password against the DB?s SHA-1 string. Because of this, I?ve not had any problem moving DB instances between clusters, especially if I?ve given up on security and use weblogic/weblogic as the console user and this user / pw is in every DB.
Steps:
The assumption for restoring a DB is that the DB has been restored but it?s an older version and doesn?t have the console user/pw that is in boot.properties. At this point swaping a DB is the same as restoring an old version of the portal DB.
1.     Edit the console user and password as clear text into: <domain>/servers/AdminServers/security/boot.properties
This is where you may give in and use weblogic/weblogic.
2.     Set the correct DB access password encryption in the jdbc/*.xml files.
a.     cd <domain>/bin
b.     . ./setDomainEnv.sh or if you?re on windows just run: setDomainEnv.cmd
c.     java weblogic.security.Encrypt <the_db_password>
d.     Edit the returned string into every <domain>/config/jdbc/*.xml
e.     Make sure the *.xml files point to the correct DB host, port, schema, DB name, DB user.
3.     Start the Admin server. I should come up. If it doesn?t it has to be not being able to create a connection to the DB, which depends on the *.xml having the correct user and DES-3 encrypted password.
4.     Edit the new console user/password on the managed instance bin/startManaged script or the local boot.properties.
5.     Start the managed instances.
2.5     Install patches on a host that does not have internet access
The short description is to run smart update on a host that does have internet access. Fetch out of the <domain>/utils/bsu/cache_dir     directory the downloaded patch jar and xml. Manually apply the patch to your non-internet accessible hosts.

Issue with deployment

We tried deploying the component through JSPM, but JSPM is not working properly, so we are trying to deploy the software components through SDM.
     We have started to deploy the all the component together it is getting stuck after some time.
     We have started to deploy the component one by one it is still getting stuck after some time.
Can anybody please help us out.
Below is the log.
<!LOGHEADER[START]/>
<!HELP[Manual modification of the header may cause parsing problem!]/>
<!LOGGINGVERSION[1.5.3.7185 - 630]/>
<!NAME[G:\usr\sap\NWB\DVEBMGS00\SDM\program\log\sdmlog20090413.log]/>
<!PATTERN[sdmlog20090413.log]/>
<!FORMATTER[com.sap.tc.logging.TraceFormatter(%24d %s: %m)]/>
<!ENCODING[Cp1252]/>
<!LOGHEADER[END]/>
Apr 13, 2009 3:02:25 PM Info:
Apr 13, 2009 3:02:25 PM Info: ===============================================
Apr 13, 2009 3:02:25 PM Info: =   Starting to execute command 'remotegui'   =
Apr 13, 2009 3:02:25 PM Info: ===============================================
Apr 13, 2009 3:02:27 PM Info: SDM started successfully.
Apr 13, 2009 3:06:12 PM Info:
Apr 13, 2009 3:06:12 PM Info: ===============================================
Apr 13, 2009 3:06:12 PM Info: =   Starting to execute command 'remotegui'   =
Apr 13, 2009 3:06:12 PM Info: ===============================================
Apr 13, 2009 3:06:14 PM Info: SDM started successfully.
Apr 13, 2009 3:06:48 PM Info:
Apr 13, 2009 3:06:48 PM Info: ============================================
Apr 13, 2009 3:06:48 PM Info: =   Starting to execute command 'server'   =
Apr 13, 2009 3:06:48 PM Info: ============================================
Apr 13, 2009 3:06:48 PM Info: Starting SDM - Software Deployment Manager...
Apr 13, 2009 3:06:48 PM Info: tc/SL/SDM/SDM/sap.com/SAP AG/7.0009.20060817110748.0000
Apr 13, 2009 3:06:49 PM Info: ====================================
Apr 13, 2009 3:06:49 PM Info: JControl is shutting SDM Server down
Apr 13, 2009 3:06:49 PM Info: ====================================
Apr 13, 2009 3:06:49 PM Info: Server finished sending back the answer of the ShutdownRequest.
Apr 13, 2009 3:06:49 PM Info: Shutting dispatcher down
Apr 13, 2009 3:06:54 PM Info:
Apr 13, 2009 3:06:54 PM Info: ============================================
Apr 13, 2009 3:06:54 PM Info: =   Starting to execute command 'server'   =
Apr 13, 2009 3:06:54 PM Info: ============================================
Apr 13, 2009 3:06:54 PM Info: Starting SDM - Software Deployment Manager...
Apr 13, 2009 3:06:55 PM Info: tc/SL/SDM/SDM/sap.com/SAP AG/7.0009.20060817110748.0000
Apr 13, 2009 3:06:57 PM Info: SDM operation mode successfully set to: Integrated
Apr 13, 2009 3:06:58 PM Info: JStartupFramework is requesting to start the SDM Server.
Apr 13, 2009 3:06:58 PM Info: Start the SDM Server integrated in the JStartupFramework.
Apr 13, 2009 3:06:58 PM Info: Initializing Network Manager (50017)
Apr 13, 2009 3:06:58 PM Info: Starting SDM Server listening on port 50018
Apr 13, 2009 3:06:58 PM Info: SDM started successfully.
Apr 13, 2009 3:08:44 PM Info:
Apr 13, 2009 3:08:44 PM Info: ===============================================
Apr 13, 2009 3:08:44 PM Info: =   Starting to execute command 'remotegui'   =
Apr 13, 2009 3:08:44 PM Info: ===============================================
Apr 13, 2009 3:08:45 PM Info: SDM started successfully.
Apr 13, 2009 3:11:44 PM Info:
Apr 13, 2009 3:11:44 PM Info: ===============================================
Apr 13, 2009 3:11:44 PM Info: =   Starting to execute command 'remotegui'   =
Apr 13, 2009 3:11:44 PM Info: ===============================================
Apr 13, 2009 3:11:45 PM Info: SDM started successfully.
Apr 13, 2009 3:11:52 PM Info: Opened client connection to punitp02979 (IP address punitp02979/<ipaddress>, remote port 2561)
Apr 13, 2009 3:11:52 PM Error: Wrong password supplied - Request for Logon rejected. Remaining logon attempts until SDM server will be shut down: 2
Apr 13, 2009 3:11:55 PM Info: Close client connection to punitp02979/<ipaddress>, remote port 2561
Apr 13, 2009 3:12:04 PM Info:
Apr 13, 2009 3:12:04 PM Info: ===============================================
Apr 13, 2009 3:12:04 PM Info: =   Starting to execute command 'remotegui'   =
Apr 13, 2009 3:12:04 PM Info: ===============================================
Apr 13, 2009 3:12:05 PM Info: SDM started successfully.
Apr 13, 2009 3:15:02 PM Info:
Apr 13, 2009 3:15:02 PM Info: ===============================================
Apr 13, 2009 3:15:02 PM Info: =   Starting to execute command 'remotegui'   =
Apr 13, 2009 3:15:02 PM Info: ===============================================
Apr 13, 2009 3:15:04 PM Info: SDM started successfully.
Apr 13, 2009 3:15:11 PM Info: Opened client connection to punitp02979 (IP address punitp02979/<ipaddress>, remote port 2654)
Apr 13, 2009 3:15:11 PM Info: Request for Logon as admin accepted
Apr 13, 2009 3:16:14 PM Info: Loading archive 'G:\usr\sap\trans\EPS\in\BPMDMAPPLI06_4.sca'
Apr 13, 2009 3:16:27 PM Info: Actions per selected component:
Apr 13, 2009 3:16:27 PM Info: No action: Selected development component 'com.sap.mdm.uwl'/'sap.com'/'SAP AG'/'5.50.20090119083803.0000'/'1' will not update currently deployed development component 'com.sap.mdm.uwl'/'sap.com'/'SAP AG'/'5.50.20090119083803.0000'/'0'.
Apr 13, 2009 3:16:27 PM Info: No action: Selected development component 'com.sap.mdm.uwl.config'/'sap.com'/'SAP AG'/'5.50.20090119083803.0000'/'1' will not update currently deployed development component 'com.sap.mdm.uwl.config'/'sap.com'/'SAP AG'/'5.50.20090119083803.0000'/'0'.
Apr 13, 2009 3:16:27 PM Info: Initial deployment: Selected software component 'BP_MDM_APPLICATION'/'sap.com'/'SAP AG'/'1000.5.50.6.4.20090119093241''/'1' will be deployed.
Apr 13, 2009 3:16:27 PM Info: No action: Selected development component 'com.sap.pct.mdm.appl.masteriviews'/'sap.com'/'SAP AG'/'5.50.20090119083803.0000'/'1' will not update currently deployed development component 'com.sap.pct.mdm.appl.masteriviews'/'sap.com'/'SAP AG'/'5.50.20090119083803.0000'/'0'.
Apr 13, 2009 3:16:27 PM Info: Initial deployment: Selected development component 'com.sap.pct.mdm.appl.packages.mdm_550'/'sap.com'/'SAP AG'/'5.50.20090119083803.0000'/'1' will be deployed.
Apr 13, 2009 3:16:37 PM Info: Saved current Engine state.
Apr 13, 2009 3:16:39 PM Info: Starting: Initial deployment: Selected development component 'com.sap.pct.mdm.appl.packages.mdm_550'/'sap.com'/'SAP AG'/'5.50.20090119083803.0000'/'1' will be deployed.
Apr 13, 2009 3:16:39 PM Info: SDA to be deployed: G:\usr\sap\NWB\DVEBMGS00\SDM\root\origin\sap.com\com.sap.pct.mdm.appl.packages.mdm_550\SAP AG\1\5.50.20090119083803.0000\com.sap.pct.mdm.appl.packages.mdm_550.epa
Apr 13, 2009 3:16:39 PM Info: Software type of SDA: single-module
Apr 13, 2009 3:16:39 PM Info: ***** Begin of SAP J2EE Engine Deployment (J2EE Module) *****

Hi,
You could check the most recent logs under the SDM log directory:
<drive>:\usr\sap\<sid>\JC00\SDM\program\log
esp ones like sdm_*.err. These normally contain information about issues related to memory while loading the archives for deployment. We had memory issue resulting in SDM getting hung.
Hope it helps.
Regards,
Srikishan

Hung User Accounts

Post Author: Rlitts
CA Forum: Authentication
I'm sorry if this is already been a topic; but I can't find anything in the administration manual regarding hung users. I'm new to BO Enterprise and was not here when it was installed, so I don't know what the installation parms are. In any event; we have a problem with users "x"ing out instead of logging off and the session gets hung; which in turn eats up a license. The only way we've found to resolve this is to stop/start the BO application, which frees up the sessions. I've got to believe that there's a better way to do it...?? Anyone help me?
Thanks,
Roy

Post Author: TAZ
CA Forum: Authentication
Well if you are using IE6 then you can set a parameter to logoff when the browser is closed. This is set by default so I'll assume your using IE7.
If that's the case then Microsoft seems to have closed a security hole that we used to close the browser. Some things that are being done involve changing session timeouts/cleanup in the web.xml(java) /web.config(.net)
There may be current issues open as they are usually handled by our deployment team.
You should be able to search for these timeouts in our KB's as well or just read through the files themselves for commented explainations.
Regards,
Tim

Hung in the oracle.jbo.pool.ResourcePool.useResource

Our customers reproduced the following stack trace (JDEVADF_11.1.1.5.0_GENERIC_110409.0025.6013 on Windows):
<Aug 30, 2011 1:56:22 PM EEST> <Error> <WebLogicServer> <BEA-000337> <[STUCK] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "652" seconds working on the request "weblogic.servlet.internal.ServletRequestImpl@13619bb[
GET /Demo-ViewController-context-root/Jobs.jspx?_afrWindowMode=0&_afrLoop=220132689544278&_adf.ctrl-state=xuimbozp8_4 HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: en-us
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2; .NET CLR 1.1.4322; .NET4.0C; .NET4.0E)
Connection: Keep-Alive
Cookie: JSESSIONID=3ycRTc1JckrC0yQYGBQpQT9VMpVMwL2f1zhTGMj2Gy43gSndgy74!1352733307
]", which is more than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace:
     java.lang.Object.wait(Native Method)
     oracle.jbo.pool.ResourcePool.useResource(ResourcePool.java:279)
     oracle.jbo.common.ampool.ApplicationPoolImpl.doCheckout(ApplicationPoolImpl.java:2339)
     oracle.jbo.common.ampool.ApplicationPoolImpl.useApplicationModule(ApplicationPoolImpl.java:3242)
     oracle.jbo.common.ampool.SessionCookieImpl.useApplicationModule(SessionCookieImpl.java:572)
     oracle.jbo.http.HttpSessionCookieImpl.useApplicationModule(HttpSessionCookieImpl.java:234)
     oracle.jbo.common.ampool.SessionCookieImpl.useApplicationModule(SessionCookieImpl.java:505)
     oracle.jbo.common.ampool.SessionCookieImpl.useApplicationModule(SessionCookieImpl.java:500)
     oracle.jbo.server.SessionImpl.findSharedApplicationModule(SessionImpl.java:834)
     oracle.jbo.server.ApplicationModuleImpl.findOrCreateSharedApplicationModule(ApplicationModuleImpl.java:8578)
     model.SessionAppModuleImpl.getJobs(SessionAppModuleImpl.java:24)
     sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     java.lang.reflect.Method.invoke(Method.java:597)
     oracle.adf.model.binding.DCInvokeMethod.invokeMethod(DCInvokeMethod.java:648)
     oracle.adf.model.binding.DCDataControl.invokeMethod(DCDataControl.java:2142)
I can reproduce this problem with the following steps:
1) Create two application module: SessionAppModule (session app module) and SharedAppModule (shared application module) and let these modules use the same data source jdbc/hdDS
2) SessionAppModule calls method of the SharedAppModule using approach suggested in the http://www.avromroyfaderman.com/2008/09/shared-application-module-instance-tricks-part-i-service-methods/:
public ViewObject getJobs() {
ApplicationModule sharedModule =
findOrCreateSharedApplicationModule("SharedAppModule", "model.SharedAppModule", SHARED_SCOPE_APPLICATION);
return sharedModule.findViewObject("JobView1");
3) List of the jobs is displayed on the page (lets say Jobs.jspx)
With this simple application:
1) Open Jobs.jspx
2) Close browser
3) Repeat 1-2
4) Restart oracle instance which supplies connections for jdbc/hdDS
5) Repeat 1-3
Hung is reproduced on step 5
The questions are --- Is it safe to use findOrCreateSharedApplicationModule in the way above? Do we need somehow release/cleanup SharedAppModule instance received from findOrCreateSharedApplicationModule?
In debugger I see that oracle.jbo.pool.ResourcePool waits until application module in destroyed state becomes available --- it seems rather suspicious.

Just to confirm that this is not a Library or deployment setup problem, Now, I changed the deployment scope to include business components in the ViewController to just to be sure it was being picked up in the ViewController too. I Created a separate AppModule in the ViewController and Added the VO to it, It Ran Properly including the Addition and Commit Control.

Deploy Windows Management Framework 4.0 with SCCM

Hey guys,
I need to deploy the Windows Management Framework 4.0 using the Application Model in SCCM 2012 R2. I've got all the silent install/uninstall commands figured out, the only place I'm hung up on is the detection method. Anyone know how I could address that?
(i.e. PowerShell, not the .NET Framework)

Here's an article with an almost correct answer: http://blogs.msdn.com/b/powershell/archive/2009/06/25/detection-logic-poweshell-installation.aspx
For v3 and 4, the registry key is slightly different: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\3 instead of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1
Jason | http://blog.configmgrftw.com

Error blocking deployment?

I am deploying a JDev 10g preview UIX/TopLink application to a standalone OC4J 9.0.4. I have deployed this application to this server several times before. We had changed the database schema and the copy of the application on the server had thrown an 'invalid column name' exception which was showing in the console. I went to deploy a new copy of the application from JDev to the server and it got as far as calling the admin.jar to start the deployment and just hung. I waited a over half an hour -- doing other things :) -- and finally got frustrated and decided to kill the server. I hit Ctrl-C in the server console, and instead of killing the server, the deployment immediately started (JDev was still running with the deployment pending).
What did I kill?
Why was this error blocking new deployments?
How can I avoid this situation in the future?

Yes, it was on a Windows box. If that's what it was,
that truly sucks. That would mean a client could
easily and inadvertently lock up their application
server -- I'll have to experiment with this...It happens to me all the time -- I use Ant to deploy and I see it sitting there just waiting. Ahh, go click in the Window. I find it happends more frequently during development cycles where I'm scrolling back and looking at log messages, etc. and I click in a Window. It may just be how I have my run window setup, but I don't remember clicking a 'stall if text selected' checkbox.
My Linux box never has the same problem .... ;-)
Let us know what you find out.
cheers
-steve-

Hung WebLogic Server in Adobe LiveCycle ES Update 1 (8.2.1)

Hi. Please feel free to move this post to a better forum if it doesn't belong in the WebLogic install forum. I'm posting my findings to help the end user communty and Adobe support staff, so they can better assist users. I hope the information helps other avoid the problems because this problem took a LONG time to fix with no real insight by vendors. The solution happened through luck when I upgraded the JDK for better troubleshooting.
Problem Description:
Occasionally in a production environment one of my managed WebLogic servers running LC ES Update 1 (8.2.1) would hang. A restart of the managed server was required each time it was hung. The restart was happening almost daily which isn't acceptable in an enterprise environment.
Symptoms:
* I would see stalled methods in my client code waiting for LC ES Update 1 to respond when it hangs. I would notice stuck threads in my client code too.
* FormsIVS and OutputIVS were deployed to all managed servers as test/verification tools, but the hung WebLogic instance wouldn't show the IVS page.
* If you visited the WebLogic admin console, then you normally see a RUNNING, OK health state. When the managed WebLogic server hung I would see RUNNING, <blank> status.
* I couldn't click on the hung managed servers Monitoring tab to see what it stuck on.
* I couldn't do garbage collections on the hung server using a WLST thread dumps.
Solution:
Upgrade from WebLogic 9.2 MP3 default JRockit 27.4 (1.5.0_12) to JRockit 28.0 (1.5.0_24). Here are some high level steps on what I had to do:
1. Copied the JRockit JDK to the box
2. Set the JAVA_HOME to the new JRockit JDK location
3. Updated setDomainEnv.cmd, config.xml, commEnv.cmd to the new JAVA_HOME location
4. Shut down all servers (admin, node manager, managed servers)
5. Edit the Server Start classpath that had any reference to the old Java location
6. Reinstall the Windows services to get them to use the new JDK.
Environment/Hardware:
Windows 2003 R2 SP2 (32-bit), Oracle RAC 10.2.0.4
8 Xeon dual core 2.8 GHz CPU, 16 GB RAM
Adobe LiveCycle Environment:
Adobe LiveCycle ES Update 1 (8.2.1) + QF 3.19, QF 3.72, QF 3.76, WebLogic 9.2 MP3 (32-bit), JRockit 27.4 (1.5.0_12) (32-bit)
* Only had Forms ES, Output ES
WebLogic 9.2 MP3 Configuration:
1 admin server, 1 node manager, 4 managed servers on the same physical box in a vertical cluster

Hi. Please feel free to move this post to a better forum if it doesn't belong in the WebLogic install forum. I'm posting my findings to help the end user communty and Adobe support staff, so they can better assist users. I hope the information helps other avoid the problems because this problem took a LONG time to fix with no real insight by vendors. The solution happened through luck when I upgraded the JDK for better troubleshooting.
Problem Description:
Occasionally in a production environment one of my managed WebLogic servers running LC ES Update 1 (8.2.1) would hang. A restart of the managed server was required each time it was hung. The restart was happening almost daily which isn't acceptable in an enterprise environment.
Symptoms:
* I would see stalled methods in my client code waiting for LC ES Update 1 to respond when it hangs. I would notice stuck threads in my client code too.
* FormsIVS and OutputIVS were deployed to all managed servers as test/verification tools, but the hung WebLogic instance wouldn't show the IVS page.
* If you visited the WebLogic admin console, then you normally see a RUNNING, OK health state. When the managed WebLogic server hung I would see RUNNING, <blank> status.
* I couldn't click on the hung managed servers Monitoring tab to see what it stuck on.
* I couldn't do garbage collections on the hung server using a WLST thread dumps.
Solution:
Upgrade from WebLogic 9.2 MP3 default JRockit 27.4 (1.5.0_12) to JRockit 28.0 (1.5.0_24). Here are some high level steps on what I had to do:
1. Copied the JRockit JDK to the box
2. Set the JAVA_HOME to the new JRockit JDK location
3. Updated setDomainEnv.cmd, config.xml, commEnv.cmd to the new JAVA_HOME location
4. Shut down all servers (admin, node manager, managed servers)
5. Edit the Server Start classpath that had any reference to the old Java location
6. Reinstall the Windows services to get them to use the new JDK.
Environment/Hardware:
Windows 2003 R2 SP2 (32-bit), Oracle RAC 10.2.0.4
8 Xeon dual core 2.8 GHz CPU, 16 GB RAM
Adobe LiveCycle Environment:
Adobe LiveCycle ES Update 1 (8.2.1) + QF 3.19, QF 3.72, QF 3.76, WebLogic 9.2 MP3 (32-bit), JRockit 27.4 (1.5.0_12) (32-bit)
* Only had Forms ES, Output ES
WebLogic 9.2 MP3 Configuration:
1 admin server, 1 node manager, 4 managed servers on the same physical box in a vertical cluster

Calling an EJB deployed in OC4J from a Java Stored Procedure

Hi all,
Well, I've been trying to figure this out for a bit now and haven't come up with a solution.
I have a Java Stored Procedure in a 9i database and would like to call an EJB deployed in the OC4J Container but DO NOT want to load the various Orion JAR files into the database.
I get hung up on the JNDI piece.
Has anyone figured out how to do this?
Got some code?
Thanks!

Doug,
This is not possible in Oracle9i Release1. in the upcoming Oracle9i DB R2, we will support loading a client-side jars of oc4j (oc4jclient.jar) in the database and call-out EJBs in 9iAS
Please look at this thread Re: Compile procedures for a detailed dicussion on this topic.
regards
Debu Panda
Oracle

Mapping runs through Deployment Manager but hangs in Process Flow

Hi,
I have a Mapping bound in a simple Process Flow.
The mapping deploys through Deployment Manager and runs. It currently processes no rows and takes a couple of seconds to do that. It completes with a Success message.
However, when I wrap it into a simple Process Flow...
--- w ---> END_WARNING
START ---> MY_MAPPING ---- s ---> END_SUCCESS
--- e ---> END_ERROR
.., deploy this and run it through the Deployment Manager, it hangs. I get the 'Execution in progress...' window with the moving graphic forever.
The Runtime Repository Browser Execution Report tells me that it is 'Busy', and if I drill down to the Process Flow Run Execution Report, I see an identical Start and End Time, an Elapsed Time of 0 seconds, and no other details (Execution Parameters, Activity Details or Error Messages).
Looking under 'Find Processes' on the Workflow Home Page, my workflow has no status in the Process List. Drilling down to the Diagram, I have a green line from the 'Start' element to my Mapping but the Mapping itself has no special colour.
I go back to the Deployment Manager and cancel the job - which it does and reports that it 'Completed with errors'.
The Runtime Repository Browser Execution Report now tells me that it is 'Busy' (with an information bubble), and if I drill down to the Process Flow Run Execution Report, I see different Start and End Times, and Elapsed Time of n seconds, a single Error Message 'RPE-01002: The operation was aborted at user request.', and no other details (Execution Parameters, Activity Details).
Looking under 'Find Processes' on the Workflow Home Page, my workflow has a status of 'Complete' in the Process LIst. Drilling down to the Diagram, I still have a green line from the 'Start' element to my Mapping and the Mapping itself still has no colour and no indication that it has stopped.
I'm running:
Oracle9i EE 9.2.0.5.0
Oracle10g OWB Client 10.2.0.1.0
Oracle10g OWB Repository 10.1.0.1.0
Anybody know how I can go about tracking down why this Process Flow is hanging - and, of course, getting it unhung :-)
Regards
Steve

Hello Steve,
It's a little difficult to read the exact flow from your ASCII graphics.
However, from your description it seems your workflow task only has an outgoing success connector, and your execution was not a success. This will stop the execution of that branch of your process flow, since there are no valid routes to take. If you only have a single branch in your workflow, the process flow is stuck.
To expedite your hung process you just click on the task icon in the Workflow Monitor graph window that does not have a green outgoing connector, press the Expedite button and select skip.
Corollary: If you use conditional connectors, always use all 3 from a task. I not using all 3, have a very good understanding of why you don't.
Regards, Hans Henrik

How to kill EPMA Deployment

Hi,
I have EPMA 11.1.1.3 and after making some changes in account and location dimensions i started deploying the app.It was initialed at around 6pm..i informed by client that it usaully takes aroung 6 and half hours to complete the deployment but after 8 hours i checked the Job its still it was going on and it might have hung up at 6%..Main thing all the changes have been reflectd in Hyperion Planning...So my question is how to kill this job running on?
Thanks in advance.
Pranav

So my question is how to kill this job running on?^^^I thought I was going to hear "Nuke it from orbit, it's the only way to be sure" EPMA can be Alien-like.
it usaully takes aroung 6 and half hours to complete the deployment but after 8 hours ^^^Really? That's amazing. I suspect you are forcing a dense restructure this time so that might be part of the issue. Has the Essbase restructure happened yet?
I would be unbelievably suspicious/completely unaccepting of any metadata build that took 6 hours. There has to be a better way.
Regards,
Cameron Lackpour

Deployment hangs - South Central US datacenter

My cloud service has been running for almost a year now. I successfully deployed an update last night. I tried to deploy again today (minor changes) and have been unsuccessful over 5 times now. It just hangs on "starting virtual machine."
My cloud service is hosted at South Central US. According to http://azure.microsoft.com/en-us/status/, a "subset" of users are having problems which I believe includes me. My question is, can we get an update on how long of an outage
we're looking at? My production site is down. Should I be working on moving my cloud service, storage accounts, and sql azure database to another location?

Hi dlee,
Thank you for all the details shared by you on the services which are being hosted. In the South Central US, we are currently experiencing intermittent network issues, and due to this the services might be hung. I have engaged network team and the
team of experts to get this issue resolved and get the services resume now.
I will keep you posted on the progress on this issue. Thank you for your patience. Sincere apologies from us regarding this issue.
Regards,
Lakshmeesha

Deployment hung

Similar Messages

Maybe you are looking for