How to debug LSCS?

There is a debug panel

http://sxxxxxxxsvr:xxxx/lscs/admin/debugpanel/

but this one is helpful in seeing whether content has been indexed by lscs and available in lscs.

When there is 500 error thrown in the lscs deployment log file, log file shows only a import error. but the log does not have precise information on how the import failed.

Is there any other debug procedure that can be followed to troubleshoot the root cause of the 500 error.

2011-09-23 01:50:12,024 DEBUG url=http://localhost:8080/lscs/v1/import/
2011-09-23 01:50:12,024 INFO ODHOME = /opt/OpenDeployNG
2011-09-23 01:50:12,024 DEBUG Start connecting to LSCS runtime server ...
2011-09-23 01:50:12,900 ERROR Exception in import delivery adapter execution
java.io.IOException: Server returned HTTP response code: 500 for URL: http://localhost:8080/lscs/v1/import/
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1290)
at com.interwoven.wcm.iwrr.deployment.adapter.delivery.LSCSDeliveryAdapterBase.processRequest(LSCSDeliveryAdapterBase.java:309)
at com.interwoven.wcm.iwrr.deployment.adapter.delivery.ImportDeliveryAdapter.deploy(ImportDeliveryAdapter.java:125)
at com.interwoven.deploy.engine.TMicroDeployRx.invokeDeliveryAdapters(TMicroDeployRx.java:3769)
at com.interwoven.deploy.engine.TMicroDeployRx.commit(TMicroDeployRx.java:2487)
at com.interwoven.deploy.engine.TMicroDeployRx.run(TMicroDeployRx.java:1363)
at java.lang.Thread.run(Thread.java:619)

----------------------------
Teamsite 7.1, Solaris

Find more posts tagged with

Comments

nipper

There are a whole lot of possibilities. I have seen this happen many different times.

Does anything get installed in LSCS ? Did you try the OOTB content ? My guess is that it is a DB issue.

Rohan_t1

There is a debug panel

http://sxxxxxxxsvr:xxxx/lscs/admin/debugpanel/

but this one is helpful in seeing whether content has been indexed by lscs and available in lscs.

When there is 500 error thrown in the lscs deployment log file, log file shows only a import error. but the log does not have precise information on how the import failed.

Is there any other debug procedure that can be followed to troubleshoot the root cause of the 500 error.

2011-09-23 01:50:12,024 DEBUG url=http://localhost:8080/lscs/v1/import/
2011-09-23 01:50:12,024 INFO ODHOME = /opt/OpenDeployNG
2011-09-23 01:50:12,024 DEBUG Start connecting to LSCS runtime server ...
2011-09-23 01:50:12,900 ERROR Exception in import delivery adapter execution
java.io.IOException: Server returned HTTP response code: 500 for URL: http://localhost:8080/lscs/v1/import/
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1290)
at com.interwoven.wcm.iwrr.deployment.adapter.delivery.LSCSDeliveryAdapterBase.processRequest(LSCSDeliveryAdapterBase.java:309)
at com.interwoven.wcm.iwrr.deployment.adapter.delivery.ImportDeliveryAdapter.deploy(ImportDeliveryAdapter.java:125)
at com.interwoven.deploy.engine.TMicroDeployRx.invokeDeliveryAdapters(TMicroDeployRx.java:3769)
at com.interwoven.deploy.engine.TMicroDeployRx.commit(TMicroDeployRx.java:2487)
at com.interwoven.deploy.engine.TMicroDeployRx.run(TMicroDeployRx.java:1363)
at java.lang.Thread.run(Thread.java:619)

----------------------------
Teamsite 7.1, Solaris

Well there could be number of reasons you would receive such errors. In my opinion it is always good idea to check AppServer logs for more conclusive information. Ofcourse this should be done after preliminary checks on lscs status, IDOL status and related logs are complete.

Frederik

yes, lscs logs actually in 2 places (go figure). One is to file lscs.log somewhere under LSCS_RUNTIME_HOME/logs . It also logs to stdout of the Servlet Container...

If you don't have log access, check the LSCS status url (would tell you if you aren't licensed, or if trouble with db conn).

Could also be file permission trouble. LSCS needs to delete some files during the import, and if OpenDeploy and LSCS (JVM) are running with diff users ... could need attention how you set those users / groups / file permissions.

cute_guy

yes, lscs logs actually in 2 places (go figure). One is to file lscs.log somewhere under LSCS_RUNTIME_HOME/logs . It also logs to stdout of the Servlet Container...

If you don't have log access, check the LSCS status url (would tell you if you aren't licensed, or if trouble with db conn).

Could also be file permission trouble. LSCS needs to delete some files during the import, and if OpenDeploy and LSCS (JVM) are running with diff users ... could need attention how you set those users / groups / file permissions.

How to find out which user is running Opendeploy and which user is running LSCS?

Should the owner & group of file & folders in livesite store should be same as user & group given in the permission rules of opendeploy configuration file?

nipper

How to find out which user is running Opendeploy and which user is running LSCS?

Should the owner & group of file & folders in livesite store should be same as user & group given in the permission rules of opendeploy configuration file?

IMHO, this is a big problem with the PLC deployment. The LSCS deployment runs as IWUSER, so you need to have that user defined in the OD GUI as an od-user and has permissions to run that deployment. The LSDS deployments are URL based an run as IDK (I don't know). But the user does not need to be known by OD.

Frederik

to clarify, I was talking about OD and LSCS users on the Runtime

(and I was assuming that your runtime is a Unix flavor, where user permissions are more delicate, and I was assuming that possibly your OD Receiver and/or LSCS webapp JVM (tomcat or other) and/or LSCS embedded idol process were running as non-root)

@cute_guy: check your lscs.log before worrying (maybe unnecessarily) about the permissions.

@nipper: yes, we've also complained at length to IWOV for the annoyance that LSCS deployments in PLC run as (*) IWUSER (in fact, the workflow initiator), whereas LSDS deployments in PLC run as the "technical user" defined in a properties file (TeamSite/local/config/lib/content_center/livesite_customer_src/etc/conf/livesite_customer/opendeploy.properties - value is initiated with input that you enter during TS installation for "Deployment user")

Note though that during the TS installation (specifically, the LSCS-Authoring installation, the installer also asks for a "LSCS Deployment user", which gets stored in LiveSiteCSAuth\authoring\etc\deployment\config\deployment-source.properties and is used under some circumstances, e.g. for the command-line LiveSiteCSAuth\authoring\bin\startdeploy.bat and during PLC if you do NOT have a review step - well, IIRC).

We've asked IWOV for a year+ now to make LSCS deployment in PLC work same as LSDS => always use the technical user defined in properties. (To me this is obvious, they call it a feature enhancement, or say that PLC is a demo...) They've pointed us in the right direction to set up a Custom Deployment bean that can force this, but we (well, management atm) are not satisfied to roll this out outside the proof-of-concept, because the bean replicates too much of the java code involved in the OOTB bean, making it risky that the bean will need attention / may break at every product upgrade (already the case when moving 7.2.0 to 7.2.1)

(*) = in terms of authentication towards OpenDeploy