av9ash/GitBugs huggingface dataset:
Bug: ABFS: Fix failure caused by listFiles() in ITestAbfsRestOperationException
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 10/Jan/22 10:52
Affects Version/s: 3.3.2

testAbfsRestOperationExceptionFormat in ITestAbfsRestOperationException fails due to the wrong exception format of the FileNotFound exception. The test invokes the Filesystem method listFiles(), and the exception thrown is found to be of the GetPathStatus format instead of ListStatus (difference in number of error fields in response).

The Filesystem implementation of listFiles() calls listLocatedStatus(), which then makes a listStatus call. A recent check-in that added implementation for listLocatedStatus() in ABFS driver led to a GetFileStatus request before ListStatus api are invoked, leading to the aberrant FNF exception format. The fix eliminates the GetPathStatus request before ListStatus is called.
Bug: ABFS: Set driver global timeout for ITestAzureBlobFileSystemBasics
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 06/Jan/22 04:05
Affects Version/s: 3.3.1

Unlike all other ABFS driver tests that have a timeout of 15min, ITestAzureBlobFileSystemBasics times out after 30s due to the global timeout inherited from FileSystemContractBaseTest. Setting a 15min timeout for the test will ensure sufficient time to allow retries and avoid transient failures.

Example failure:
testListOnFolderWithNoChildren(org.apache.hadoop.fs.azurebfs.contract.ITestAzureBlobFileSystemBasics)  Time elapsed: 34.655 s  <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 30000 milliseconds
Bug: S3A to support exponential backoff when throttled
Status: Resolved | Priority: Major | Resolution: Not A Problem
Created: 18/Feb/22 21:08

S3 API has limits which we can exceed when using a large number of writers/readers/or listers. We should add randomized-exponential back-off to the s3 client when it encounters:

 

com.amazonaws.services.s3.model.AmazonS3Exception: Please reduce your request rate. (Service: Amazon S3; Status Code: 503; Error Code: SlowDown;
Bug: hadoop-client-runtime latest version 3.3.1 has security issues
Status: Resolved | Priority: Major | Resolution: Not A Problem
Created: 17/Feb/22 19:23

hadoop-client-runtime latest version 3.3.1 ([Maven Repository: org.apache.hadoop » hadoop-client-runtime » 3.3.1 (mvnrepository.com)|https://mvnrepository.com/artifact/org.apache.hadoop/hadoop-client-runtime/3.3.1]) has many security issues.
Beside the ones list in maven repo,  it's dependency:

"org.eclipse.jetty_jetty-io" (9.4.40.v20210413) has [CVE-2021-34429|https://nvd.nist.gov/vuln/detail/CVE-2021-34429] and [CVE-2021-28169|https://nvd.nist.gov/vuln/detail/CVE-2021-28169]

"com.fasterxml.jackson.core_jackson-databind" (2.10.5.1) has [PRISMA-2021-0213.|https://github.com/FasterXML/jackson-databind/issues/3328]



Need to upgrade to higher version.
Bug: AbstractJavaKeyStoreProvider: need a way to read credential store password from Configuration
Status: Resolved | Priority: Major | Resolution: Invalid
Created: 05/Jan/22 15:22

Codepath in focus is [this|https://github.com/apache/hadoop/blob/c3006be516ce7d4f970e24e7407b401318ceec3c/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/alias/AbstractJavaKeyStoreProvider.java#L316]
{code}
      password = ProviderUtils.locatePassword(CREDENTIAL_PASSWORD_ENV_VAR,
          conf.get(CREDENTIAL_PASSWORD_FILE_KEY));
{code}

Since HIVE-14822, we can use custom keystore that Hiveserver2 propagates to jobs/tasks of different execution engines (mr, tez, spark).
We're able to pass any "jceks:" url, but not a password, e.g. on this codepath:
{code}
Caused by: java.security.UnrecoverableKeyException: Password verification failed
	at com.sun.crypto.provider.JceKeyStore.engineLoad(JceKeyStore.java:879) ~[sunjce_provider.jar:1.8.0_232]
	at java.security.KeyStore.load(KeyStore.java:1445) ~[?:1.8.0_232]
	at org.apache.hadoop.security.alias.AbstractJavaKeyStoreProvider.locateKeystore(AbstractJavaKeyStoreProvider.java:326) ~[hadoop-common-3.1.1.7.1.7.0-551.jar:?]
	at org.apache.hadoop.security.alias.AbstractJavaKeyStoreProvider.<init>(AbstractJavaKeyStoreProvider.java:86) ~[hadoop-common-3.1.1.7.1.7.0-551.jar:?]
	at org.apache.hadoop.security.alias.KeyStoreProvider.<init>(KeyStoreProvider.java:49) ~[hadoop-common-3.1.1.7.1.7.0-551.jar:?]
	at org.apache.hadoop.security.alias.JavaKeyStoreProvider.<init>(JavaKeyStoreProvider.java:42) ~[hadoop-common-3.1.1.7.1.7.0-551.jar:?]
	at org.apache.hadoop.security.alias.JavaKeyStoreProvider.<init>(JavaKeyStoreProvider.java:35) ~[hadoop-common-3.1.1.7.1.7.0-551.jar:?]
	at org.apache.hadoop.security.alias.JavaKeyStoreProvider$Factory.createProvider(JavaKeyStoreProvider.java:68) ~[hadoop-common-3.1.1.7.1.7.0-551.jar:?]
	at org.apache.hadoop.security.alias.CredentialProviderFactory.getProviders(CredentialProviderFactory.java:73) ~[hadoop-common-3.1.1.7.1.7.0-551.jar:?]
	at org.apache.hadoop.conf.Configuration.getPasswordFromCredentialProviders(Configuration.java:2409) ~[hadoop-common-3.1.1.7.1.7.0-551.jar:?]
	at org.apache.hadoop.conf.Configuration.getPassword(Configuration.java:2347) ~[hadoop-common-3.1.1.7.1.7.0-551.jar:?]
	at org.apache.hadoop.fs.azurebfs.AbfsConfiguration.getPasswordString(AbfsConfiguration.java:295) ~[hadoop-azure-3.1.1.7.1.7.0-551.jar:?]
	at org.apache.hadoop.fs.azurebfs.AbfsConfiguration.getTokenProvider(AbfsConfiguration.java:525) ~[hadoop-azure-3.1.1.7.1.7.0-551.jar:?]
{code}

Even there is a chance of reading a text file, it's not secure, we need to try reading a Configuration property first and if it's null, we can go to the environment variable.
Hacking the System.getenv() is only possible with reflection, doesn't look so good.
Bug: is there any plan to fix the vulnerabilities in hadoop-common
Status: Open | Priority: Major | Resolution: 
Created: 01/Feb/22 17:10
Affects Version/s: 3.3.1

Hi all, I use a library that is using hadoop-commons as dependency in quite an old version.

anyway I was trying to upgrate it to the latest version and found that still there, there are some problems in hadoop commons.

I can see them even in maven 

[https://mvnrepository.com/artifact/org.apache.hadoop/hadoop-common/3.3.1]

 

[CVE-2022-23305|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23305]
[CVE-2022-23302|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23302]
[CVE-2021-4104|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4104]
[CVE-2021-36374|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-36374]
[CVE-2021-36090|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-36090]
[CVE-2021-35516|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-35516]
[CVE-2021-34429|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-34429]
[CVE-2021-22569|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569]
[CVE-2020-15522|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15522]

 

Anyway I'm definitely not an expert on this but is there plans to fix this vulnerabilities? 

Or is this library not to be used anymore and we need to migrate to something else?

Thanks for any feedback
Bug: Remove org.checkerframework.dataflow from hadoop-shaded-guava artifact (GNU GPLv2 license)
Status: Resolved | Priority: Major | Resolution: Not A Problem
Created: 20/Jan/22 09:09

Please refer to TEZ-4378 for further details:
{code}
 jar tf ./hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-catalog/hadoop-yarn-applications-catalog-webapp/target/app/WEB-INF/lib/hadoop-shaded-guava-1.1.1.jar | grep "dataflow"

org/apache/hadoop/thirdparty/org/checkerframework/dataflow/
org/apache/hadoop/thirdparty/org/checkerframework/dataflow/qual/
org/apache/hadoop/thirdparty/org/checkerframework/dataflow/qual/Deterministic.class
org/apache/hadoop/thirdparty/org/checkerframework/dataflow/qual/Pure$Kind.class
org/apache/hadoop/thirdparty/org/checkerframework/dataflow/qual/Pure.class
org/apache/hadoop/thirdparty/org/checkerframework/dataflow/qual/SideEffectFree.class
org/apache/hadoop/thirdparty/org/checkerframework/dataflow/qual/TerminatesExecution.class
{code}

 I can see that checker-qual LICENSE.txt was removed in the scope of HADOOP-17648, but it has nothing to do with the license itself, only for [resolving a shading error|https://github.com/apache/hadoop-thirdparty/pull/9#issuecomment-822398949]

my understanding is that in the current way an Apache licensed package (guava shaded jar) will contain a GPLv2 licensed software, which makes it a subject of GPLv2, also triggers license violations in security tools (like BlackDuck)
Bug: libhdfspp authentication failed
Status: Open | Priority: Major | Resolution: 
Created: 06/Jan/22 03:51
Affects Version/s: 3.3.0

I build the example lihdfspp client code in [https://github.com/apache/hadoop/blob/rel/release-3.3.0/hadoop-hdfs-project/hadoop-hdfs-native-client/src/main/native/libhdfspp/examples/cc/cat/cat.cc]

 

When running, the following error happened. While I can successfully connect to the same cluster using example code from C API from [https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/LibHdfs.html]

 

[WARN  ][RPC           ][Thu Jan  6 11:47:12 2022][Thread id = 139810402694976][/tmp/orc/build/libhdfspp_ep-prefix/src/libhdfspp_ep/lib/rpc/namenode_tracker.cc:50]    Nameservice declares more than two nodes.  Some won't be used.

[ERROR ][RPC           ][Thu Jan  6 11:47:12 2022][Thread id = 139810357286656][/tmp/orc/build/libhdfspp_ep-prefix/src/libhdfspp_ep/lib/rpc/rpc_engine.cc:191]    RpcEngine::AsyncRpcCommsError called; status="AuthenticationFailed" conn=0x13ab6e0 reqs=1

[WARN  ][RPC           ][Thu Jan  6 11:47:12 2022][Thread id = 139810357286656][/tmp/orc/build/libhdfspp_ep-prefix/src/libhdfspp_ep/lib/rpc/rpc_engine.cc:202]    RpcEngine::RpcCommsError called; status="AuthenticationFailed" conn=0x13ab6e0 reqs=1

[WARN  ][RPC           ][Thu Jan  6 11:47:12 2022][Thread id = 139810357286656][/tmp/orc/build/libhdfspp_ep-prefix/src/libhdfspp_ep/lib/rpc/rpc_connection_impl.h:387]    Network error during RPC read: Bad file descriptor

[ERROR ][RPC           ][Thu Jan  6 11:47:12 2022][Thread id = 139810357286656][/tmp/orc/build/libhdfspp_ep-prefix/src/libhdfspp_ep/lib/rpc/rpc_engine.cc:191]    RpcEngine::AsyncRpcCommsError called; status="Bad file descriptor" conn=0x13ab6e0 reqs=0

[WARN  ][RPC           ][Thu Jan  6 11:47:12 2022][Thread id = 139810357286656][/tmp/orc/build/libhdfspp_ep-prefix/src/libhdfspp_ep/lib/rpc/rpc_engine.cc:202]    RpcEngine::RpcCommsError called; status="Bad file descriptor" conn=0x13ab6e0 reqs=0

Could not connect to jssz-bigdata-proxy-ns1:. AuthenticationFailed
Bug: remove filtering of directory markers in s3a RenameOperation
Status: Open | Priority: Minor | Resolution: 
Created: 03/Feb/22 11:22
Affects Version/s: 3.4.0

S3A RenameOperation tries to filter out renaming intermediate directory markers so as to avoid retaining them when copying from an authoritiative dir to a non-auth one. we did this to support installations where dir marker retention was only enabled for auth dirs

* nobody, AFAIK, does this..it is all or nothing
* all recent hadoop releases, including earlier branches, is now marker aware
* the extras complexity makes debugging rename problems harder.

let's just cut it out.
Bug: S3A connector to improve support for all AWS partitions
Status: Open | Priority: Minor | Resolution: 
Created: 24/Jan/22 16:52
Affects Version/s: 3.3.2

There are some minor issues in using the S3A connector's more advanced features in china

see https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html

Specifically, that "arn:aws:" prefix we use for all arns needs to be configurable so that aws-cn can be used instead.

This means finding where we create and use these in production code (dynamically creating IAM role policies) and in tests, and making it configurable.  

proposed
* add an option {{fs.s3a.aws.partition}}, default aws.
* new StoreContext methods to query this, and create the arn for the current bucket (string concat or from the bucket's ARN if created with an AP ARN)
* docs

I remember ABFS had a problem with oauth endpoints, that was a lot more serious.

Can't think of real tests for this, other than verifying that if you create an invalid partition "aws-mars" some things break.

someone needs to run all our existing tests in china, including those with IAM roles and SSE-KMS.
Bug: s3a prefetching stream to support unbuffer()
Status: In Progress | Priority: Minor | Resolution: 
Created: 28/Mar/22 17:31
Affects Version/s: 3.4.0

Apache Impala uses unbuffer() to free up all client side resources held by a stream, so allowing it to have a map of available (path -> stream) objects, retained across queries.

This saves on having to reopen the files, with the cost of HEAD checks etc. S3AInputStream just closes its http connection. here there is a lot more state to discard, but all memory and file storage must be freed.

until this done, ITestS3AContractUnbuffer must skip when the prefetch stream is used.

its notable that the other tests don't fail, even though the stream doesn't implement the interface; the graceful degradation handles that. it should fail if the test xml resource says the stream does it, but that the stream capabilities say it doesn't.
Bug: Remove unused import AbstractJavaKeyStoreProvider in Shell class
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 01/Jan/22 14:41
Affects Version/s: 3.4.0

In Shell, there are some invalid imports.
For example:
 !image-2022-01-01-22-40-50-604.png! 

Among them, AbstractJavaKeyStoreProvider does not seem to be referenced anywhere.
Bug: Add an option to preserve root directory permissions
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 09/Feb/22 08:22
Affects Version/s: 3.4.0

As mentioned in https://issues.apache.org/jira/browse/HADOOP-15211

 

If *-update* or *-overwrite* is being passed when *distcp* used, the root directory will be skipped in two occasions (CopyListing#doBuildListing & CopyCommitter#preserveFileAttributesForDirectories), which will ignore root directory's attributes.

 

We face the same issue when distcp huge data between clusters and it takes too much effort to update root directories attributes manually.

 

From the earlier ticket it's obvious why this behaviour is there, but sometime we need to enforce root directory update hence I will add a new option for distcp to enable someone (who understands the need of this and know what they are doing) to enforce the update of root directory's attributes (permissions, ownership, ...)

 

It should be simple one, something like this
{code:java}
$ hadoop distcp -p -update -updateRootDirectoryAttributes /a/b/c /a/b/d {code}
This behaviour is optional and will be *false* by default. (it should not affect existing *distcp* users).
Bug: s3a audit logs to publish range start/end of GET requests in audit header
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 28/Mar/22 17:17
Affects Version/s: 3.3.2

we don't get the range of ranged get requests in s3 server logs, because the AWS s3 log doesn't record that information. we can see it's a partial get from the 206 response, but the length of data retrieved is lost.

LoggingAuditor.beforeExecution() would need to recognise a ranged GET and determine the extra key-val pairs for range start and end (rs & re?)

we might need to modify {{HttpReferrerAuditHeader.buildHttpReferrer()}} to take a map of <string, string> so it can dynamically create a header for each request; currently that is not in there.
Bug: S3PrefetchingInputStream to support status probes when closed
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 29/Mar/22 15:58
Affects Version/s: 3.4.0

S3PrefetchingInputStream is a bit over aggressive on raising exceptions/downgrading responses after a stream is closed

* MUST: getPos() to return last read location, or a least 0 (maybe we should add this to filesystem spec)
* MUST: getIOStatistics(). critical for collecting stats in processes
* MUST: seekToNewSource() (it's a no op anyway)
* MAY S3AInputStreamStatistics and getStreamStatistics() though that is only in used in testing...ioStatistics have given us a stable stats api. we may want to tag the method @VisibleForTesting to discourage use.
Bug: Change scope of getRootFallbackLink for InodeTree to make them accessible from outside package
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 24/Mar/22 20:22
Affects Version/s: 2.10.2

Sometimes, we need to access rootFallBackLink in InodeTree from another package. One such case is we extend from ViewFileSystem but want to put the new filesystem in org.apache.hadoop.fs package, instead of org.apache.hadoop.fs.viewfs package. As a result, we need make them public, similar as what we did for getMountPoints() in HADOOP-18100.
Bug: Add debug log when RPC#Reader gets a Call
Status: Reopened | Priority: Minor | Resolution: 
Created: 17/Jan/22 07:58
Affects Version/s: 2.9.2

Now there is an important question. That is, we only know when a Call is actually executed by the Handler. By logging, we cannot know when the Call came in.
If I log some information from the moment the Call enters the inside of the RPC, it will help us to know more about the Call.
The records here should be in the form of logs, and the priority of the logs should not be too high, debug is the best.
Bug: Increase precommit job timeout from 24 hr to 30 hr
Status: Patch Available | Priority: Minor | Resolution: 
Created: 24/Feb/22 07:14

As per some recent precommit build results, full build QA is not getting completed in 24 hr (recent example [here|https://github.com/apache/hadoop/pull/4000] where more than 5 builds timed out after 24 hr). We should increase it to 30 hr.
Bug: The FSDownload verifyAndCopy method doesn't support S3
Status: Resolved | Priority: Minor | Resolution: Invalid
Created: 01/Mar/22 15:50

The modification time comparison in FSDownload's verifyAndCopy method fails for S3, which prohibits distributed cache files being loaded from S3. This change allows S3 to be supported via a config change, that would replace the IO Exception with a warning log entry.
Bug:  move org.apache.hadoop.fs.common package into hadoop-common module
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 28/Mar/22 14:49
Affects Version/s: 3.4.0

move org.apache.hadoop.fs.common package from hadoop-aws, along with any tests, into hadoop-common jar and the+ package org.apache.hadoop.fs.impl

(except for any bits we find are broadly useful in applications to use any new APIs, in which case somewhere more public, such as  o.a.h.util.functional for the futures work)

we can and should pick on new package and move the classes there, even while they are in hadoop-aws. why so? lets us add checkstyle/findbugs rules with the final classnames
Bug: ITestMarkerTool.testRunLimitedLandsatAudit failing due to most of bucket content purged
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 22/Mar/22 13:43
Affects Version/s: 3.3.5

{{ITestMarkerTool.testRunLimitedLandsatAudit}} is failing -a scan which was meant to stop after the first page of results is finishing because there aren't so many objects there.
 
first visible sign of the landsat-pds cleanup

now we have requester pays, we could do this against another store with stability promises, e.g common crawl.

This test failure is fixed in branch-3.3 and trunk: don't worry about the test failing in earlier releases
Bug: S3AFileSystem cannot find a fake dir on minio
Status: Resolved | Priority: Minor | Resolution: Duplicate
Created: 09/Mar/22 04:06
Affects Version/s: 3.2.2

I am using spark and delta lake for reading and writing datasets. After I upgraded the hadoop version, I found that writing files reported an error, indicating that the folder does not exist.

{code:java}
    java.io.FileNotFoundException: No such file or directory: s3a://table_cache/t5ffe773c987844cbba0aafd/_delta_log
        at org.apache.hadoop.fs.s3a.S3AFileSystem.s3GetFileStatus(S3AFileSystem.java:3356)
        at org.apache.hadoop.fs.s3a.S3AFileSystem.innerGetFileStatus(S3AFileSystem.java:3185)
        at org.apache.hadoop.fs.s3a.S3AFileSystem.getFileStatus(S3AFileSystem.java:3053)
        at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1760)
        at org.apache.hadoop.fs.s3a.S3AFileSystem.exists(S3AFileSystem.java:4263)
        at org.apache.spark.sql.delta.storage.S3SingleDriverLogStore.listFromInternal(S3SingleDriverLogStore.scala:120)
        at org.apache.spark.sql.delta.storage.S3SingleDriverLogStore.exists(S3SingleDriverLogStore.scala:156)
        at org.apache.spark.sql.delta.storage.S3SingleDriverLogStore.write(S3SingleDriverLogStore.scala:174)
        at org.apache.spark.sql.delta.OptimisticTransactionImpl.doCommit(OptimisticTransaction.scala:742)
...
{code}
When this folder has been created, the error is still reported.

The related commit is 49f8ae96, It delete some code that dealing with Fake directory.


{code:java}
// Either a normal file was not found or the probe was skipped.
      // because the key ended in "/" or it was not in the set of probes.
      // Look for the dir marker
      if (probes.contains(StatusProbeEnum.DirMarker)) {
        String newKey = maybeAddTrailingSlash(key);
        try {
          ObjectMetadata meta = getObjectMetadata(newKey);

          if (objectRepresentsDirectory(newKey, meta.getContentLength())) {
            LOG.debug("Found file (with /): fake directory");
            return new S3AFileStatus(Tristate.TRUE, path, username);
          } else {
            LOG.warn("Found file (with /): real file? should not happen: {}",
                key);

            return new S3AFileStatus(meta.getContentLength(),
                    dateToLong(meta.getLastModified()),
                    path,
                    getDefaultBlockSize(path),
                    username,
                    meta.getETag(),
                    meta.getVersionId());
          }
        } catch (AmazonServiceException e) {
          if (e.getStatusCode() != SC_404 || isUnknownBucket(e)) {
            throw translateException("getFileStatus", newKey, e);
          }
        } catch (AmazonClientException e) {
          throw translateException("getFileStatus", newKey, e);
        }
      }
    }
{code}
Bug: ViewFileSystem#getUri should return a URI with a empty path component
Status: Open | Priority: Minor | Resolution: 
Created: 10/Feb/22 18:00

The goal here is that the semantics of {{FileSystem#getURI()}} remains the same as before when using ViewFileSystem. 

We should assume that the URI returned by {{FileSystem#getURI()}} doesn't have a Path component (i.e., path component is null). DistributedFileSystem follows this pattern. However, ViewFileSystem add "/" as the path component in the URI returned.
Bug: GCS connector in core-default.xml file missing
Status: Open | Priority: Minor | Resolution: 
Created: 08/Feb/22 11:19
Affects Version/s: 3.2.2

 

{{<property>
    <name>fs.gs.impl</name>
    <value>com.google.cloud.hadoop.fs.gcs.GoogleHadoopFileSystem</value>
    <description>The FileSystem for gs: (GCS) uris.</description>
</property>
<property>
    <name>fs.AbstractFileSystem.gs.impl</name>
    <value>com.google.cloud.hadoop.fs.gcs.GoogleHadoopFS</value>
    <description>
     The AbstractFileSystem for gs: (GCS) uris. Only necessary for use with Hadoop 2.
    </description>
</property>}}

{{}}

{{these config are missing from core-default.xml which is present inside hadoop-common-3.2.2.jar file, which is causing the ssl enabled solr to not communicate with GCS.}}

{{}}

{{By adding these class in the jar file , we will be able to access the gcs directory as the connection between the connector and HDFS will be established.}}

{{}}

{{}}

{{}}