Frequent "Could not load items. Server returned status: 500" error

Issue #286 resolved
Murat Ursavas
created an issue


With updating version from 1.17 Snapshot to 1.22 Production SCM Manager started to give "Could not load items. Server returned status: 500" error very frequently. It was not an issue with the older version.

It occures while browsing the Repo sources via web interface. We don't have any issues with Hg. Cloning, pulling & pushing works perfectly.

Please find the trace logs attached. The files contains just the diff, the logs of the action that causes this error.

Please notice the line in diff 1 file:

09:26:39.382 [qtp758974803-21] DEBUG sonia.scm.repository.api.BrowseCommandBuilder - create browser result for BrowseCommandRequest{path=Technical, revision=null}

and the line in diff 2 file:

09:43:50.104 [qtp758974803-23] DEBUG sonia.scm.repository.api.BrowseCommandBuilder - create browser result for BrowseCommandRequest{path=docs, revision=null}

P.S: I suspect from a pattern which is similar to #195. I have many repo's and I get the error only within the repositories with little "i" character.

Comments (15)

  1. Murat Ursavas reporter
  2. Sebastian Sebastian repo owner
  3. Sebastian Sebastian repo owner

    No, this is not right one. You can see each rest url (or ajax) call of the scm-manager web interface with a tool like Firebug, Live HttpHeaders or Google Chrome Developer Tools. But I've postet the correct urls in my previous post. Please open one of the urls with your browser. However i think the problem comes from the mercurial encoding. Please set the encoding of Config->Repository Types->Mercurial Settings->Encoding to the same encoding as your workstation.

  4. Murat Ursavas reporter

    OK, I got it. Here is the output of the action (from Chrome Developer Tools)

    change directory: Technical 062360a214a09b5a0b13beb52c54cf2f8909d908.js:1931
    add history element repositoryBrowser;b143ed22-7838-46e7-8b94-656dd608875c;null;Technical 062360a214a09b5a0b13beb52c54cf2f8909d908.js:1769
    GET 500 (Input length = 1) 062360a214a09b5a0b13beb52c54cf2f8909d908.js:34
    i 062360a214a09b5a0b13beb52c54cf2f8909d908.js:34
    Ext.lib.Ajax.k.request 062360a214a09b5a0b13beb52c54cf2f8909d908.js:35
    Ext.extend.request 062360a214a09b5a0b13beb52c54cf2f8909d908.js:186
    Ext.extend.doRequest 062360a214a09b5a0b13beb52c54cf2f8909d908.js:873
    Ext.extend.request 062360a214a09b5a0b13beb52c54cf2f8909d908.js:860 062360a214a09b5a0b13beb52c54cf2f8909d908.js:826 062360a214a09b5a0b13beb52c54cf2f8909d908.js:823
    Sonia.repository.RepositoryBrowser.Ext.extend.changeDirectory 062360a214a09b5a0b13beb52c54cf2f8909d908.js:1931
    Sonia.repository.RepositoryBrowser.Ext.extend.onClick 062360a214a09b5a0b13beb52c54cf2f8909d908.js:1929
    h 062360a214a09b5a0b13beb52c54cf2f8909d908.js:203
    store returned statuscode 500 062360a214a09b5a0b13beb52c54cf2f8909d908.js:1816
    error during store load, status: 500 062360a214a09b5a0b13beb52c54cf2f8909d908.js:1816
    handle failure for status code: 500 

    And here is the URL you wanted:
  5. Murat Ursavas reporter

    I've changed the server's OS locale to Turkish (was US/English),

    checked my computers settings (Turkish),

    checked browser page encoding (UTF-8),

    checked repository encoding (set to UTF-8)

    Still no luck.

    I can enter some other folders with little "i" character within the same repository. And sometimes I can not enter which has no "i" in it. But they include files with "İ" or "ı" characters. I still believe, this is an encoding issue.

  6. Sebastian Sebastian repo owner

    Ok, this is an encoding problem. Could you please set the encoding at "Config->Repository Types->Mercurial Settings->Encoding" to ISO-8859-9, restart scm-manager and try again?

  7. Murat Ursavas reporter

    Yep, this chapter explains why I experienced all of these:

    2.3. Windows
    Kernel has several different incompatible 8-bit encoding regimes:
    default encoding used in the GUI
    default encoding used in the filesystem
    default (legacy) encoding used in the console (cmd.exe)
    Kernel has a mix of byte-width and wide character APIs
    Kernel and console environment have basically no support for UTF-8 filename I/O or character display
    Kernel may fold non-ASCII filenames to fit in the current codepage with a one-way best-fit algorithm (ie reported files can't actually be opened!)
    Filesystem uses a highly-obscure Unicode-aware case-folding algorithm by default
    Filenames are generally in Unicode NFC, but this is not enforced and NFD-normalized names are treated as different files
    Many tools attempt to do transcoding of file contents from the local encoding to UTF-16 before passing it off to the filesystem
    UTF-16 text files are occasionally found
    A couple multibyte character encodings like Shift-JIS cause trouble here because they make the "\" byte ambiguous
    Console has limited support for UTF-8 in codepage 65001, but is generally buggy
  8. Log in to comment