I have two instances of WCS, both on OEL and WLS. One was installed as a Management/Development instance and one installed as Delivery (no sample sites). I followed the steps in the WCS Administrators guide for setting up RealTime publishing;
- created batch and realtime users
- set up the destination system
- edit the "FSII Destination (RealTime)" Destination Definition (get the green button)
- initialized the Destination Database (success)
- clicked the Force Approve Published Assets
- made a small change to a page in FSII, approved the changes and dependencies
- access the Publishing Console for FSII
- select publish desintation, click select destination
- publish button is visible, click
Then, nothing. There's no status in the column, it just sits there forever with no publish log entries (https://dl.dropbox.com/u/878812/webcontent/publishing_status.jpg). When I look at the Source system Log Viewer, there's several hundred of these:
[2012-12-05 12:25:57,442 PST] [ERROR] [.kernel.Default (self-tuning)'] [com.fatwire.logging.cs] Error response from posting url <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Draft//EN">
<TITLE>Error 404--Not Found</TITLE>
<FONT FACE=Helvetica><BR CLEAR=all>
<TABLE border=0 cellspacing=5><TR><TD><BR CLEAR=all>
<FONT FACE="Helvetica" COLOR="black" SIZE="3"><H2>Error 404--Not Found</H2>
<TABLE border=0 width=100% cellpadding=10><TR><TD VALIGN=top WIDTH=100% BGCOLOR=white><FONT FACE="Courier New"><FONT FACE="Helvetica" SIZE="3"><H3>From RFC 2068 <i>Hypertext Transfer Protocol -- HTTP/1.1</i>:</H3>
</FONT><FONT FACE="Helvetica" SIZE="3"><H4>10.4.5 404 Not Found</H4>
</FONT><P><FONT FACE="Courier New">The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.</p><p>If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.</FONT></P>
What am I missing on the Destination system?
Edited by: oMaT on Dec 5, 2012 12:30 PM (screenshot)
Edited by: oMaT on Dec 5, 2012 12:32 PM
Can you post the full source and target sites.log to dropbox, also SSOConfig.xml from target?
Are you able to manually authenticate in the target Admin UI? (http://host:port/cs/Xcelerate/LoginPage.html)
Destination Log: https://dl.dropbox.com/u/878812/webcontent/SitesLog_Destination.zip
Source Log: https://dl.dropbox.com/u/878812/webcontent/SitesLog_Source.zip
Destination SSOConfig: https://dl.dropbox.com/u/878812/webcontent/Target_SSOConfig.xml
Yes, I can log into the target (PROD) via that URL, though its /servlet/ instead of /cs/. Initially it doesn't even show the admin panel but after the destination initialization it does show up.
This suggests the source machine can't reach itself on the batchhost address to initiate the publish (source starts publishing in the background by submitting a batch job to the batchhost, which is simply itself in a non-clustered setup). Can you check value of cs.batchhost in futuretense_xcel.ini? It should have the host:port of the source, and source machine should be able to reach itself on that address.
(Also looks like your cs.eventhost setting is incorrect, same story with this, it's used to fire system events in the background).
As indicated in the Admin Guide doc (p274), I set the xcelerate.batchhost within futuretense_xcel.ini to "localhost:7001" which is "+the host name of the application server that is hosting the source system. The source system is the batch host. If the port number of the web server is anything other than 80, you must also include the port number. For example, myserver:7001.+" I'm running WCS on WLS so that's the location of WLS. I've now tried it with that set to "localhost:7001", "192.168.10.213:7001" and then thinking they meant WCS when they said "application server" I tried "localhost:7003" and "192.168.10.213:7003" - restarting WCS after each change. In all cases the log continued to pop the 404 errors.
You said "+It should have the host:port of the source, and source machine should be able to reach itself on that address.+"
Does that mean it should be pointing to WCS or WLS?
The cs.eventhost value found within the App Server panel of futuretense.ini on the source instance is currently set to "http://192.168.10.213:7003" which is the correct location of the source WCS (without the /cs/).
I appreciate your continued help!
Edited by: oMaT on Dec 6, 2012 8:14 AM (spelling)
After much fiddling I discovered this was caused by exactly what pglehorn said it was: the xcelerate.batchhost.
From the Sites 11g bp1 Administrators Guide:
"+Set this property to the host name of the application server that is hosting the source system. The source system is the batch host. If the port number of the web server is anything other than 80, you must also include the port number. For example, myserver:7001. In a clustered WebCenter Sites environment, only one batch host is supported. The xcelerate.batchhost property must be set on each cluster member to point to the dedicated host.+"
I interpreted "application server" as WebLogic (especially considering they use port 7001 in the example) when in fact they're talking about Sites. The 404 errors were not in response to a publishing attempt OR an attempt by the Destination Definition to ping the Target. The DD page apparently also pings the BatchHost and the 404 when pointed at WLS was what I was seeing.
Big thanks to pglehorn for the help in solving this!
Edited by: oMaT on Dec 7, 2012 7:46 AM