Right, this should should get exposed in JMX for: * Producer * Broker * Consumer
Otis -- Monitoring * Alerting * Anomaly Detection * Centralized Log Management Solr & Elasticsearch Support * http://sematext.com/ On Wed, Nov 12, 2014 at 12:34 PM, Gwen Shapira <gshap...@cloudera.com> wrote: > Actually, Jun suggested exposing this via JMX. > > On Wed, Nov 12, 2014 at 9:31 AM, Gwen Shapira <gshap...@cloudera.com> > wrote: > > > Good question. > > > > The server will need to expose this in the protocol, so Kafka clients > will > > know what they are talking to. > > > > We may also want to expose this in the producer and consumer, so people > > who use Kafka's built-in clients will know which version they have in the > > environment. > > > > > > > > On Wed, Nov 12, 2014 at 9:09 AM, Mark Roberts <wiz...@gmail.com> wrote: > > > >> Just to be clear: this is going to be exposed via some Api the clients > >> can call at startup? > >> > >> > >> > On Nov 12, 2014, at 08:59, Guozhang Wang <wangg...@gmail.com> wrote: > >> > > >> > Sounds great, +1 on this. > >> > > >> >> On Tue, Nov 11, 2014 at 1:36 PM, Gwen Shapira <gshap...@cloudera.com > > > >> wrote: > >> >> > >> >> So it looks like we can use Gradle to add properties to manifest file > >> and > >> >> then use getResourceAsStream to read the file and parse it. > >> >> > >> >> The Gradle part would be something like: > >> >> jar.manifest { > >> >> attributes('Implementation-Title': project.name, > >> >> 'Implementation-Version': project.version, > >> >> 'Built-By': System.getProperty('user.name'), > >> >> 'Built-JDK': System.getProperty('java.version'), > >> >> 'Built-Host': getHostname(), > >> >> 'Source-Compatibility': project.sourceCompatibility, > >> >> 'Target-Compatibility': project.targetCompatibility > >> >> ) > >> >> } > >> >> > >> >> The code part would be: > >> >> > >> >> > >> > this.getClass().getClassLoader().getResourceAsStream("/META-INF/MANIFEST.MF") > >> >> > >> >> Does that look like the right approach? > >> >> > >> >> Gwen > >> >> > >> >> On Tue, Nov 11, 2014 at 10:43 AM, Bhavesh Mistry < > >> >> mistry.p.bhav...@gmail.com > >> >>> wrote: > >> >> > >> >>> If is maven artifact then you will get following pre-build property > >> file > >> >>> from maven build called pom.properties under > >> >>> /META-INF/maven/groupid/artifactId/pom.properties folder. > >> >>> > >> >>> Here is sample: > >> >>> #Generated by Maven > >> >>> #Mon Oct 10 10:44:31 EDT 2011 > >> >>> version=10.0.1 > >> >>> groupId=com.google.guava > >> >>> artifactId=guava > >> >>> > >> >>> Thanks, > >> >>> > >> >>> Bhavesh > >> >>> > >> >>> On Tue, Nov 11, 2014 at 10:34 AM, Gwen Shapira < > gshap...@cloudera.com > >> > > >> >>> wrote: > >> >>> > >> >>>> In Sqoop we do the following: > >> >>>> > >> >>>> Maven runs a shell script, passing the version as a parameter. > >> >>>> The shell-script generates a small java class, which is then built > >> >> with a > >> >>>> Maven plugin. > >> >>>> Our code references this generated class when we expose > >> "getVersion()". > >> >>>> > >> >>>> Its complex and ugly, so I'm kind of hoping that there's a better > way > >> >> to > >> >>> do > >> >>>> it :) > >> >>>> > >> >>>> Gwen > >> >>>> > >> >>>>> On Tue, Nov 11, 2014 at 9:42 AM, Jun Rao <jun...@gmail.com> > wrote: > >> >>>>> > >> >>>>> Currently, the version number is only stored in our build config > >> >> file, > >> >>>>> gradle.properties. Not sure how we can automatically extract it > and > >> >>>> expose > >> >>>>> it in an mbean. How do other projects do this? > >> >>>>> > >> >>>>> Thanks, > >> >>>>> > >> >>>>> Jun > >> >>>>> > >> >>>>> On Tue, Nov 11, 2014 at 7:05 AM, Otis Gospodnetic < > >> >>>>> otis.gospodne...@gmail.com> wrote: > >> >>>>> > >> >>>>>> Hi Jun, > >> >>>>>> > >> >>>>>> Sounds good. But is the version number stored anywhere from > where > >> >> it > >> >>>>> could > >> >>>>>> be gotten? > >> >>>>>> > >> >>>>>> Thanks, > >> >>>>>> Otis > >> >>>>>> -- > >> >>>>>> Monitoring * Alerting * Anomaly Detection * Centralized Log > >> >>> Management > >> >>>>>> Solr & Elasticsearch Support * http://sematext.com/ > >> >>>>>> > >> >>>>>> > >> >>>>>> On Tue, Nov 11, 2014 at 12:45 AM, Jun Rao <jun...@gmail.com> > >> >> wrote: > >> >>>>>> > >> >>>>>>> Otis, > >> >>>>>>> > >> >>>>>>> We don't have an api for that now. We can probably expose this > >> >> as a > >> >>>> JMX > >> >>>>>> as > >> >>>>>>> part of kafka-1481. > >> >>>>>>> > >> >>>>>>> Thanks, > >> >>>>>>> > >> >>>>>>> Jun > >> >>>>>>> > >> >>>>>>> On Mon, Nov 10, 2014 at 7:17 PM, Otis Gospodnetic < > >> >>>>>>> otis.gospodne...@gmail.com> wrote: > >> >>>>>>> > >> >>>>>>>> Hi, > >> >>>>>>>> > >> >>>>>>>> Is there a way to detect which version of Kafka one is running? > >> >>>>>>>> Is there an API for that, or a constant with this value, or > >> >> maybe > >> >>>> an > >> >>>>>>> MBean > >> >>>>>>>> or some other way to get to this info? > >> >>>>>>>> > >> >>>>>>>> Thanks, > >> >>>>>>>> Otis > >> >>>>>>>> -- > >> >>>>>>>> Monitoring * Alerting * Anomaly Detection * Centralized Log > >> >>>>> Management > >> >>>>>>>> Solr & Elasticsearch Support * http://sematext.com/ > >> > > >> > > >> > > >> > -- > >> > -- Guozhang > >> > > > > >
