Bug 1085328 - Git: cannot clone repositories from business-central to different machine
Summary: Git: cannot clone repositories from business-central to different machine
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss BRMS Platform 6
Classification: Retired
Component: Business Central
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ER3
: 6.0.2
Assignee: Alexandre Porcelli
QA Contact: Zuzana Krejčová
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-08 11:36 UTC by Zuzana Krejčová
Modified: 2018-12-09 17:43 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-08-06 19:54:26 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Zuzana Krejčová 2014-04-08 11:36:06 UTC
Description of problem:
It is not possible to clone repositories to a different machine, except some very small ones (like a brand new repository).

I have 2 machines, A.B.C.X and A.B.C.Y - the app server with business-central runs on A.B.C.X, I'm trying to clone from A.B.C.Y. 
App server is bound to A.B.C.X host, git and ssh daemons are set to this host as well (using system properties "org.uberfire.nio.git.daemon.host", "org.uberfire.nio.git.ssh.host"  set in standalone.xml), I'm using default ports (9418 for git and 8001 for ssh), connecting to these ports is allowed on the X machine as well.
In business-central, I have a repository "myrepo" with quite a few assets and some history.

I try to clone "myrepo" using 'git clone ssh://testadmin.C.X:8001/myrepo'.
Doing this form the A.B.C.X works. Doing this from the A.B.C.Y machine, the cloning fails due to, probably, some kind of exceeded timeout. Depending on the size of the repository, I get either some 'Packfile truncated' error or 'Corrupted MAC on input. Disconnecting: Packet corrupt .. fatal: early EOF' or some variation on that:

"""
git clone ssh://testadmin.C.X:8001/myrepo
Cloning into 'myrepo'...
Authenticated with partial success.
Password authentication
Password:
remote: Counting objects: 2928, done
remote: Finding sources: 100% (2928/2928)
remote: Getting sizes: 100% (1443/1443)
Corrupted MAC on input.
Disconnecting: Packet corrupt
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
"""

Cloning the same repository via the git protocol works fine so far.


Version-Release number of selected component (if applicable):
BPMS 6.0.1 CR2


Steps to Reproduce:
1. Set up app server with business-central on machine A.B.C.X, with proper host binding, ssh and git daemons host set, (default) ports allowed. Set up user testadmin (role 'admin').
2. Clone a decent-size repository to business-central under the name "myrepo".
3. On machine A.B.C.Y, execute command 'git clone ssh://testadmin.C.X:8001/myrepo'


Actual results:
Cloning fails.


Expected results:
Repository is cloned successfully.

Comment 3 Alexandre Porcelli 2014-04-09 17:13:55 UTC
I coudln't reproduce the issue... 

I've tried the same config here with different repository sizes (from brigh new empty one to 500mb repo like guvnor from github) using all different connection speedies and no luck.

In a rreally slow connection (56K) what I got from client was a clear timout message like:

Received disconnect from 10.211.55.2 2: User session has timed out after being idled for 10000ms.
fatal: The remote end hung up upon initial contact.

Comment 4 Zuzana Krejčová 2014-04-17 14:10:48 UTC
My problem was resolved by bumping up the sshd-core module version to 0.10.0. Product uses 0.9.0. Pertinent information (I think) to be found in issue SSHD-255 (https://issues.apache.org/jira/browse/SSHD-255). 
I'd also recommend using higher version of jgit (3.2.0) - as I understand it, based on issue JENKINS-19043 (https://issues.jenkins-ci.org/browse/JENKINS-19043), there were some performance improvements.

With the product versions of jgit and sshd-core, results were better if GitUploadCommand used compression (requires a small code change and an uberfire module rebuild as well).

Just for the record, rebuilding uberfire modules (6.0.2 ER1 sync) with either or both of these changes requires only to update two lines of imports (and only in case of jgit version switch). Product (6.0.2 ER1 BPMS) deployed with these updated jars, nothing seemed broken (that wasn't broken already).

Comment 5 Alexandre Porcelli 2014-04-24 22:48:24 UTC
Thanks for your hard work on this Zuzana, without it we couldn't improve on this. Here are the changes that you proposed pushed to master and product branches:

(master) https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/commit/b9afd5ceea2
(6.0.x) http://github.com/droolsjbpm/droolsjbpm-build-bootstrap/commit/6b4b31881

(master) http://github.com/uberfire/uberfire/commit/8f96cb036
(0.3.x) http://github.com/uberfire/uberfire/compare/a67cb2f...055f093

Comment 6 Alessandro Lazarotti 2014-05-12 15:26:45 UTC
Upgrade please the version jGit version to 3.3 instead of 3.2 to make sure that al problems related to this issue being solved.

jGit has an issue also related to clone or any other operation over ssh if the repository is bigger than 5 mb - it reports "Short read of block" - this is only solved by 3.3 release:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=426514

We have customers reporting this issue, so please update it to 3.3.1 (latest version) instead of 3.2.


Note You need to log in before you can comment on or make changes to this bug.