I don’t feel it would be a big hit in performance because Kafka works very
fast. I think the speed difference would be negligible. Why are you worried
about stability? I’m just curious because it doesn’t seem like it would be
unstable, but maybe it would be a bit overkill for one app and some de
gated table. I.e. say your table
> represents number of view per page, so try to compute number of views
> per page category.
>
> Just like when you use aggregation in SQL using some aggregation
> function, in order for this to make sense you must map several rows in
> the sourc
it using "old keys".
Hope that clears it up.
On Mon, Sep 24, 2018 at 12:03 PM Michael Eugene wrote:
>
> First off thanks or taking the time out of your schedule to respond.
>
> You lost me at almost the beginning, specifically at mapping to a different
> key. If those r
KStream[T] becomes more like
KStream[Change[T]] where change carries both new and old value, and
over the wire this change gets transmitted as two separate kafka
messages.
On Mon, Sep 24, 2018 at 10:56 AM Michael Eugene wrote:
>
> Can someone explain to me the point of the Subtractor in an aggr
Can someone explain to me the point of the Subtractor in an aggregator? I have
to have one, because there is no concrete default implentation of it, but I am
just trying to get a "normal" aggregation working and I don't see why I need a
subtractor. Other than of course I need to make the progr
guity if the compiler can't tell if "scala" references the
top-level package or the intermediate package inside Streams.
Hope this helps!
-John
On Wed, Sep 12, 2018 at 3:02 PM Michael Eugene wrote:
> Hey thanks for the help everyone, I’m gonna use the new scala 2.0
> libraries.
> Hi Michael Eugene,
>
> You're correct - you only need to upgrade your Kafka Streams dependencies
> in your build file. Looking at MVN Repository, the streams lib will
> implicitly bring in its dependency on kafka-clients, but you can always
> include your own expli
older versions of the brokers; you don't need to get
> everyone else to upgrade their clients or your cluster.
>
> Regards
> Sean
>
> On Sun, Sep 9, 2018 at 3:59 PM Michael Eugene wrote:
>
> > I’m integrating with lot of other applications and it would be a little
&
he library is now deprecated
>>> and I remember we ran into some SAM related issues with Scala 2.11 (which
>>> worked fine with 2.12). They were finally fixed in the Kafka distribution -
>>> there are some differences in the APIs as well ..
>>>
>>> regar
; there are some differences in the APIs as well ..
>
> regards.
>
>> On Sun, Sep 9, 2018 at 11:32 PM Michael Eugene wrote:
>>
>> I’m using 2.11.11
>>
>> Sent from my iPhone
>>
>>> On Sep 9, 2018, at 12:13 PM, Debasish Ghosh
>> wrote:
I’m using 2.11.11
Sent from my iPhone
> On Sep 9, 2018, at 12:13 PM, Debasish Ghosh wrote:
>
> Which version of Scala are u using ?
>
>> On Sun, 9 Sep 2018 at 10:44 AM, Michael Eugene wrote:
>>
>> Hi,
>>
>> I am using kafak-sreams-scala
>>
k, v, vr don't match those expected by the
> aggregate() function. Add explicit types to your code and you'll find the
> problem. You'll probably find that Scala is inferring an Any somewhere.
>
> Ryanne
>
>> On Sun, Sep 9, 2018, 12:14 AM Michael Eugene wrote:
>
Hi,
I am using kafak-sreams-scala
https://github.com/lightbend/kafka-streams-scala, and I am trying to implement
something very simple and I am getting a compilation error by the "aggregate"
method. The error is "Cannot resolve overload method 'aggregate'" and
"Unspecified value parameters:
u start the application, it should the config in the logs. Can
> you double check if it did pick up the handler there?
>
> -Matthias
>
>> On 6/24/18 6:42 PM, Michael Eugene wrote:
>> The thing about that is, when I try to register the handler, it doesn’t
>> work.
thought.
>
>
> For exactly-once, producer retries are set to MAX_VALUE and thus the
> application would re-try practically forever.
>
>
> -Matthias
>
>> On 6/16/18 1:52 PM, Michael Eugene wrote:
>> Hi I am trying to understand when to retry sending messages to topic
Hi two questions - Does it make sense to have an error topic for “retryable”
errors if the retries parameter is already set to like 10 (default)?
For non retryable errors, is the approach to try to send to the topic, catch
the specific exception and send to another topic (just send the whole me
Hi I am trying to understand when to retry sending messages to topics and when
to start trying to send to "retry" topics. The scenario is basically
1. A KafkaStreams application is consuming from a topic and sending to a topic.
The "retries" is set at the default of 10.
2a. After 10 retries,
17 matches
Mail list logo
