Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
1.1.0
-
None
-
None
-
None
-
RHEL 6.2 64-bit
Description
The following config is invalid, but is not caught by the properties validator (no sinks are specified).
a1.sources = r1
a1.channels = c1
#a1.sinks = k1
a1.sources.r1.type = SEQ
a1.sources.r1.channels = c1
a1.channels.c1.type = MEMORY
#a1.sinks.k1.type = logger
#a1.sinks.k1.channel = c1
If I run with this config, then the source and channel instance is created. If you add a print statement to ChannelProcessor.processEvent(), you'll see that the source is sending events to the channel. The source generates about 104 events, and then generates an additional one about every second... which is interesting, since the mem channel's default capacity is only 100 and there's no sink. When I do a runtime configuration by changing the the props file to this:
#a1.sources = r1
a1.channels = c1
a1.sinks = k1
#a1.sources.r1.type = SEQ
#a1.sources.r1.channels = c1
a1.channels.c1.type = MEMORY
a1.sinks.k1.type = logger
a1.sinks.k1.channel = c1
...then sink instance is created but the SEQ source is not stopped – it continuously sends events at a rapid pace.
I mention this because observing the behavior of even invalid configs might give clues as to problems that might occur with valid configs (such as a source not being stopped upon dynamic reconfig).