nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

LSCS deployment failing - trying to figure out why

Adam Stoller

Environment[indent]TS/LS/OD 7.2.1 on Linux with WebSphere[/indent]Setup[indent]Using a variant of the PLC workflow
Pre-existing setup: DEV_TS -> D2 (LSCS/LSDS/WebSphere) - working
New setup: DEV_TS -> D3 (LSCS/LSDS/WebSphere) - not working[/indent]Request[indent]I'm trying to figure out what I should be looking for / at in order to determine why the LSCS deployments to D3 are failing - i.e.:

Find more posts tagged with

Comments

nipper

import failures are the HOPI errors in LSCS, it can be one of a bunch of things.

Check the license(LSCS). That is a possibility, do any deployments work to that server ? I have seen this a number of times, but of course 7.2.1 and 7.3.1 are different for LSCS, so not all will be possible.

Get access to the server and start looking for logs (LSCS), normally I would say Idol as well, but that was not in 7.2.1 (I think),

Adam Stoller

import failures are the HOPI errors in LSCS, it can be one of a bunch of things.

Check the license(LSCS). That is a possibility, do any deployments work to that server ? I have seen this a number of times, but of course 7.2.1 and 7.3.1 are different for LSCS, so not all will be possible.

Get access to the server and start looking for logs (LSCS), normally I would say Idol as well, but that was not in 7.2.1 (I think),

Well, I did make use of locate to find log files that changed around the time of my last failed deployment:

% locate .log | xargs /bin/ls -ld | grep "Oct 10" | egrep -v "201[01]" | grep -v " 0 " | cut -c51- | sort

I ran it on both the source and target sides.
(it doesn't seem to be completely up-to-date, maybe it takes a bit of time to update?)

On the source side - in the LiveSiteCSAuth/log/deployment2.log - I do see a message about the failure occurring during the "StandardMetada" deployment - but other than that, no light shed as far as I can see.

nipper

Locate has to have the DB updated (posted on another thread). Get sudo access and run updatedb. That should be run by cron nightly.

Won't work really well on deployment logs since those are named different each time. There should be some logs under the LSCS folder (or websphere) and maybe under the Search folder (if there is one)

Adam Stoller

GOOD NEWS[indent]The initial source of the problem has been determined. For some reason (as yet unknown to me) the port, 15060, was not open for "localhost" on D3 (but was on D2).

In both cases, the port is open for the hostname (e.g.: D2:15060 and D3:15060)[/indent]BAD NEWS[indent]Now I'm back to this strange issue where it fails on D3 with:

2012-10-10 14:07:22,508 DEBUG Request method = GET
2012-10-10 14:07:22,508 DEBUG data=null
2012-10-10 14:07:22,508 DEBUG url=http://D3.CUSTOMER.com:15060/lscs/v1/util-command/pending-context/project///usfliwd0.CUSTOMER.com/default/main/BRANCH/?format=json
2012-10-10 14:07:22,508 INFO  ODHOME =  /usr/Interwoven/OpenDeployNG
2012-10-10 14:07:22,508 DEBUG Start connecting to LSCS runtime server ...
2012-10-10 14:07:22,560 INFO  {"contexts":[]}
2012-10-10 14:07:22,560 INFO  No pending context found.
2012-10-10 14:07:22,561 DEBUG Request method = POST
2012-10-10 14:07:22,561 DEBUG data=manifestURL=FILE%3A%2F%2Flocalhost%2F%2Fusr%2FLSCSRT-Store%2F4914e5e0d630e6dc2a13590e5f2a0f74%2Fmanifest%2Flscs_manifest.xml
2012-10-10 14:07:22,561 DEBUG url=http://D3.CUSTOMER.com:15060/lscs/v1/import/
2012-10-10 14:07:22,561 INFO  ODHOME =  /usr/Interwoven/OpenDeployNG
2012-10-10 14:07:22,561 DEBUG Start connecting to LSCS runtime server ...
2012-10-10 14:07:25,511 ERROR Exception in import delivery adapter execution
java.io.IOException: Server returned HTTP response code: 500 for URL: http://D3.CUSTOMER.com:15060/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)

The thing is, at least when attempting to connect from my client machine - I get the same "error" code as I showed in the original post (incorrectly saying it was from DEV_TS when it was actually from my client machine):

http://D2:15060/lscs/vi/import[html]

Method not supported on this uri: GET /lscs/v1/import

[/html]http://D3:15060/lscs/vi/import[html]

Method not supported on this uri: GET /lscs/v1/import

[/html]

Is it possible that this could be a service / port that would only be accessible internally on the server (i.e. D2 could connect to it on itself, but D3 can't for some reason)?[/indent]

Adam Stoller

We believe the problem is with the LSCS DB setup on the second server (D3)

First - let me verify:[indent]Since we're going to have multiple app servers as part of a fan-out (eventually), each with their own instance of LSCS - am I correct that each instance needs it's own DB Schema / table?

I'm assuming the above because otherwise you'd be trying to write into the same table from two (or more) servers concurrently during the fan-out.

Further I'm assuming that you want to have distinct instances of LSCS, along with LSCSRT-Store, for each app server - so that (a) it doesn't matter which app-server the web-server connects to and (b) if one of the app servers ever goes down you don't lose access to the LSCS information.[/indent]Are those two assumptions accurate / reasonable?

Moving along - presuming that I'm correct in the above, since LSCS already was installed on the server (at least in this case) - where would we find the appropriate configuration file to modify the references to:

(the schema contains the table(s) - right?)As LSCS is running within WebSphere - would this information be somewhere in the /opt/WebSphere/.... path, or is it in the /usr/LiveSitexxx/ path (I can't remember the name of the directory off-hand - I'll be in the office in a couple of hours though)

nipper

Your assumptions are correct.

I think that information would be in lscs-conf.properties

Most of it should show up in the LSCS debug panel as well when you view it.

Adam Stoller

Your assumptions are correct.

I think that information would be in lscs-conf.properties

Most of it should show up in the LSCS debug panel as well when you view it.

Yeah - apparently LSCS was deployed as a war file to D3 and thus has the same properties file as D2 inside the /opt/WebSphere/... directory.
The one in /usr/Interwoven/... actually differs, but it isn't being used (as verified using http://D3:15060/lscs/vi/admin/diags)

We're working on figuring out the best way to maintain distinct configurations for this on each server - and to verify we have the necessary DB/Schemas available for us to use with it...

Rick Poulin

BAD NEWS[indent]Now I'm back to this strange issue where it fails on D3 with:

Back to your HTTP500, that means the import failed and you'll (likely) have actual useful information in lscs.log. The location of that log file depends on the log4j.xml configuration for your webapp instance.

Also, /lscs/v1/import only works on POST, which is why you're getting that "not supported" message on GET requests.

Adam Stoller

Back to your HTTP500, that means the import failed and you'll (likely) have actual useful information in lscs.log. The location of that log file depends on the log4j.xml configuration for your webapp instance.

Also, /lscs/v1/import only works on POST, which is why you're getting that "not supported" message on GET requests.

(in reverse order): Yeah - someone else explained that to me this morning - which kind of made sense to me since, as I said (at some point) - even though I got the same error trying to go to that URL on D2 - deployments to D2 alone worked just fine.

The information turned out to be in several places - one of them with the LiveSiteCSRT/idol/logs/application.log. The other folks involved figured out a way to use a shared library resource to manage having a distinct copy of the lscs-conf.properties file on each server.

Now I can deploy from DEV_TS to D2 or D3.

I'm going to close this thread and begin concentrating (again) on what I initially started out to do - which is deploying from DEV_TS to D2 and D3...