{ "name": "subject", "dataType": "STRING" },

{ "name": "account_type", "dataType": "STRING" },

I'm using DataGrip to explore the linked tables and I noticed the data type for subject is noted as varchar(max) and for account_type it's array(0). What that means is currently I can't filter on account_type inside of the quotes since it's considered an array

Any ideas on why the connector decided one field was a varchar(max) and the other was an array(0)?

What's even more interesting is querying the information schema, the metadat sees both of these as varchar, so it could be a data grip issue.

hi team i try to enable tls-ssl follow this link --> https://docs.pinot.apache.org/operators/tutorials/configuring-tls-ssl i found some issue. 1.after i start server why port 8098 http still running. #tls/ssl pinot.server.tls.keystore.path=/data/apache-pinot/cert/poc-pinot02.server.keystore.jks pinot.server.tls.keystore.password=hellorealtime pinot.server.tls.truststore.path=/data/apache-pinot/cert/poc-pinot02.server.truststore.jks pinot.server.tls.truststore.password=hellorealtime #pinot.server.netty.enabled=true #pinot.server.netty.port=8098 pinot.server.nettytls.enabled=true pinot.server.nettytls.port=8089 pinot.server.adminapi.access.protocols=https #pinot.server.adminapi.access.protocols.http.port=8097 pinot.server.adminapi.access.protocols.https.port=7443 2. after i create table i can not query via webUI error is --> ProcessingException(errorCode:450, messageInternalError java.net.SocketException: Unexpected end of file from server at java.base/sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:866) at java.base/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:689) at java.base/sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:863) at java.base/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:689)) Anyone enable tls-ssl (production) please share me an example config.

Hi All, I'm trying to use Pinot with AWS S3 integration but I got this error message (whole error message will be attached):

2022/04/08 19:30:00.576 ERROR [StartServiceManagerCommand] [main] Failed to start a Pinot [CONTROLLER] at 35.248 since launch
java.lang.RuntimeException: Caught exception while initializing ControllerFilePathProvider
	at org.apache.pinot.controller.BaseControllerStarter.initControllerFilePathProvider(BaseControllerStarter.java:526) ~[pinot-all-0.8.0-jar-with-dependencies.jar:0.8.0-c4ceff06d21fc1c1b88469a8dbae742a4b609808]
	...
Caused by: org.apache.pinot.controller.api.resources.InvalidControllerConfigException: Caught exception while initializing file upload path provider
	at org.apache.pinot.controller.api.resources.ControllerFilePathProvider.<init>(ControllerFilePathProvider.java:107) ~[pinot-all-0.8.0-jar-with-dependencies.jar:0.8.0-c4ceff06d21fc1c1b88469a8dbae742a4b609808]
	... 11 more
Caused by: java.lang.IllegalStateException: PinotFS for scheme: s3 has not been initialized
	at shaded.com.google.common.base.Preconditions.checkState(Preconditions.java:518) ~[pinot-all-0.8.0-jar-with-dependencies.jar:0.8.0-c4ceff06d21fc1c1b88469a8dbae742a4b609808]
	... 11 more

I configured Pinot's Kubernetes as

controller:
      data:
        dir: <s3://mybucket/data/>
      # values under "pinot.controller" at <https://docs.pinot.apache.org/users/tutorials/use-s3-as-deep-store-for-pinot#start-controller>
      storage:
        factory:
          s3:
            region: us-east-1
          class:
            s3: org.apache.pinot.plugin.filesystem.S3PinotFS
      segment:
        fetcher:
          s3:
            class: org.apache.pinot.common.utils.fetcher.PinotFSSegmentFetcher
          protocols: file,http,s3

    server:
      segment:
        fetcher:
          protocols: file,http,s3
          s3:
            class: org.apache.pinot.common.utils.fetcher.PinotFSSegmentFetcher
      instance:
        dataDir: /tmp/pinot-tmp/server/index
        segmentTarDir: /tmp/pinot-tmp/server/segmentTars
      storage:
        factory:
          class:
            s3: org.apache.pinot.plugin.filesystem.S3PinotFS
          s3:
            region: us-east-1

Pinot version is 0.8.0. Do you know where is the issue? Thanks in advance!

Hello!

question: when restarting servers that have been consuming data already, and say that when we restart the server we have to download data from an external deep store, is there any way to know when the server is ready to be queryable? i feel like a check to

health

endpoint wouldn’t suffice or would it. I’m asking cause we are making a change in production and I have notice that we do roll restarts with

kubectl

servers come back but they are trying to catch up the data that they are missing and what not so i’m trying to figure out a way to do this safely

Screenshot 2022-04-12 at 16.59.46.png

I wonder if your job jar has a different version of the guava jar (I assume that’s where InternalFutureFailureAccess is located) than what’s in your HDFS jars. Pinot builds against Hadoop 2.7, and you’ve using 3.1.1 when running the batch ingestion job. I don’t recall if there’s any API compatibility issues between 2.7 and 3.1 HDFS, if not then you could try to use Hadoop 2.7 jars when running the job. (sorry, should have threaded this reply)

getting this error, can anyone help?

image.png

image.png

image.png

Here’s another question. My queries to Pinot tables are failing with either error code 305 (Segment unavailable) or error code 410 (BrokerResourceMissingError). So far, my debugging has uncovered that not all queries are failing => Roughly 50% of the segments are healthy and consuming, whereas the other 50% of the segments are in a bad state. For the segments in a bad state, I’m unable to see any mapping between the Segments and the servers that store the segment data through the UI. I’ve tried deleting and recreating the failing tables as well as to reset/refresh/reload the segment, but none of this seems to work. I’m trying to understand if there’s anything we would have done that could have affected the configurations within the segments. Has anyone encountered this before, and what are some ways to gracefully recover from such issues?

my docker spec

Segment created with only one file