-
Improvement
-
Resolution: Fixed
-
Major
Currently each attempt to load a class in a remote JVM makes a round-trip request to the master, which over a laggy network can make class loading quite slow, thus adding considerable overhead to the first build on a new slave.
Two possible solutions have been put forward.
Optimistic prefetch
The idea: when sending a class file to be loaded, scan its bytecode for other statically linked classes which have not yet been loaded, and send those along as well. In the common case that a network of classes is loaded around the same time, this would avoid some round trips.
Details
The first part is for one side to keep track of what classes the other side has already loaded (into which class loader), which is basically memorizing the response from IClassLoader.fetch2.
The second part is to add Collection<ClassFile> IClassLoader.fetch3 that works like fetch2, except it will also parse the class, figure out some of the referenced classes that are not yet loaded by the other side, then send them along.
Those prefetched class files would need to be remembered by RemoteClassLoader so that when those are actually requested it can load a class in the right classloader without calling back RemoteClassLoader.proxy. (Assuming there are no side effects, it could also eagerly call RemoteClassLoader.loadClassFile on the prefetched classes.)
The remoting layer supports talking to an earlier version of the remoting layer. We do this by a bitmask in Capability, so this needs one more bit defined there. There is no point in tracking the classes the other side has loaded if the other side will never call fetch3.
Bulk transfer
Send entire JAR files at a time, rather than individual classes; can wind up transferring more than is needed, but the reduction in latency is probably worth it. Since arbitrary class loader graphs might be in use, not just a flat classpath, some custom code needs to be run remotely which will implement the class loader delegation model without hitting the network for each class.
Details
An API sketch:
class Channel { void setClassLoaderTrafficCop(TrafficCop cop); } interface TrafficCop { /** do I know/control/own this classloader? */ boolean controls(ClassLoader cl); Set<JarFile> getJarFilesOf(ClassLoader cl); RemotePartOfTrafficCop getRemotePart(); } class JarFile { String checksum(); InputStream data(); } /** runs in remote agent */ interface RemotePartOfTrafficCop implements Serializable { /** given a class/resource and an originating loader, what is the defining loader? */ RemoteClassLoader trafficControl(RemoteClassLoader origin, String resourceName); }
- is related to
-
JENKINS-18394 IncompatibleClassChangeError after upgrade to 1.519
- Resolved
-
JENKINS-18401 java.lang.NoClassDefFoundError: hudson/maven/MavenReporter
- Resolved
-
JENKINS-18405 Findbugs plugin unable to run on slaves with 1.519
- Resolved
-
JENKINS-18533 Unable to run Maven3 builds due to InvalidClassException
- Resolved
-
JENKINS-16261 Defer JAR copying from MavenComputerListener.preOnline
- Resolved
-
JENKINS-18459 IOException: No Such File
- Resolved
-
JENKINS-18836 java.io.IOException: Unexpected termination of the channel
- Resolved
-
JENKINS-18525 Jenkins 1.520 update breaks Jenkins . Jenkins wont start
- Closed
-
JENKINS-18528 ruby plugins cannot work on Jenkins 1.519+
- Closed