This discussion is archived
2 Replies Latest reply: Jun 30, 2009 2:21 PM by 807567 RSS

Status code 500 with local patch server

807567 Newbie
Currently Being Moderated
Occasionally I'll get this error on a patch client from `smpatch download':

The following patches were not downloaded:
121620-04: Request to download update failed. Status code 500 returned. An unexpected error occurred inside the server that prevented it from fulfilling the request.

When this happens, our local patch server records this sort of thing in catalina.out:

16-Jun-2009 5:08:37 PM com.sun.swup.updateserver.PatchsvrServlet processRequest
INFO: User-Agent: SunUC_smpatch/1.0.10 Solaris 10 5/08 s10s_u5wos_10 SPARC Java/1.5.0_18
/usr/lib/cc-ccr/bin/ccr -g cns.patchsvr.patchsource
/usr/lib/cc-ccr/bin/ccr -g cns.patchsvr.patchsource
/usr/lib/cc-ccr/bin/ccr -g cns.patchsvr.patchsource
16-Jun-2009 5:09:41 PM com.sun.swup.updateserver.handler.CachingProxyHandler stream
SEVERE: Broken pipe Broken pipe
at Method)
at org.apache.catalina.connector.ResponseBase.flushBuffer(

Repeated download attempts have the same result. Restarting the local patch server has no
effect either. The patch file does exist on the server. I found eventually that if I remove the file
on the patch server, it will download a new identical copy from Sun's patch server, and that
the download on the client is then successful.

Most of the time the local patch server works correctly. What's causing these occasional problems?
  • 1. Re: Status code 500 with local patch server
    807567 Newbie
    Currently Being Moderated
    Sorry for the late response.

    With the new patch in place do you see the same problem on subsequent requests for the same patch?

    When you restarted the server did you check for old processes that might have been leftover?

    Note that we have been testing an IDR for the patch server, which will hopefully be released soon.
  • 2. Re: Status code 500 with local patch server
    807567 Newbie
    Currently Being Moderated
    Our local patch server actually has a T-patch, T119788-10, applied now. The problem mentioned
    here occurred after application of that patch. It seemed to happen only when many patch clients
    connected to the patch server at the same time, and when they all needed to download a large
    number of patches. This only happens periodically, when a new batch of patches is released.
    It didn't happen in the few weeks after application of the T-patch.

    The behavior is somewhat unpredictable. Once it had happened, it seemed to happen each time
    on the same client, even though the server was idle. Restarting the patch server had no effect,
    but removing the file on the patch server caused it to work again.

    The problem of leftover processes seems to have been solved by the T-patch.