Posted: 18 Feb 2016 14:49 EST Last activity: 26 Aug 2020 8:17 EDT
Update 7.2 is getting "SRVE0255E:" Error
I am doing update from 7.1.7 to 7.2. I have run the 2 migrate and 2 update scripts. after that I am deploying new EAR file (prpc_j2ee14_ws.ear file). When I go to browser to log in. I am getting below error:
A WebGroup/Virtual Host to handle /prweb7/PRServlet/bjvNRSE1I9-FTK_4jYEW25SZpLAhAJCOhp6iEx8e-YQ%5B*/!STANDARD has not been defined." error.
I have searched for the error SRVE0255E error online. it says to point to web application to IBM Websphere application server's out-of-the-box "default_host" Virtual Host.Which is suggested by PEGA to use as well.
I am using default_host as virtual host as well but no luck .
Also, can you tell me the serial number associated with the media you used for this? You'd find this in the file name of the update media, I believe it would either be "115007_Pega72-UPD.zip" or "115042_Pega72-UPD.zip."
what is the jndi name for the datasource, this is the problem - should be jdbc/PegaRULES out of the box.
[2/18/16 13:06:51:171 CST] 00000065 PRBootstrapDa E com.pega.pegarules.internal.bootstrap.PRBootstrapDataSource Unable to obtain DataSource for java:comp/env/jdbc/PegaRULES; com.ibm.websphere.naming.CannotInstantiateObjectException: A NameNotFoundException occurred on an indirect lookup on the name java:comp/env/jdbc/PegaRULES. The name java:comp/env/jdbc/PegaRULES maps to a JNDI name in deployment descriptor bindings for the application performing the JNDI lookup. Make sure that the JNDI name mapping in the deployment descriptor binding is correct. If the JNDI name mapping is correct, make sure the target resource can be resolved with the specified name relative to the default initial context. [Root exception is javax.naming.NameNotFoundException: Context: tpega07sand/nodes/tpega07sand-node01/servers/tpega07sand-sysmgmt01, name: jdbc/PegaRULES: First component in name PegaRULES not found. [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]]
It is clear your jndi resources are not bound during the server start, not just jdbc/PegaRULES, I do not even see url/initialization/explicittempdir etc. I would suggest you make sure all nodes are fully synchronized and restart both deployment manager and node agent. Look for stuff similar to these during startup:
[1/28/16 17:08:51:718 EST] 00000001 ResourceMgrIm I WSVR0049I: Binding Pegarulesv719st_CF as eis/jdbc/PegaRULES_CMP
[1/28/16 17:08:51:724 EST] 00000001 ResourceMgrIm I WSVR0049I: Binding Peganone as url/pega/none
[1/28/16 17:08:51:761 EST] 00000001 ResourceMgrIm I WSVR0049I: Binding Pegarulesv719st as jdbc/PegaRULES
[1/28/16 17:08:51:770 EST] 00000001 ResourceMgrIm I WSVR0049I: Binding pegaworkmanager as wm/PegaWorkManager
[1/28/16 17:08:51:779 EST] 00000001 ResourceMgrIm I WSVR0049I: Binding DefaultEJBTimerDataSource as jdbc/DefaultEJBTimerDataSource
[1/28/16 17:08:51:788 EST] 00000001 ResourceMgrIm I WSVR0049I: Binding pegatempdir as url/initialization/explicittempdir
Worked with Premal yesterday and went through all app server configuration. All jndi namespace Issues have been fixed (mainly due to some misconfiguration/deployment). Now all the jndi bindings are correctly identified during server startup. The current issue is due to incorrect rulebase update (e.g., missing pr_engineclasses table). Premal is going to work with his colleague to rerun update and then server should be able to startup.
Posted: 5 years ago
Updated: 5 years ago
Posted: 23 Feb 2016 19:01 EST Updated: 23 Feb 2016 19:57 EST
please attach a complete log file (use attachment not copy/paste) for a clean restart. From the log, you should be able to see the schemas used for both rules and data schema. Also do a query from sql client tool and post the result:
select distinct pzcodesetversion from <rules schema>.pr_engineclasses where pzcodeset = 'pega-enginecode';
Looks like all the right schemas are used except that the query above is not executed. Can you try to use the latest jdbc driver (ojdbc7.jar)? if still not working, create a new SR request assigning to me, we can go through more details tomorrow.
Kevin, for (ojdbc7.jar) I have to check with the DBAs. but is 7.2 is different than 7.1.7, because my all other environments are running ojdbc6.jar and they are working completely fine. I will check with DBA, and if available I will try with that tomorrow.