Deploying JavaScript (.js)

I am consistently getting errors when deploying .js files. I edit a .js in my workarea, submit, and then start an area deployment using date different. Although the file is new and should overwrite the old version, it throws an error and fails to deploy the file. Non .js files deploy without issue.

client: DEPLOYING - [Y:\default\main\abc\STAGING] to [C:\IBM HTTP Server\htdocs]
(3) client: Received 'get' request for (.\inc\request_info_menus.js)
client: Sending [.\inc\request_info_menus.js] [reason src-is-older] -- FAILED

If I delete the file and re-deploy, everything goes smoothly. Also, it appears that Windows (my server platform) might be locking these files or something as I cannot delete over the network but delete "locally". Any ideas?

OS: Wiindows 2000
TS: 5.5.2
OD: 5.6

Find more posts tagged with

Comments

Adam Stoller

(1) Check the time settings on both the Base Server and Receiver - including the time-zones. It's possible that your servers are not synchronized with respect to time and thus you *are* deploying an older file when it should be newer.

(2) Look at the verious svrTry* options available for use in the deployment configuration file - these tend to help getting around file locking problems on the Receiver.

(3) If '2' fails - you may need to create DNR scripts to stop (before) / start (after) whatever process is using the JS files that might be keeping it locked. [I think this is more likely with java that javascript, but ...]

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

dharrels

Thanks.

I'm sure that the times are not the problem as I'm deploying to localhost, just copying files from Y: to C:

I'll play with the svrTry options a bit, but would you be able to expand on Interwoven's comments that "These features work in conjunction with Microsoft IIS, and are designed to accommodate times of heavy production server traffic". How do the options work with IIS? I'm not using IIS, using Apache, but nonetheless am curious....

Capture.PNG

Lynchy

Also try checking the timestamp on the existing file before and after trying the deployment. Is it a possibility that when the file is accessed prior to the deployment that the destination file's timestamp is altered?

BfExampleOneTbo.java

dharrels

Nah, the timestamps aren't the problem. OpenDeploy actually gets a request to send the file because "src-is-newer". The failure is that the file can't be overwritten... I think it's locked by some unknown process.

Adam Stoller

You say "Opendeploy actually gets a request to send the file because 'src-is-newer'" but your original post showed it wasn't deployed because 'src-is-older' - which is it?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

composer-tbo2.JPG

composer-tbo1.JPG