Documents only accessible on port 8080 when rest of the site is using 80

[Brian Scott Schupbach, modificado 11 Anos atrás.]

Hello,

We had an existing intranet setup running with a tomcat front end on port 80. Hundreds of documents were uploaded while the site was setup in this way. Today we switched to have IIS running on port 80 in front of tomcat which now runs on port 8080. The site (including all the images) runs perfectly setup this way. Except that previously uploaded documents produce a 404 error. However, if I try to grab the document using the same URL on port 8080, it downloads. I've re-indexed the documents and it didn't fix the issue. When I upload a new document and download it, it works great. The only issue is documents that were previously uploaded. They are only accessible on port 8080 while the rest of the site runs on 80. How do I fix this? Please help!!

[Hitoshi Ozawa, modificado 11 Anos atrás.]

Are you site binding port 8080 to port 80? By documents are you referring to files in document and media library?

From your description, old documents seems to be in cache. Instead of reindexing, try clearing liferay's cache from Control Panel -> Server Administration and if that doesn't work, try clearing IIS cache.

[Brian Scott Schupbach, modificado 11 Anos atrás.]

I am binding to port 80 and using the Application Request Routing plugin to send all request to 8080. It's odd because images are fine but only the documents have issue. The documents are in the document and media library. I've tried clearing liferay's cache but it changed nothing. Tomorrow I'm going to clear tomcat and IIS cache to see if that works..

thanks

[Brian Scott Schupbach, modificado 11 Anos atrás.]

Clearing the cache of tomcat and IIS did not work...

[Brian Scott Schupbach, modificado 11 Anos atrás.]

Actually now i can't even access the files on port 8080..

[Hitoshi Ozawa, modificado 11 Anos atrás.]

Actually now i can't even access the files on port 8080..

Thought so. All traffic to port 8080 should have been redirected to port 80 so it was funny that port 8080 was still returning.
So, this clears the port 8080 problem.

What's the url on images and documents? There may be some filter blocking the files with some extensions.

[Brian Scott Schupbach, modificado 11 Anos atrás.]

A bunch of weird stuff is going on...It actually looks like a small percentage of documents are working. For the remaining documents that cannot be accessed about half can be accessed by going to port :8080. The other half cannot be accessed whether you use port 8080 or not. The document I linked to on this page cannot be accessed using unless you use port 8080 (if you use port 8080 it will take you to our login screen because you must be authenticated to view it. If you try to access it on port 80 it returns a 404).

[Brian Scott Schupbach, modificado 11 Anos atrás.]

Now I'm hearing that people are logging in and it is showing that they are logged in as a random person in the office (not themselves). It doesn't make sense why all this would be happening by switching the requests to go through IIS rather than tomcat. But that's the only change that was made... Obviously something isn't setup right..but I don't even really know where to start.

I can't reproduce the being signed on as another person error and it seems like it doesn't happen a majority of the time. But its happening enough where a few different people have reported it.

[Brian Scott Schupbach, modificado 11 Anos atrás.]

I've tested a lot more documents and it appears that almost all of the broken ones cannot be accessible unless port 8080 is used. I'm not sure what is going on..

[Brian Scott Schupbach, modificado 11 Anos atrás.]

Alright...I've finally figured it out after going crazy for a day. In IIS the default Maximum Allowed Content Length in bytes is something like 30mb. So, since all the documents are above that size, it was failing. In IIS if you go into click on the site and then "Request Filtering" -> "Edit Feature Settings" you will see an area where you can increase this.

[Hitoshi Ozawa, modificado 11 Anos atrás.]

Wasn't that error in IIS's error log? Logs are the best way to find the problem when something isn't working correctly.