You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the issue
Currently, I need to disable caching for a KTable, but the Kafka Streams binder in Spring Cloud Stream does not provide this functionality natively. To address this, I propose adding a CacheEnabled property to allow enabling/disabling caching for KTables, similar to how materialized-as provides control over KTable materialization. For consistency and flexibility, I also suggest adding a LoggingEnabled property to toggle detailed logging, offering the same level of configurability.
These properties would enhance control over KTable behavior, addressing limitations in performance optimization (via caching) and debugging (via logging).
To Reproduce
This is a feature request, so reproduction steps are not applicable. However, the limitation can be observed when attempting to disable caching for a KTable in the current Kafka Streams binder, which lacks a direct configuration option for this.
Version of the framework - currently I use
spring-cloud-stream-binder-kafka-streams: 4.1.3
kafka-streams: 3.7.1
Expected behavior
CacheEnabled:
true: Enables caching for the KTable (default behavior).
false: Disables caching, allowing finer performance tuning.
LoggingEnabled:
true: create changelog topic.
false: not create changelog topic.
These properties would mirror the flexibility provided by existing options like materialized-as, extending it to caching and logging control.
Additional context
Adding these properties would benefit applications requiring fine-grained control over KTable behavior, such as:
Disabling caching to reduce memory usage or latency in specific use cases.
Enabling detailed logging for troubleshooting complex stream processing pipelines.
What are your thoughts on adding these properties to the Kafka Streams binder?
or I really need another way that add stream processor, right now functional is only way to create stream processor.
The text was updated successfully, but these errors were encountered:
Describe the issue
Currently, I need to disable caching for a KTable, but the Kafka Streams binder in Spring Cloud Stream does not provide this functionality natively. To address this, I propose adding a CacheEnabled property to allow enabling/disabling caching for KTables, similar to how materialized-as provides control over KTable materialization. For consistency and flexibility, I also suggest adding a LoggingEnabled property to toggle detailed logging, offering the same level of configurability.
These properties would enhance control over KTable behavior, addressing limitations in performance optimization (via caching) and debugging (via logging).
To Reproduce
This is a feature request, so reproduction steps are not applicable. However, the limitation can be observed when attempting to disable caching for a KTable in the current Kafka Streams binder, which lacks a direct configuration option for this.
Version of the framework - currently I use
spring-cloud-stream-binder-kafka-streams: 4.1.3
kafka-streams: 3.7.1
Expected behavior
CacheEnabled:
true: Enables caching for the KTable (default behavior).
false: Disables caching, allowing finer performance tuning.
LoggingEnabled:
true: create changelog topic.
false: not create changelog topic.
These properties would mirror the flexibility provided by existing options like materialized-as, extending it to caching and logging control.
Additional context
Adding these properties would benefit applications requiring fine-grained control over KTable behavior, such as:
Disabling caching to reduce memory usage or latency in specific use cases.
Enabling detailed logging for troubleshooting complex stream processing pipelines.
What are your thoughts on adding these properties to the Kafka Streams binder?
or I really need another way that add stream processor, right now functional is only way to create stream processor.
The text was updated successfully, but these errors were encountered: