[jira] [Updated] (STORM-3075) NPE starting nimbus
[
https://issues.apache.org/jira/browse/STORM-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated STORM-3075:
--
Labels: pull-request-available (was: )
> NPE starting nimbus
> ---
>
> Key: STORM-3075
> URL: https://issues.apache.org/jira/browse/STORM-3075
> Project: Apache Storm
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Aaron Gresch
>Assignee: Aaron Gresch
>Priority: Major
> Labels: pull-request-available
>
> {code:java}
> 2018-05-15 14:14:59.873 o.a.c.f.l.ListenerContainer main-EventThread [ERROR]
> Listener (org.apache.storm.zookeeper.Zookeeper$1@26d820eb) threw an exception
> java.lang.NullPointerException: null
> at
> org.apache.storm.nimbus.LeaderListenerCallback.leaderCallBack(LeaderListenerCallback.java:118)
> ~[storm-server-2.0.0.y.jar:2.0.0.y]
> at
> org.apache.storm.zookeeper.Zookeeper$1.isLeader(Zookeeper.java:124)
> ~[storm-server-2.0.0.y.jar:2.0.0.y]
> at
> org.apache.curator.framework.recipes.leader.LeaderLatch$9.apply(LeaderLatch.java:665)
> ~[curator-recipes-4.0.1.jar:4.0.1]
> at
> org.apache.curator.framework.recipes.leader.LeaderLatch$9.apply(LeaderLatch.java:661)
> ~[curator-recipes-4.0.1.jar:4.0.1]
> at
> org.apache.curator.framework.listen.ListenerContainer$1.run(ListenerContainer.java:93)
> ~[curator-framework-4.0.1.jar:4.0.1]
> at
> org.apache.curator.shaded.com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:435)
> ~[curator-client-4.0.1.jar:?]
> at
> org.apache.curator.framework.listen.ListenerContainer.forEach(ListenerContainer.java:85)
> ~[curator-framework-4.0.1.jar:4.0.1]
> at
> org.apache.curator.framework.recipes.leader.LeaderLatch.setLeadership(LeaderLatch.java:660)
> ~[curator-recipes-4.0.1.jar:4.0.1]
> at
> org.apache.curator.framework.recipes.leader.LeaderLatch.checkLeadership(LeaderLatch.java:539)
> ~[curator-recipes-4.0.1.jar:4.0.1]
> at
> org.apache.curator.framework.recipes.leader.LeaderLatch.access$700(LeaderLatch.java:65)
> ~[curator-recipes-4.0.1.jar:4.0.1]
> at
> org.apache.curator.framework.recipes.leader.LeaderLatch$7.processResult(LeaderLatch.java:590)
> ~[curator-recipes-4.0.1.jar:4.0.1]
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.sendToBackgroundCallback(CuratorFrameworkImpl.java:865)
> ~[curator-framework-4.0.1.jar:4.0.1]
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.processBackgroundOperation(CuratorFrameworkImpl.java:635)
> ~[curator-framework-4.0.1.jar:4.0.1]
> at
> org.apache.curator.framework.imps.WatcherRemovalFacade.processBackgroundOperation(WatcherRemovalFacade.java:152)
> ~[curator-framework-4.0.1.jar:4.0.1]
> at
> org.apache.curator.framework.imps.GetChildrenBuilderImpl$2.processResult(GetChildrenBuilderImpl.java:187)
> ~[curator-framework-4.0.1.jar:4.0.1]
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
> ~[zookeeper-3.4.6.jar:3.4.6-1569965]
> at
> org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> ~[zookeeper-3.4.6.jar:3.4.6-1569965]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (STORM-3075) NPE starting nimbus
Aaron Gresch created STORM-3075:
---
Summary: NPE starting nimbus
Key: STORM-3075
URL: https://issues.apache.org/jira/browse/STORM-3075
Project: Apache Storm
Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Aaron Gresch
Assignee: Aaron Gresch
{code:java}
2018-05-15 14:14:59.873 o.a.c.f.l.ListenerContainer main-EventThread [ERROR]
Listener (org.apache.storm.zookeeper.Zookeeper$1@26d820eb) threw an exception
java.lang.NullPointerException: null
at
org.apache.storm.nimbus.LeaderListenerCallback.leaderCallBack(LeaderListenerCallback.java:118)
~[storm-server-2.0.0.y.jar:2.0.0.y]
at org.apache.storm.zookeeper.Zookeeper$1.isLeader(Zookeeper.java:124)
~[storm-server-2.0.0.y.jar:2.0.0.y]
at
org.apache.curator.framework.recipes.leader.LeaderLatch$9.apply(LeaderLatch.java:665)
~[curator-recipes-4.0.1.jar:4.0.1]
at
org.apache.curator.framework.recipes.leader.LeaderLatch$9.apply(LeaderLatch.java:661)
~[curator-recipes-4.0.1.jar:4.0.1]
at
org.apache.curator.framework.listen.ListenerContainer$1.run(ListenerContainer.java:93)
~[curator-framework-4.0.1.jar:4.0.1]
at
org.apache.curator.shaded.com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:435)
~[curator-client-4.0.1.jar:?]
at
org.apache.curator.framework.listen.ListenerContainer.forEach(ListenerContainer.java:85)
~[curator-framework-4.0.1.jar:4.0.1]
at
org.apache.curator.framework.recipes.leader.LeaderLatch.setLeadership(LeaderLatch.java:660)
~[curator-recipes-4.0.1.jar:4.0.1]
at
org.apache.curator.framework.recipes.leader.LeaderLatch.checkLeadership(LeaderLatch.java:539)
~[curator-recipes-4.0.1.jar:4.0.1]
at
org.apache.curator.framework.recipes.leader.LeaderLatch.access$700(LeaderLatch.java:65)
~[curator-recipes-4.0.1.jar:4.0.1]
at
org.apache.curator.framework.recipes.leader.LeaderLatch$7.processResult(LeaderLatch.java:590)
~[curator-recipes-4.0.1.jar:4.0.1]
at
org.apache.curator.framework.imps.CuratorFrameworkImpl.sendToBackgroundCallback(CuratorFrameworkImpl.java:865)
~[curator-framework-4.0.1.jar:4.0.1]
at
org.apache.curator.framework.imps.CuratorFrameworkImpl.processBackgroundOperation(CuratorFrameworkImpl.java:635)
~[curator-framework-4.0.1.jar:4.0.1]
at
org.apache.curator.framework.imps.WatcherRemovalFacade.processBackgroundOperation(WatcherRemovalFacade.java:152)
~[curator-framework-4.0.1.jar:4.0.1]
at
org.apache.curator.framework.imps.GetChildrenBuilderImpl$2.processResult(GetChildrenBuilderImpl.java:187)
~[curator-framework-4.0.1.jar:4.0.1]
at
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:590)
~[zookeeper-3.4.6.jar:3.4.6-1569965]
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
~[zookeeper-3.4.6.jar:3.4.6-1569965]
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (STORM-3074) Inconsistent null checking in SaslMessageToken
[ https://issues.apache.org/jira/browse/STORM-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stig Rohde Døssing updated STORM-3074: -- Affects Version/s: (was: 1.2.1) (was: 1.0.6) (was: 1.1.2) > Inconsistent null checking in SaslMessageToken > -- > > Key: STORM-3074 > URL: https://issues.apache.org/jira/browse/STORM-3074 > Project: Apache Storm > Issue Type: Bug > Components: storm-client >Affects Versions: 2.0.0 >Reporter: Stig Rohde Døssing >Assignee: Stig Rohde Døssing >Priority: Minor > > The SaslMessageToken class will throw an NPE if buffer() is called and the > payload is null. While the buffer method checks whether the token is null in > a few places before dereferencing, the encodedLength method is called right > off the bat, and it doesn't check for null. > The payload is always generated by either > https://docs.oracle.com/javase/7/docs/api/javax/security/sasl/SaslServer.html#evaluateResponse(byte[]) > or > https://docs.oracle.com/javase/7/docs/api/javax/security/sasl/SaslClient.html#evaluateChallenge(byte[]). > The javadoc indicates that if these return null, authentication has > succeeded and it is unnecessary to send any more messages to the other party. > I think if null SaslMessageToken payloads are never sent over the wire, we > should remove all the null checking in SaslMessageToken and MessageDecoder, > and ensure that the SASL handlers check for null before deciding to write > tokens. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (STORM-3074) Inconsistent null checking in SaslMessageToken
Stig Rohde Døssing created STORM-3074: - Summary: Inconsistent null checking in SaslMessageToken Key: STORM-3074 URL: https://issues.apache.org/jira/browse/STORM-3074 Project: Apache Storm Issue Type: Bug Components: storm-client Affects Versions: 1.2.1, 1.0.6, 1.1.2, 2.0.0 Reporter: Stig Rohde Døssing Assignee: Stig Rohde Døssing The SaslMessageToken class will throw an NPE if buffer() is called and the payload is null. While the buffer method checks whether the token is null in a few places before dereferencing, the encodedLength method is called right off the bat, and it doesn't check for null. The payload is always generated by either https://docs.oracle.com/javase/7/docs/api/javax/security/sasl/SaslServer.html#evaluateResponse(byte[]) or https://docs.oracle.com/javase/7/docs/api/javax/security/sasl/SaslClient.html#evaluateChallenge(byte[]). The javadoc indicates that if these return null, authentication has succeeded and it is unnecessary to send any more messages to the other party. I think if null SaslMessageToken payloads are never sent over the wire, we should remove all the null checking in SaslMessageToken and MessageDecoder, and ensure that the SASL handlers check for null before deciding to write tokens. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (STORM-3055) never refresh connection
[ https://issues.apache.org/jira/browse/STORM-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stig Rohde Døssing reassigned STORM-3055: - Assignee: zhangbiao (was: Stig Rohde Døssing) > never refresh connection > > > Key: STORM-3055 > URL: https://issues.apache.org/jira/browse/STORM-3055 > Project: Apache Storm > Issue Type: Bug > Components: storm-client, storm-core >Affects Versions: 2.0.0, 1.1.1 >Reporter: zhangbiao >Assignee: zhangbiao >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > in our enviroment some worker's connection to other worker being closed and > never reconnect, > the log show's that > 2018-05-02 10:28:49.302 o.a.s.m.n.Client > Thread-90-disruptor-worker-transfer-queue [ERROR] discarding 1 messages > because the Netty client to Netty-Client-/192.168.31.1:6800 is being closed > .. > 2018-05-02 11:00:29.540 o.a.s.m.n.Client > Thread-90-disruptor-worker-transfer-queue [ERROR] discarding 1 messages > because the Netty client to Netty-Client-/192.168.31.1:6800 is being closed > the log shows that it never can reconnect again. i can only fix it after > restart the topo, -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (STORM-3055) never refresh connection
[ https://issues.apache.org/jira/browse/STORM-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stig Rohde Døssing reassigned STORM-3055: - Assignee: Stig Rohde Døssing > never refresh connection > > > Key: STORM-3055 > URL: https://issues.apache.org/jira/browse/STORM-3055 > Project: Apache Storm > Issue Type: Bug > Components: storm-client, storm-core >Affects Versions: 2.0.0, 1.1.1 >Reporter: zhangbiao >Assignee: Stig Rohde Døssing >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > in our enviroment some worker's connection to other worker being closed and > never reconnect, > the log show's that > 2018-05-02 10:28:49.302 o.a.s.m.n.Client > Thread-90-disruptor-worker-transfer-queue [ERROR] discarding 1 messages > because the Netty client to Netty-Client-/192.168.31.1:6800 is being closed > .. > 2018-05-02 11:00:29.540 o.a.s.m.n.Client > Thread-90-disruptor-worker-transfer-queue [ERROR] discarding 1 messages > because the Netty client to Netty-Client-/192.168.31.1:6800 is being closed > the log shows that it never can reconnect again. i can only fix it after > restart the topo, -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (STORM-3072) Frequent test failures in storm-sql-core
[
https://issues.apache.org/jira/browse/STORM-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stig Rohde Døssing resolved STORM-3072.
---
Resolution: Fixed
Fix Version/s: 2.0.0
> Frequent test failures in storm-sql-core
>
>
> Key: STORM-3072
> URL: https://issues.apache.org/jira/browse/STORM-3072
> Project: Apache Storm
> Issue Type: Bug
> Components: storm-sql
>Affects Versions: 2.0.0
>Reporter: Stig Rohde Døssing
>Assignee: Stig Rohde Døssing
>Priority: Major
> Labels: pull-request-available
> Fix For: 2.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Seeing test failures in storm-sql-core, sometimes regular test failures,
> other times JVM crashes.
> {code}
> testExternalUdf(org.apache.storm.sql.TestStormSql) Time elapsed: 8.177 sec
> <<< ERROR!
> java.lang.RuntimeException: java.lang.RuntimeException: not a leader, current
> leader is NimbusInfo{host='DESKTOP-AGC8TKM.localdomain', port=6627,
> isLeader=true}
> at
> org.apache.storm.daemon.nimbus.Nimbus.submitTopologyWithOpts(Nimbus.java:2952)
> at
> org.apache.storm.daemon.nimbus.Nimbus.submitTopology(Nimbus.java:2761)
> at org.apache.storm.LocalCluster.submitTopology(LocalCluster.java:378)
> at
> org.apache.storm.sql.StormSqlLocalClusterImpl.runLocal(StormSqlLocalClusterImpl.java:68)
> at
> org.apache.storm.sql.TestStormSql.testExternalUdf(TestStormSql.java:214)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runners.Suite.runChild(Suite.java:127)
> at org.junit.runners.Suite.runChild(Suite.java:26)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeLazy(JUnitCoreWrapper.java:119)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:87)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:161)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.lang.RuntimeException: not a leader, current leader is
>
[jira] [Updated] (STORM-3073) In some cases workers may crash because pendingEmits is full
[
https://issues.apache.org/jira/browse/STORM-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated STORM-3073:
--
Labels: pull-request-available (was: )
> In some cases workers may crash because pendingEmits is full
>
>
> Key: STORM-3073
> URL: https://issues.apache.org/jira/browse/STORM-3073
> Project: Apache Storm
> Issue Type: Bug
> Components: examples, storm-client
>Affects Versions: 2.0.0
>Reporter: Stig Rohde Døssing
>Assignee: Stig Rohde Døssing
>Priority: Major
> Labels: pull-request-available
>
> Saw this while running the
> https://github.com/apache/storm/blob/master/examples/storm-loadgen/src/main/java/org/apache/storm/loadgen/ThroughputVsLatency.java
> topology.
> {code}
> 2018-05-15 11:35:28.365 o.a.s.u.Utils Thread-16-spout-executor[8, 8] [ERROR]
> Async loop died!
> java.lang.RuntimeException: java.lang.IllegalStateException: Queue full
> at org.apache.storm.executor.Executor.accept(Executor.java:282)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.JCQueue.consumeImpl(JCQueue.java:133)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.JCQueue.consume(JCQueue.java:110)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.JCQueue.consume(JCQueue.java:101)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor$2.call(SpoutExecutor.java:168)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor$2.call(SpoutExecutor.java:157)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.Utils$2.run(Utils.java:349)
> [storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_144]
> Caused by: java.lang.IllegalStateException: Queue full
> at java.util.AbstractQueue.add(AbstractQueue.java:98) ~[?:1.8.0_144]
> at
> org.apache.storm.daemon.worker.WorkerTransfer.tryTransferRemote(WorkerTransfer.java:113)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.daemon.worker.WorkerState.tryTransferRemote(WorkerState.java:516)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.ExecutorTransfer.tryTransfer(ExecutorTransfer.java:66)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutOutputCollectorImpl.sendSpoutMsg(SpoutOutputCollectorImpl.java:140)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutOutputCollectorImpl.emit(SpoutOutputCollectorImpl.java:70)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.spout.SpoutOutputCollector.emit(SpoutOutputCollector.java:42)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.loadgen.LoadSpout.fail(LoadSpout.java:135)
> ~[stormjar.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor.failSpoutMsg(SpoutExecutor.java:360)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor$1.expire(SpoutExecutor.java:120)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor$1.expire(SpoutExecutor.java:113)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.RotatingMap.rotate(RotatingMap.java:63)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor.tupleActionFn(SpoutExecutor.java:295)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.executor.Executor.accept(Executor.java:278)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> ... 7 more
> {code}
> The executor's pendingEmits queue is full, and the executor then tries to add
> another tuple. It looks to me like we're preventing the queue from filling by
> emptying it between calls to nextTuple at
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/executor/spout/SpoutExecutor.java#L184.
> The TVL topology reemits failed tuples directly from the fail method, which
> can be triggered by tick tuples. If the pendingEmits queue is already close
> to full when this happens, we might hit the error above. I think it can also
> happen if nextTuple emits too many tuples in a call, or if too many metrics
> ticks happen between pendingEmit flushes, since metrics ticks also trigger
> emits.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (STORM-3073) In some cases workers may crash because pendingEmits is full
[
https://issues.apache.org/jira/browse/STORM-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stig Rohde Døssing updated STORM-3073:
--
Component/s: storm-client
examples
> In some cases workers may crash because pendingEmits is full
>
>
> Key: STORM-3073
> URL: https://issues.apache.org/jira/browse/STORM-3073
> Project: Apache Storm
> Issue Type: Bug
> Components: examples, storm-client
>Affects Versions: 2.0.0
>Reporter: Stig Rohde Døssing
>Assignee: Stig Rohde Døssing
>Priority: Major
>
> Saw this while running the
> https://github.com/apache/storm/blob/master/examples/storm-loadgen/src/main/java/org/apache/storm/loadgen/ThroughputVsLatency.java
> topology.
> {code}
> 2018-05-15 11:35:28.365 o.a.s.u.Utils Thread-16-spout-executor[8, 8] [ERROR]
> Async loop died!
> java.lang.RuntimeException: java.lang.IllegalStateException: Queue full
> at org.apache.storm.executor.Executor.accept(Executor.java:282)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.JCQueue.consumeImpl(JCQueue.java:133)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.JCQueue.consume(JCQueue.java:110)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.JCQueue.consume(JCQueue.java:101)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor$2.call(SpoutExecutor.java:168)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor$2.call(SpoutExecutor.java:157)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.Utils$2.run(Utils.java:349)
> [storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_144]
> Caused by: java.lang.IllegalStateException: Queue full
> at java.util.AbstractQueue.add(AbstractQueue.java:98) ~[?:1.8.0_144]
> at
> org.apache.storm.daemon.worker.WorkerTransfer.tryTransferRemote(WorkerTransfer.java:113)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.daemon.worker.WorkerState.tryTransferRemote(WorkerState.java:516)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.ExecutorTransfer.tryTransfer(ExecutorTransfer.java:66)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutOutputCollectorImpl.sendSpoutMsg(SpoutOutputCollectorImpl.java:140)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutOutputCollectorImpl.emit(SpoutOutputCollectorImpl.java:70)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.spout.SpoutOutputCollector.emit(SpoutOutputCollector.java:42)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.loadgen.LoadSpout.fail(LoadSpout.java:135)
> ~[stormjar.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor.failSpoutMsg(SpoutExecutor.java:360)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor$1.expire(SpoutExecutor.java:120)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor$1.expire(SpoutExecutor.java:113)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.RotatingMap.rotate(RotatingMap.java:63)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor.tupleActionFn(SpoutExecutor.java:295)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.executor.Executor.accept(Executor.java:278)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> ... 7 more
> {code}
> The executor's pendingEmits queue is full, and the executor then tries to add
> another tuple. It looks to me like we're preventing the queue from filling by
> emptying it between calls to nextTuple at
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/executor/spout/SpoutExecutor.java#L184.
> The TVL topology reemits failed tuples directly from the fail method, which
> can be triggered by tick tuples. If the pendingEmits queue is already close
> to full when this happens, we might hit the error above. I think it can also
> happen if nextTuple emits too many tuples in a call, or if too many metrics
> ticks happen between pendingEmit flushes, since metrics ticks also trigger
> emits.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (STORM-3073) In some cases workers may crash because pendingEmits is full
[
https://issues.apache.org/jira/browse/STORM-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stig Rohde Døssing reassigned STORM-3073:
-
Assignee: Stig Rohde Døssing
> In some cases workers may crash because pendingEmits is full
>
>
> Key: STORM-3073
> URL: https://issues.apache.org/jira/browse/STORM-3073
> Project: Apache Storm
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Stig Rohde Døssing
>Assignee: Stig Rohde Døssing
>Priority: Major
>
> Saw this while running the
> https://github.com/apache/storm/blob/master/examples/storm-loadgen/src/main/java/org/apache/storm/loadgen/ThroughputVsLatency.java
> topology.
> {code}
> 2018-05-15 11:35:28.365 o.a.s.u.Utils Thread-16-spout-executor[8, 8] [ERROR]
> Async loop died!
> java.lang.RuntimeException: java.lang.IllegalStateException: Queue full
> at org.apache.storm.executor.Executor.accept(Executor.java:282)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.JCQueue.consumeImpl(JCQueue.java:133)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.JCQueue.consume(JCQueue.java:110)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.JCQueue.consume(JCQueue.java:101)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor$2.call(SpoutExecutor.java:168)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor$2.call(SpoutExecutor.java:157)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.Utils$2.run(Utils.java:349)
> [storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_144]
> Caused by: java.lang.IllegalStateException: Queue full
> at java.util.AbstractQueue.add(AbstractQueue.java:98) ~[?:1.8.0_144]
> at
> org.apache.storm.daemon.worker.WorkerTransfer.tryTransferRemote(WorkerTransfer.java:113)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.daemon.worker.WorkerState.tryTransferRemote(WorkerState.java:516)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.ExecutorTransfer.tryTransfer(ExecutorTransfer.java:66)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutOutputCollectorImpl.sendSpoutMsg(SpoutOutputCollectorImpl.java:140)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutOutputCollectorImpl.emit(SpoutOutputCollectorImpl.java:70)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.spout.SpoutOutputCollector.emit(SpoutOutputCollector.java:42)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.loadgen.LoadSpout.fail(LoadSpout.java:135)
> ~[stormjar.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor.failSpoutMsg(SpoutExecutor.java:360)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor$1.expire(SpoutExecutor.java:120)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor$1.expire(SpoutExecutor.java:113)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.RotatingMap.rotate(RotatingMap.java:63)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor.tupleActionFn(SpoutExecutor.java:295)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.executor.Executor.accept(Executor.java:278)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> ... 7 more
> {code}
> The executor's pendingEmits queue is full, and the executor then tries to add
> another tuple. It looks to me like we're preventing the queue from filling by
> emptying it between calls to nextTuple at
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/executor/spout/SpoutExecutor.java#L184.
> The TVL topology reemits failed tuples directly from the fail method, which
> can be triggered by tick tuples. If the pendingEmits queue is already close
> to full when this happens, we might hit the error above. I think it can also
> happen if nextTuple emits too many tuples in a call, or if too many metrics
> ticks happen between pendingEmit flushes, since metrics ticks also trigger
> emits.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (STORM-3073) In some cases workers may crash because pendingEmits is full
[
https://issues.apache.org/jira/browse/STORM-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475804#comment-16475804
]
Stig Rohde Døssing commented on STORM-3073:
---
For the spout executors I don't think this is a big issue, because as far as I
can tell it only happens if the spout emits from non-nextTuple method, if the
spout is blocked for so long that it receives 1024 metrics ticks while being
unable to flush, or if it emits many tuples in one nextTuple call (which is a
bad idea anyway because it prevents maxSpoutPending from working properly).
"Fixing" this by allowing pendingEmits to grow unbounded would likely just lead
to unbounded growth and OOME for cases like spouts emitting from fail().
I think it might be an issue for bolts though, since this puts a cap on how
many tuples a bolt can safely emit per input tuple, without potentially
crashing the worker. For example, I modified ExclamationTopology so the bolt
emits 2048 copies of the input tuple, and this crashes the worker if the bolt
executor happens to need to put the tuples in pendingEmits.
We should be able to fix this by uncapping the pendingEmits size (maybe just
for bolts, not sure there's a good reason to do it for spouts).
> In some cases workers may crash because pendingEmits is full
>
>
> Key: STORM-3073
> URL: https://issues.apache.org/jira/browse/STORM-3073
> Project: Apache Storm
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Stig Rohde Døssing
>Priority: Major
>
> Saw this while running the
> https://github.com/apache/storm/blob/master/examples/storm-loadgen/src/main/java/org/apache/storm/loadgen/ThroughputVsLatency.java
> topology.
> {code}
> 2018-05-15 11:35:28.365 o.a.s.u.Utils Thread-16-spout-executor[8, 8] [ERROR]
> Async loop died!
> java.lang.RuntimeException: java.lang.IllegalStateException: Queue full
> at org.apache.storm.executor.Executor.accept(Executor.java:282)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.JCQueue.consumeImpl(JCQueue.java:133)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.JCQueue.consume(JCQueue.java:110)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.JCQueue.consume(JCQueue.java:101)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor$2.call(SpoutExecutor.java:168)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor$2.call(SpoutExecutor.java:157)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.Utils$2.run(Utils.java:349)
> [storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_144]
> Caused by: java.lang.IllegalStateException: Queue full
> at java.util.AbstractQueue.add(AbstractQueue.java:98) ~[?:1.8.0_144]
> at
> org.apache.storm.daemon.worker.WorkerTransfer.tryTransferRemote(WorkerTransfer.java:113)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.daemon.worker.WorkerState.tryTransferRemote(WorkerState.java:516)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.ExecutorTransfer.tryTransfer(ExecutorTransfer.java:66)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutOutputCollectorImpl.sendSpoutMsg(SpoutOutputCollectorImpl.java:140)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutOutputCollectorImpl.emit(SpoutOutputCollectorImpl.java:70)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.spout.SpoutOutputCollector.emit(SpoutOutputCollector.java:42)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.loadgen.LoadSpout.fail(LoadSpout.java:135)
> ~[stormjar.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor.failSpoutMsg(SpoutExecutor.java:360)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor$1.expire(SpoutExecutor.java:120)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor$1.expire(SpoutExecutor.java:113)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.utils.RotatingMap.rotate(RotatingMap.java:63)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at
> org.apache.storm.executor.spout.SpoutExecutor.tupleActionFn(SpoutExecutor.java:295)
> ~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
> at org.apache.storm.executor.Executor.accept(Executor.java:278)
>
[jira] [Created] (STORM-3073) In some cases workers may crash because pendingEmits is full
Stig Rohde Døssing created STORM-3073:
-
Summary: In some cases workers may crash because pendingEmits is
full
Key: STORM-3073
URL: https://issues.apache.org/jira/browse/STORM-3073
Project: Apache Storm
Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Stig Rohde Døssing
Saw this while running the
https://github.com/apache/storm/blob/master/examples/storm-loadgen/src/main/java/org/apache/storm/loadgen/ThroughputVsLatency.java
topology.
{code}
2018-05-15 11:35:28.365 o.a.s.u.Utils Thread-16-spout-executor[8, 8] [ERROR]
Async loop died!
java.lang.RuntimeException: java.lang.IllegalStateException: Queue full
at org.apache.storm.executor.Executor.accept(Executor.java:282)
~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at org.apache.storm.utils.JCQueue.consumeImpl(JCQueue.java:133)
~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at org.apache.storm.utils.JCQueue.consume(JCQueue.java:110)
~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at org.apache.storm.utils.JCQueue.consume(JCQueue.java:101)
~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at
org.apache.storm.executor.spout.SpoutExecutor$2.call(SpoutExecutor.java:168)
~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at
org.apache.storm.executor.spout.SpoutExecutor$2.call(SpoutExecutor.java:157)
~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at org.apache.storm.utils.Utils$2.run(Utils.java:349)
[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_144]
Caused by: java.lang.IllegalStateException: Queue full
at java.util.AbstractQueue.add(AbstractQueue.java:98) ~[?:1.8.0_144]
at
org.apache.storm.daemon.worker.WorkerTransfer.tryTransferRemote(WorkerTransfer.java:113)
~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at
org.apache.storm.daemon.worker.WorkerState.tryTransferRemote(WorkerState.java:516)
~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at
org.apache.storm.executor.ExecutorTransfer.tryTransfer(ExecutorTransfer.java:66)
~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at
org.apache.storm.executor.spout.SpoutOutputCollectorImpl.sendSpoutMsg(SpoutOutputCollectorImpl.java:140)
~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at
org.apache.storm.executor.spout.SpoutOutputCollectorImpl.emit(SpoutOutputCollectorImpl.java:70)
~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at
org.apache.storm.spout.SpoutOutputCollector.emit(SpoutOutputCollector.java:42)
~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at org.apache.storm.loadgen.LoadSpout.fail(LoadSpout.java:135)
~[stormjar.jar:2.0.0-SNAPSHOT]
at
org.apache.storm.executor.spout.SpoutExecutor.failSpoutMsg(SpoutExecutor.java:360)
~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at
org.apache.storm.executor.spout.SpoutExecutor$1.expire(SpoutExecutor.java:120)
~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at
org.apache.storm.executor.spout.SpoutExecutor$1.expire(SpoutExecutor.java:113)
~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at org.apache.storm.utils.RotatingMap.rotate(RotatingMap.java:63)
~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at
org.apache.storm.executor.spout.SpoutExecutor.tupleActionFn(SpoutExecutor.java:295)
~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
at org.apache.storm.executor.Executor.accept(Executor.java:278)
~[storm-client-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
... 7 more
{code}
The executor's pendingEmits queue is full, and the executor then tries to add
another tuple. It looks to me like we're preventing the queue from filling by
emptying it between calls to nextTuple at
https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/executor/spout/SpoutExecutor.java#L184.
The TVL topology reemits failed tuples directly from the fail method, which can
be triggered by tick tuples. If the pendingEmits queue is already close to full
when this happens, we might hit the error above. I think it can also happen if
nextTuple emits too many tuples in a call, or if too many metrics ticks happen
between pendingEmit flushes, since metrics ticks also trigger emits.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (STORM-2472) kafkaspout should work normally in kerberos mode with kafka 0.9.x API
[ https://issues.apache.org/jira/browse/STORM-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated STORM-2472: -- Labels: pull-request-available (was: ) > kafkaspout should work normally in kerberos mode with kafka 0.9.x API > - > > Key: STORM-2472 > URL: https://issues.apache.org/jira/browse/STORM-2472 > Project: Apache Storm > Issue Type: Improvement > Components: storm-kafka-client >Reporter: liuzhaokun >Assignee: liuzhaokun >Priority: Major > Labels: pull-request-available > Time Spent: 1h 40m > Remaining Estimate: 0h > > storm 1.0.x-branch didn't support kafkaspout to consume from kafka in > kerberos mode with we can't set kafka's parameter > ,'java.security.auth.login.config', in storm's process .So I solve it via > preparing a kafkaspout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
