Select Page

Have you ever noticed that every time you retrieve a document that’s not in the local cache of a server like Image Services (IS) it takes almost exactly two minutes to appear?

Coincidence? Unlikely.

Magic? Nah.

The Jedi mind trick? I wish!

It’s actually a default setting that web servers have. Before I get into that, here’s some background.

How Document Retrieval Works

If you open a packet sniffing tool on your network and capture the packets that occur because of an image request, you’ll see something like this:

  1. The client (webserver) asks the server (Image Services) for an image using TCP.
  2. If the server has the file in its local cache it sends the document back and the process is over.
  3. If the server doesn’t have the file in its local cache, it says great I’ll let you know when it’s ready using TCP.
  4. The local cache receives the image from the server.
  5. The server sends a UDP packet (port seems to be entirely random) to the client to let it know the image is ready.
  6. The client sends another request for the image as TCP.
  7. The server sends the image as TCP.

What Goes Wrong?

Where the 120 seconds comes into play is when step five fails. It usually fails because of a firewall rule against UDP packets. When this happens, the client waits for the UDP packet to come back. But the client won’t wait forever – it’s impatient and only waits two minutes (a default setting) to get the document. After the 120 seconds, it starts the process over and it’s likely that the server completed up to step four during the initial request, thus the image is in a local cache, and the second request short circuits at step two and you get your image.

Why Does This Happen?

As I said, the UDP packet cannot make it to the IDM Web Services (IDMWS) server for a variety of reasons, but the most common reason we see is that a firewall rule explicitly blocks it. Here’s where it gets a bit techie: Web servers (like IDMWS) often have a firewall rule that only allows HTTP (e.g. TCP) packets on port 80 to get to the webserver.

You usually set up this rule on the public IP of the webserver or via NAT-ing rules in your firewall (AKA the “front end” of your webserver). When the server tries to respond to the client, the firewall says nope, and since the communication is UDP there’s no guarantee of delivery, and thus the image services server never knows that something went wrong and doesn’t indicate the failure in any log or message.

How Do I Load Document Images Faster?

One option: One thing you can do to load document images faster is to lower the wait from 120 seconds. The 120 made sense in the older days when the doc was on OSAR and it took a while to get that jukebox fired up. Nowadays everyone uses MSAR (or file or database stores) and it’s unlikely it will take that long. There’s an IBM Support article that covers this change. We recommend five to ten seconds.

A risky option: Another thing you can do is open a hole in your firewall that allows the UDP packet to reach the server. WE DO NOT RECOMMEND THIS because opening your firewall is scary and there’s a reason it’s there in the first place! However, a source-to-destination rule for UDP packets (with the source being the IS server and the destination being the webserver) isn’t too bad a hole to open.

The best option: The best choice to resolve this problem and load document images faster involves making a “back-end” IP address available for your web server. In most environments you probably already have a back-end IP set up for remote desk-toping, SMTP, monitoring, etc. that has a less restrictive firewall because requests are coming from the trusted internal network. The solution is to get image services to send the UDP packet in step four to the back-end IP.

This isn’t as easy as it sounds because there are no settings on IS that let you choose how to resolve the IP address of the client. In fact, it took a lot of packet sniffing to realize that the client actually supplies the IP address in step one. So the fix is a trick: Make the IDMWS server resolve itself to the “back-end” IP address that your firewall won’t block UDP packets on.  Add an entry in the client’s host file which puts the resolution high enough in the order that the IS server will send to the back-end IP and your images will appear as soon as possible.

Note: This is an article from our archives about Image Services (AKA Image Manager, Panagon, IS), but it’s a critical problem that Pyramid Solutions sees in many FileNet implementations, so we want to keep it on our new website blog. If you found this article helpful, please share it on social media.