Re: [DISCUSS]PIP-417: Provide ability for Pulsar clients to integrate with third-party schema registry service

I'm sorry for ignoring what I said. There is really no need to consider the admin command processing of the broker side. Thanks, sinan SiNan Liu 于2025年6月26日 周四11:34写道： > Yes. Therefore, when you find that the schema type of the topic is > EXTERNAL, just ignore this admin comma

Re: [DISCUSS]PIP-417: Provide ability for Pulsar clients to integrate with third-party schema registry service

> > On Mon, Jun 23, 2025 at 6:58 PM SiNan Liu wrote: > > > I don't seem to have seen any description of the relevant behaviour of > > admin api. > > > > What should we do when calling pulsar-admin schemas get . > > > > > > Thanks, > > si

Re: [DISCUSS]PIP-417: Provide ability for Pulsar clients to integrate with third-party schema registry service

I don't seem to have seen any description of the relevant behaviour of admin api. What should we do when calling pulsar-admin schemas get . Thanks, sinan PengHui Li 于2025年6月24日 周二05:02写道： > Hi Ran, > > Thanks for adding the compatibility explanation and the new schema type. > The proposal loo

Re: [DISCUSS] PIP-423: Add Support for Cancelling Individual Delayed Messages

I think it's actually okay too. That is to add a new parameter `Map messageIds` to `skipMessages`, with key as `ledgerId` and value as `entryId`. However, `numMessages` is a required parameter, how should this part be designed well? - Set `numMessages` to -1 or 0? And execute the logic of `intern

Re: [DISCUSS] PIP-423: Add Support for Cancelling Individual Delayed Messages

The document has been updated, please review it again. For now, let's not consider adding the "index" to the parameters. Thanks, sinan xiangying meng 于2025年6月10日周二 12:03写道： > Hello, Sinan, > > I hold the opposite view on this matter. There is no need to provide > the index parameter for this

Re: [DISCUSS] PIP-423: Add Support for Cancelling Individual Delayed Messages

When I saw xiangying reply, I also remembered PIP-415. https://github.com/apache/pulsar/pull/24220 At present, admin-api in PIP-423 can actually add a new parameter "index". If the user does not set ledgerId and entryId, he can also set "index". Thanks, sinan SiNan Liu 于

Re: [DISCUSS] PIP-423: Add Support for Cancelling Individual Delayed Messages

ent out to consumers for delivery and whether the message was already > acknowledged. > > > > It would be great to have some comments from other community members as > well. > > > > -Lari > > > > On 2025/06/08 05:47:27 SiNan Liu wrote: > > > T

Re: [DISCUSS] PIP-423: Add Support for Cancelling Individual Delayed Messages

ng delayed messages. The operation could possibly > provide some best efforts based response whether this message has already > been sent out to consumers for delivery and whether the message was already > acknowledged. > > It would be great to have some comments from other community m

Re: [DISCUSS] PIP-423: Add Support for Cancelling Individual Delayed Messages

for the various settings > in Pulsar 4.1, for example, it would be useful to enable compression > by default. > > -Lari > > On Fri, 6 Jun 2025 at 05:00, SiNan Liu wrote: > > > > Yes, I'm also re-evaluating the current implementation. > > > > I believe th

Re: [DISCUSS] PIP-423: Add Support for Cancelling Individual Delayed Messages

ssage, but I don't see a reason why that couldn't be introduced. > > Any thoughts about this? > > -Lari > > On 2025/06/01 13:16:43 SiNan Liu wrote: > > Hi all > > > > I want to start a discussion on > > PIP-423: Add Support for Cancelling Indivi

Re: New PMC member: Xiangying Meng

Congratulations! lushiji(apache) 于2025年6月4日周三 20:04写道： > wow,Congratulations > > On Wed, Jun 4, 2025 at 8:03 PM Lari Hotari wrote: > > > The Project Management Committee (PMC) for Apache Pulsar > > is delighted to announce that Xiangying Meng has joined the PMC! > > > > Xiangying Meng has been

Re: [DISCUSS]PIP-417: Provide ability for Pulsar clients to integrate with third-party schema registry service

+1, +1 The load balancing has a good migration guide ( https://pulsar.apache.org/docs/4.0.x/concepts-broker-load-balancing-migration/ ) There are two scenarios we need to consider and handle: 1. How to migrate topics that are already using Pulsar's built-in schema to an external one. This scena

[DISCUSS] PIP-423: Add Support for Cancelling Individual Delayed Messages

Hi all I want to start a discussion on PIP-423: Add Support for Cancelling Individual Delayed Messages Proposal link: https://github.com/apache/pulsar/pull/24370 I'm looking forward to hearing from you. Thanks, sinan

[DISCUSS] PIP-405: Enhanced Dynamic Handling of Selective Consumers in MultiTopicConsumers

*Hi all, I open PIP-405 to enhanced dynamic handling of selective consumers in MultiTopicConsumers.* https://github.com/apache/pulsar/pull/23895/files *In Pulsar, consumers can subscribe to multiple topics by pattern or by passing a list of topics.However, currently, if you need to mo

Re: [DISCUSS] Enhance dynamic topic subscription management in PatternMultiTopicsConsumer

we are thinking far ahead about the solution, it's also good to > continue learning more about the problem space so that we could eventually > decide whether this is functionality that we would be willing to support in > the Pulsar Java client API in the future. > > -Lari >

Re: [DISCUSS] Enhance dynamic topic subscription management in PatternMultiTopicsConsumer

lem and evaluate potential solutions. > Looking forward to learning more about your use case and collaborating on > finding the right approach. > > -Lari > > On 2025/01/03 13:53:28 SiNan Liu wrote: > > Hi, Pulsar Community. > > > > I added a new PR that aims to

[DISCUSS] Enhance dynamic topic subscription management in PatternMultiTopicsConsumer

Hi, Pulsar Community. I added a new PR that aims to enhance our management of topic subscriptions within PatternMultiTopicsConsumer in Pulsar client. This PR introduces the ability to dynamically add or remove topics from a regex pattern subscription, which can significantly improve our system’s r

Re: [PR] PCIP-1: Distributed RPC framework implemented by the Pulsar client [pulsar-java-contrib]

I think PCIP is needed for important features. If it is relatively small and simple to extend the plugin, only need to supplement the documentation. Personal projects require a `README.md` file to introduce the project. PCIP is the same. Thanks, sinan Dave Fisher 于2024年10月18日周五 21:51写道： > My

Re: [DISCUSS] Revert the PR 23395, which broke the behavior of schemas

org/thread/zbkpypb1yw89op510f7zg7cdkns1om0q At the beginning of this discussion, I made some summary, which is directly quoted here. SiNan Liu > 2024年4月16日 21:51 > 发送至 dev > #17221 describes an environment when multiple bookie copies are corrupted, > or a Ledger has been deleted. The loss of schema

Re: [VOTE] PIP-367 Propose a Contributor Repository for Pulsar

epository. Of course, this may involve some code changes to avoid > unnecessary coupling with the Pulsar main repository code. > > Thanks, > Xiangying > > On Mon, Aug 19, 2024 at 4:31 PM SiNan Liu wrote: > > > > Sorry, I would like to know more about it. > > PIP-371

Re: [VOTE] PIP-367 Propose a Contributor Repository for Pulsar

Sorry, I would like to know more about it. PIP-371(https://github.com/apache/pulsar/pull/23194) Can this be contributed to this repo? I think the repo is just a plug-in implementation of the interface? Thanks, sinan xiangying meng 于2024年8月19日 周一16:09写道： > Thanks, everyone. > > Close this vote

Re: [DISCUSS] PIP-371 Support for request-reply model that implements RPC calls

R can also help to close it. Thank you. I will continue to contribute to Pulsar. And, I hope the Pulsar community will get better and better. Thank you. 😁 Thanks, sinan Lari Hotari 于2024年8月19日 周一13:33写道： > On 2024/08/18 13:16:39 SiNan Liu wrote: > > Although at present, there is n

Re: [DISCUSS] PIP-371 Support for request-reply model that implements RPC calls

if you have the usage scenario of this function. Can help with internal testing. This is just a simple implementation, there are many exception handling or the metrics is not perfect. You are still welcome to discuss your questions on the mailing list or pr. Thanks, sinan SiNan Liu 于2024年8月9日

Re: [DISCUSS] PIP-371 Support for request-reply model that implements RPC calls

oposal, it can be discussed. Thanks, sinan Lari Hotari 于2024年8月9日 周五13:28写道： > On 2024/08/09 01:10:11 SiNan Liu wrote: > > Thank you for your comments. > > > > I took a look at this. There are a few questions. > > > > 1. Compared with my proposal to directly

Re: [DISCUSS] PIP-371 Support for request-reply model that implements RPC calls

> irreversible. > > Finally, perhaps we should collect user needs and confirm whether > there are really many companies that need to use pulsar for RPC. > Otherwise, we should not carry out this work. > > BR, > aurora > > SiNan Liu 于2024年8月9日周五 09:10写道： > > >

Re: [DISCUSS] PIP-371 Support for request-reply model that implements RPC calls

a > plugin or an add-on if we were to make it available in the Apache Pulsar > project. I'll be happy to support this type of design. > > -Lari > > > On 2024/08/08 15:09:17 SiNan Liu wrote: > > Hi all. > > > > I drafted a proposal to support for reques

[DISCUSS] PIP-371 Support for request-reply model that implements RPC calls

Hi all. I drafted a proposal to support for request-reply model that implements RPC calls in pulsar. https://github.com/apache/pulsar/pull/23143 I'm looking forward to hearing from you. Thanks, sinan

Re: [DISCUSS] Solution after missing schema

a if it doesn't exist because the top level module can't decide that. > > Thanks, > Rajan > > On Tue, Apr 16, 2024 at 6:47 PM SiNan Liu wrote: > > > The two solutions are conflicting. > > > > If the schema is lost and the automatic skip is selected (and t

Re: [VOTE] PIP-327 Support force topic loading for unrecoverable errors

Please go here first to discuss the solution after the schema is lost. We have some conflicts on the solution. (It is only related to the schema part of this PIP) https://lists.apache.org/thread/zbkpypb1yw89op510f7zg7cdkns1om0q Thanks, sinan Apurva Telang 于2024年4月17日 周三02:43写道： > +1 (non-bind

Re: [DISCUSS] Solution after missing schema

nistrators > to control forceful recovery of the topics in case the cluster is facing > corruption for schema topics. > > Thanks, > Rajan > > > On Tue, Apr 16, 2024 at 6:52 AM SiNan Liu wrote: > > > #17221 <https://github.com/apache/pulsar/issues/17221> describes

[DISCUSS] Solution after missing schema

#17221 describes an environment when multiple bookie copies are corrupted, or a Ledger has been deleted. The loss of schema ledger results in new producers and consumers not even being created and working properly. At present, if the integrity of the

Re: [DISCUSS] PIP-327 Support force topic loading for unrecoverable errors

I just left a comment in your PR about the part of the *schema*. PTAL! Thanks, sinan Rajan Dhabalia 于2023年12月21日周四 01:19写道： > > I don't see the topic load issues. The topic loading works fine, and > the producer works fine. But the proposal said it would resolve the topic > load issue, ca

Re: [DISCUSS] Consistent code style (esp. ws/indent) and autotools

Consistent code style is crucial for a large project. In order to make Pulsar better, I believe we shouldn't be afraid of "risks". By introducing Spotless, we can permanently resolve the issue of inconsistent code style and ensure that all contributors adhere to this rule moving forward. If we don'

Re: [ANNOUNCE] Zili Chen (tison) as new PMC member in Apache Pulsar

Congratulations Thanks, sinan Yu 于2023年7月22日周六 11:53写道： > Congrats! > > On Sat, Jul 22, 2023 at 9:53 AM ZhangJian He wrote: > > > Congratulations > > > > Thanks > > ZhangJian He > > > > > > On Sat, 22 Jul 2023 at 01:19, Lari Hotari wrote: > > > > > Congratulations, Tison! > > > > > > -Lari >

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

Hi, all. Are there any other additions and modifications to this PIP? Thanks, sinan SiNan Liu 于2023年3月26日周日 14:25写道： > *Hi, Asaf! This week I in the research about `SchemaRegistryServiceImpl` > optimization, sorry to reply later.* > > 1. > >> Well, this is exactly the ar

Re: [DISCUSS] forbid user to upload `BYTES` schema

ray. > > > > > > In flink-connector-pulsar, we only use the schema when the users want > > > to do some evolution check. Otherwise, we will only send messages in > > > BYTES schema. > > > > > > On Tue, Mar 28, 2023 at 10:06 AM SiNan Liu >

Re: [DISCUSS] forbid user to upload `BYTES` schema

s the users > want to bypass the schema check and handle the schema validation by > themselves. > > On Tue, Mar 28, 2023 at 8:58 AM SiNan Liu wrote: > > > > Hi, everyone. > > When a user uploads bytes schema. We can warn the user and skip uploading > > bytes schema.

Re: [DISCUSS] forbid user to upload `BYTES` schema

Hi, everyone. When a user uploads bytes schema. We can warn the user and skip uploading bytes schema. Also check to see if the topic has a schema other than bytes. 1. If yes, warn the user that it is not necessary to upload bytes schema. You can subscribe to a topic using bytes schema. 2. If there

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

t; > > > > So what do you wish to state with this quote? Oh, rule 7 has been retained. Let's ignore this. *I also took into account that proto2 was a really problematic version. And the pulsar website seems to say that only proto3 is used.* https://pulsar.apache.org/docs/next/schem

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

ule needs to be added. Thanks, sinan Asaf Mesika 于2023年3月19日周日 19:11写道： > Also: > > (2) PROTOBUF_NATIVE was designed so that not use avro-protobuf for protobuf > > schema compatibility checking. > > The root message name is the class name we pass in when we create the >

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

gt; fully, and the backward compatibility validation code almost does not > exist: It only checks if the root message name is the same between > versions. > > GOALS > The goal of this PIP is to amend PROTOBUF_NATIVE by adding a fully > functional validation for any of the d

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

otobufNativeSchemaCompatabilityCheckV3 makes sense to me. > > > > On Thu, Mar 9, 2023 at 5:49 AM 丛搏 wrote: > > > Hi siNan: > > > > From my point of view, it is just a plug-in. I don't think it is > > necessary to add configuration for the plugin. > > This i

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

better, Rather than in a ProtobufNativeSchemaCompatibilityCheck extension different validator implementation. Sorry I can not use the computer and network in the company, I use my mobile phone to reply to the email, the format may be a bit messy. Please understand. Thanks, sinan SiNan Liu 于 2023年3月8日周三 下午3:

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

use the computer and network in the company, I use my mobile phone to reply to the email, the format may be a bit messy. Please understand. Thanks, sinan 丛搏 于 2023年3月7日周二 下午11:39写道： > SiNan Liu 于2023年3月7日周二 13:22写道： > > > > Great to see your comment, bo! > > > >

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

bed in Implementation 2 and on the pulsar official website.* 6. Why implement each schema-compatibility-check-strategy separately? Isn't it good to find out the commonality of the compatibility checking behavior of multiple policies? Thanks, sinan Asaf Mesika 于2023年3月7日周二 17:45写道： > On Tue,

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

lementation is way too > complicated. > > Why not have a simple function for validation for each switch case above? > > Why do we need strategy and builder, and all this complexity? > > > > > > *Here are the basic compatibility rules we've defined:* > >

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

gt; > > > I dislike this proposal. IMO Avro implementation is way too > complicated. > > Why not have a simple function for validation for each switch case above? > > Why do we need strategy and builder, and all this complexity? > > > > > > *Here are t

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

Asaf Mesika 于2023年3月5日周日 20:21写道： > On Wed, Mar 1, 2023 at 4:33 PM SiNan Liu wrote: > > > > > > > Can you please explain how a Protobuf Schema descriptor can be > validated > > > for backward compatibility check using Avro based compatibility rules? > >

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

previous behaviour ? > I know that adding such flags is a burden but if the upgrade breaks > some workflows then users won't be able to upgrade. > We can add the flag in the next release and drop it in the next major > release > > Enrico > > Il giorno mer 1 mar 2023 alle

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

SchemaBreakCheckUtils.checkSchemaCompatibility(writtenSchema, readSchema); } ``` Thanks, sinan Asaf Mesika 于2023年3月1日周三 21:19写道： > > On Mon, Feb 27, 2023 at 3:47 PM SiNan Liu wrote: > > > > > > > I read it and they look identical. What's the difference bet

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

n. > > I'm saying this since you used "writttenSchema" word but it represents > something completely different if it's backward or forward check. > > Once you'll have that structure like that, I personally will be able to > read and understand it. &g

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

tion - for me , it's all over the place. Can > you please list in order what I wrote above, and list the validation rules > with a good explanation why you validate it like that? > > Lastly, one you have all the validation rules clearly stated, you can use > it to document it pr

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

leave the code to the PRs. > > > On Sun, Feb 19, 2023 at 2:59 PM SiNan Liu wrote: > > > Hi all, > > > > I made a PIP to discuss: https://github.com/apache/pulsar/issues/19565. > > > > We can talk about the current design here. Especially for the field type > > change check rules, please give your valuable advice. > > > > Thanks, > > Sinan > > >

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

13422e6e4fb/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/schema/ProtobufNativeSchemaCompatibilityCheck.java#L31 > > [cid:image002.png@01D94541.991807E0] > > [Text Description automatically generated] > > From: SiNan Liu > Date: Monday, February 20, 2023 at 1:41 PM &g

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

> > It’s discussable. Maybe I’m just missing something. > > I personally wouldn’t rely on such compatibility guarantees in a real > application. > If my check amount (> int32 lol) would be truncated because someone > changed the field type in a schema, I would be quite upset. > &

Re: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

gt; forwards- or backwards-compatibility. > > It leads to JS/PHP-like implicit conversions if I understand it right. > > From: SiNan Liu > Date: Sunday, February 19, 2023 at 1:59 PM > To: dev@pulsar.apache.org > Subject: [DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compat

[DISCUSS] PIP-246: Improved PROTOBUF_NATIVE schema compatibility checks without using avro-protobuf

Hi all, I made a PIP to discuss: https://github.com/apache/pulsar/issues/19565. We can talk about the current design here. Especially for the field type change check rules, please give your valuable advice. Thanks, Sinan

[VOTE] PIP-236: Record schema in the request and carry to the broker when subscribing with AUTO_CONSUME schema.

Hello community, I'm starting the VOTE for PIP-236: Record schema in the request and carry to the broker when subscribing with AUTO_CONSUME schema. PIP link: https://github.com/apache/pulsar/issues/19113 Discuss thread: https://lists.apache.org/thread/v7p88h7grqnbzocw34g6jvxjfw962kfd

Re: [DISCUSS] PIP-236: Upload AUTO_CONSUME SchemaType to Broker

a of the consumer. We just make it absent > > > before > > > > for > > > > AUTO_CONSUME schema. We just thought we could make it absent if the > > > consumer > > > > is using AUTO_CONSUME schema. But apparently, this is a problem for > now. > >

Re: [DISCUSS] PIP-236: Upload AUTO_CONSUME SchemaType to Broker

t; > > > used to pass the used schema of the consumer. We just make it absent > > > before > > > > for > > > > AUTO_CONSUME schema. We just thought we could make it absent if the > > > consumer > > > > is using AUTO_CONSUME schem

Re: [DISCUSS] PIP-236: Upload AUTO_CONSUME SchemaType to Broker

Ok, it's done. Thanks, Sinan Enrico Olivelli 于2023年1月16日周一 22:38写道： > I think that in "Alternatives" you should mention the approach of > adding a boolean (optional) field to the subscribe request > > Enrico > > Il giorno lun 16 gen 2023 alle ore 15:32 S

Re: [DISCUSS] PIP-236: Upload AUTO_CONSUME SchemaType to Broker

> AUTO_CONSUME schema. We just thought we could make it absent if the > > consumer > > > is using AUTO_CONSUME schema. But apparently, this is a problem for > now. > > > > > > I think the easier-to-understand way is for the client to set the >

Re: [DISCUSS] PIP-236: Upload AUTO_CONSUME SchemaType to Broker

ibility issue with uploading the AUTO_CONSUME > schema with > subscribe command, do you see any apparent cons? > > Best, > Penghui > > [1] > > https://github.com/apache/pulsar/blob/master/pulsar-common/src/main/proto/PulsarApi.proto#L241-L266 > > On Fri, Jan 6, 2023

Re: [DISCUSS] PIP-236: Upload AUTO_CONSUME SchemaType to Broker

sar/wiki/PIP-54:-Support-acknowledgment-at-batch-index-level#changes > [2] https://github.com/apache/pulsar/issues/16757 > > On Fri, Jan 6, 2023 at 12:17 AM SiNan Liu wrote: > > > > I just updated the PIP issue and title, you guys can have a look. > issue19113 > > <https:

Re: [DISCUSS] PIP-236: Upload AUTO_CONSUME SchemaType to Broker

; consumer, the schema could be uploaded into the registry and other > clients would be affected. So we should keep not carrying the schema > info in CommandSubscribe for an AUTO_CONSUMER consumer. > > Thanks, > Yunze > > On Thu, Jan 5, 2023 at 11:55 AM SiNan Liu wrote: > >

Re: [DISCUSS] PIP-236: Upload AUTO_CONSUME SchemaType to Broker

eException: Some required fields are > > missing > > at > org.apache.pulsar.common.api.proto.Schema.checkRequiredFields(Schema.java:337) > > at > org.apache.pulsar.common.api.proto.Schema.parseFrom(Schema.java:332) > > at > org.apache.pulsar.commo

Re: [DISCUSS] PIP-236: Upload AUTO_CONSUME SchemaType to Broker

be to > > > > > > > > the topic with AUTO_CONSUME schema, what will happen? > > > > > > > > > > > > > > AUTO_CONSUME schema will not store in > `SchemaRegistryServiceImpl`, it > > > > > > > only represents one

Re: [DISCUSS] PIP-236: Upload AUTO_CONSUME SchemaType to Broker

schema will do any compatibility check > > > > > > Thanks, > > > Bo > > > > > > Yunze Xu 于2023年1月3日周二 10:16写道： > > > > > > > > What I am concerned about is that if the old clients with other > > &

Re: [DISCUSS] PIP-236: Upload AUTO_CONSUME SchemaType to Broker

ty check > > > > > > Thanks, > > > Bo > > > > > > Yunze Xu 于2023年1月3日周二 10:16写道： > > > > > > > > What I am concerned about is that if the old clients with other > > > > schemas (i.e. schema i

Re: [DISCUSS] PIP-236: Upload AUTO_CONSUME SchemaType to Broker

1.Schema.Type and org.apache.pulsar.common.schema.SchemaType value should be the same. 2.These changes do not affect produce and are only affect consumer subscribe behavior. 3.backward compatibility: (1)In org.apache.pulsar.broker.service.ServerCnx#handleSubscribe. if (schema != null && schema.getT