The remote end hung up unexpectedly (git)

One day, git clone from GitHub failed with error messages like below.

remote: Counting objects: 505, done.
remote: Compressing objects: 100% (293/293), done.
fatal: The remote end hung up unexpectedly
fatal: early EOFs: 92% (465/505)
fatal: index-pack failed

In the Internet, there were some suggestions to solve this issue, but none of them worked in my case. So, I set 1 to GIT_TRACE environment variable and tried git clone again.

$ GIT_TRACE=1 git clone ...
....
POST git-upload-pack (386 bytes)
error: RPC failed; result=22, HTTP code = 504
fatal: The remote end hung up unexpectedly

According to the HTTP specification, 504 is returned when "The server was acting as a gateway or proxy and did not receive a timely response from the upstream server." In general, 504 is caused due to slow network. If it was the case in my git clone failure, I thought that either the network between my git client and GitHub or the network between GitHub front-end and back-end might have a trouble. For the latter case, we cannot do anything but wait for GitHub to recover. But, for the former case, there may be some workarounds, so I started to read the source code of git.

In the source code of git, the error message "The remote end hung up unexpectedly" is written only in safe_read() function in pkt-line.c. Reading the source code further made me conclude that the error occurred in git-upload-pack command in my case (as the log message implied).

The man page of git-upload-pack says that the command accepts "--timeout=<seconds>" option and that git-upload-pack is invoked by git-fetch-pack. I thought that passing a long timeout value to git-upload-pack via git-fetch-pack might solve the problem.

The man page of  git-fetch-pack says that git-fetch-pack provides "--upload-pack=<path>" option to specify the path of git-upload-pack command and that if the option is omitted, PATH environment variable is referred to to search for git-upload-pack.

Because I could not find a smart way to pass "--timeout=<seconds>" option to git-upload-pack, I created my own git-upload-pack (shell script) like below,

$ mkdir bin
$ vi bin/git-upload-pack

#!/bin/sh
exec /usr/local/bin/git-upload-pack --timeout=300 "$@"

and ran git clone as follows.

$ PATH="${PWD}/bin:${PATH}" git clone ...

This worked for me! I found a workaround?!

Right after the above successful trial, I tried git clone again without the workaround to check if the workaround had been the key for the success. However, the trial without the workaround also succeeded. Oh, it seemed that GitHub had recovered before I could confirm my workaround... Hmm...

Well, so, my conclusion is that I should simply wait for GitHub to recover when GIT_TRACE=1 git clone reports "HTTP code = 504".

Additional JVM options for maven-javadoc-plugin

I had a trouble. "mvn release:prepare" generated javadoc not in English but in Japanese.

"mvn release:prepare" invokes maven-javadoc-plugin to generate javadoc. In my local environment, javadoc command uses HTML templates for Japanese unless -Duser.language=en option is given. So, I looked for the way to pass the option to javadoc and finally found it.

Additional JVM options can be passed to maven-javadoc-plugin by adding the block shown below to pom.xml.

<project>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-javadoc-plugin</artifactId>
                <configuration>
                    <additionalJOption>-J-Duser.language=en</additionalJOption>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

However, note that, according to maven-javadoc-plugin FAQ, "Where in the pom.xml do I configure the Javadoc Plugin?", places to put configuration for maven-javadoc-plugin at vary depending on your purposes.

Steps to release a maven artifact

# Old title = "mvn release:prepare" stucks in "git push"

1. Build a maven artifact and upload it to Sonatype OSS.
   
   
   $ eval `ssh-agent` Agent pid 6700
   
   $ ssh-add
   Enter passphrase for /c/Users/TakahikoKawasaki/.ssh/id_rsa:
   Identity added: /c/Users/TakahikoKawasaki/.ssh/id_rsa (/c/Users/TakahikoKawasaki/.ssh/id_rsa)
   
   $ mvn clean
   $ mvn release:clean
   $ mvn release:prepare
   $ mvn release:perform


2. Login Sonatype OSS.
   


3. Click "Staging Repositories" on the left menu and then search the list on the right for the uploaded maven artifact 
   


4. Check the uploaded maven artifact and click "Close" button. The status will change to "closed" after a while.


5. Click "Release" button.

---

Maven artifact をリリースする手順
# 旧タイトル = "mvn release:prepare" が "git push" で止まってしまった場合

1. Maven artifact をビルドして Sonatype OSS にアップロードする。
   
   $ eval `ssh-agent`
   Agent pid 6700
   
   $ ssh-add
   Enter passphrase for /c/Users/TakahikoKawasaki/.ssh/id_rsa:
   Identity added: /c/Users/TakahikoKawasaki/.ssh/id_rsa (/c/Users/TakahikoKawasaki/.ssh/id_rsa)
   
   $ mvn clean
   $ mvn release:clean
   $ mvn release:prepare
   $ mvn release:perform


2. Sonatype OSS にログインする。


3. 左メニューの「Staging Repositories」をクリックし、右側のリストからアップロードした Maven artifact を探す。


4. アップロードした Maven artifact にチェックマークをつけて「Close」ボタンをクリックする。しばらくすると Status が closed に変わる。


5. 「Release」ボタンをクリックする。

"MIME media type application/json was not found" (Jersey client)

If your Jersey client reports an error saying "MIME media type application/json was not found", try to enable FEATURE_POJO_MAPPING feature to support mapping between JSON and Java classes. Below is one example to create a Jersey client instance with FEATURE_POJO_MAPPING enabled.

import com.sun.jersey.api.client.Client;
import com.sun.jersey.api.client.config.ClientConfig;
import com.sun.jersey.api.client.config.DefaultClientConfig;
import com.sun.jersey.api.json.JSONConfiguration;

private Client createJerseyClient()
{
    // Configuration of Jersey client.
    ClientConfig config = new DefaultClientConfig();

    // Enable mapping between JSON and Java classes.
    config.getFeatures().put(JSONConfiguration.FEATURE_POJO_MAPPING, true);

    // Create a Client instance.
    return Client.create(config);
}

Note that jersey-json-*.jar is needed. If you are using Maven, add a dependency entry like below.

<dependency>
    <groupId>com.sun.jersey</groupId>
    <artifactId>jersey-json</artifactId>
    <version>1.16</version>
</dependency>