On Thu, Sep 20, 2018 at 07:42:10PM -0000, john.calc...@gmail.com wrote: > On 2018/09/16 05:19:15, john.calc...@gmail.com <john.calc...@gmail.com> > wrote: > > Hi Andrew, > > > > I know it's not your business to support HCP, but I'm hoping you've seen > > this sort of thing in the past and know of a possible fix/work-around for > > it. I've got a little test program that connects to an HGST HCP cloud > > server and sends a single file - no matter what settings I use, I get back > > a 500 internal server error (with no error details, of course). The > > configuration is an SSL connection using https and port 443. I had > > handshake fatal alerts from the server when I ran it on windows, but moving > > my program to a RedHat 7.3 system got me past the SSL connection issues. > > Now I just see that 500 internal server error when trying to putBlob. Note > > that I do a removeBlob first, and that succeeds (though it's likely the > > blob is not there). I've also tried several different content forms, > > including stream, string, byte array, etc. > > > > Do you know of any special configuration that must be used with HCP? > > > > (It might also interest you to know, if you don't already, that HCP returns > > an empty entity on this error, which jclouds attempts to parse as XML with > > a SAX parser. This generates a stack trace in the log. It's incidental, but > > you might want to try to do a little pre-checking of the content before > > attempting to parse it with SAX. Just a thought.) > > > > Thanks in advance, > > John Calcote > > Hammerspace, Inc. > > > Though we're still not sure, we believe these 500 errors are caused either by > disk-full or container-quota-full conditions.
Sorry for the late reply, but I have also heard users complain about 500 errors when overwriting existing blobs. Apparently it can be configured in a write-once manner. Unfortunately I don't have any direct experience with HGST. -- Andrew Gaul http://gaul.org/
