Class BundleFetchConnection

    • Field Detail

      • transport

        private final Transport transport
      • bin

        java.io.InputStream bin
      • prereqs

        final java.util.Map<ObjectId,​java.lang.String> prereqs
      • lockMessage

        private java.lang.String lockMessage
    • Method Detail

      • readSignature

        private int readSignature()
                           throws java.io.IOException
        Throws:
        java.io.IOException
      • readBundleV2

        private void readBundleV2()
                           throws java.io.IOException
        Throws:
        java.io.IOException
      • duplicateAdvertisement

        private PackProtocolException duplicateAdvertisement​(java.lang.String name)
      • readLine

        private java.lang.String readLine​(byte[] hdrbuf)
                                   throws java.io.IOException
        Throws:
        java.io.IOException
      • didFetchTestConnectivity

        public boolean didFetchTestConnectivity()
        Did the last FetchConnection.fetch(ProgressMonitor, Collection, Set) validate graph?

        Some transports walk the object graph on the client side, with the client looking for what objects it is missing and requesting them individually from the remote peer. By virtue of completing the fetch call the client implicitly tested the object connectivity, as every object in the graph was either already local or was requested successfully from the peer. In such transports this method returns true.

        Some transports assume the remote peer knows the Git object graph and is able to supply a fully connected graph to the client (although it may only be transferring the parts the client does not yet have). Its faster to assume such remote peers are well behaved and send the correct response to the client. In such transports this method returns false.

        Returns:
        true if the last fetch had to perform a connectivity check on the client side in order to succeed; false if the last fetch assumed the remote peer supplied a complete graph.
      • setPackLockMessage

        public void setPackLockMessage​(java.lang.String message)
        Set the lock message used when holding a pack out of garbage collection.

        Callers that set a lock message must ensure they call FetchConnection.getPackLocks() after FetchConnection.fetch(ProgressMonitor, Collection, Set), even if an exception was thrown, and release the locks that are held.

        Parameters:
        message - message to use when holding a pack in place.
      • getPackLocks

        public java.util.Collection<PackLock> getPackLocks()
        Returns:
        collection (possibly empty) of locks created by the last call to fetch. The caller must release these after refs are updated in order to safely permit garbage collection.
      • close

        public void close()

        Close any resources used by this connection.

        If the remote repository is contacted by a network socket this method must close that network socket, disconnecting the two peers. If the remote repository is actually local (same system) this method must close any open file handles used to read the "remote" repository.

        If additional messages were produced by the remote peer, these should still be retained in the connection instance for Connection.getMessages().

        AutoClosable.close() declares that it throws Exception. Implementers shouldn't throw checked exceptions. This override narrows the signature to prevent them from doing so.

        Specified by:
        close in interface java.lang.AutoCloseable
        Specified by:
        close in interface Connection
        Specified by:
        close in class BaseConnection