[jira] [Updated] (STORM-2752) Nimbus crashes silently if scheduler is not found
[ https://issues.apache.org/jira/browse/STORM-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Burian updated STORM-2752: - Priority: Minor (was: Major) > Nimbus crashes silently if scheduler is not found > - > > Key: STORM-2752 > URL: https://issues.apache.org/jira/browse/STORM-2752 > Project: Apache Storm > Issue Type: Bug >Affects Versions: 1.0.5 >Reporter: Martin Burian >Priority: Minor > > When nimbus is started and the custom scheduler specified in storm.yaml is > not in the classpath, nimbus hangs and exits with status 13 about 10s later. > No errors are logged. > Affected versions 1.0.3-5, I did not test any other. OpenJDK 8. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (STORM-2750) fix double_checked locking
[ https://issues.apache.org/jira/browse/STORM-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stig Rohde Døssing resolved STORM-2750. --- Resolution: Fixed Fix Version/s: 1.1.2 2.0.0 > fix double_checked locking > -- > > Key: STORM-2750 > URL: https://issues.apache.org/jira/browse/STORM-2750 > Project: Apache Storm > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Huaiyong Fu >Assignee: Huaiyong Fu > Labels: pull-request-available > Fix For: 2.0.0, 1.1.2 > > > update HBaseSecurityUtil singleton to fix double_checked locking > Double-Checked Locking is widely cited and used as an efficient method for > implementing lazy initialization in a multithreaded environment. > Unfortunately, it will not work reliably in a platform independent way when > implemented in Java, without additional synchronization. When implemented in > other languages, such as C++, it depends on the memory model of the > processor, the reorderings performed by the compiler and the interaction > between the compiler and the synchronization library. Since none of these are > specified in a language such as C++, little can be said about the situations > in which it will work. Explicit memory barriers can be used to make it work > in C++, but these barriers are not available in Java. > See url link for details: > http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (STORM-2755) Sharing data between Bolts
Oussama BEN LAMINE created STORM-2755: - Summary: Sharing data between Bolts Key: STORM-2755 URL: https://issues.apache.org/jira/browse/STORM-2755 Project: Apache Storm Issue Type: Question Reporter: Oussama BEN LAMINE Hello, i am facing a problem and your help will be really appreciated. so, i am using storm 1.0.1, i prepared a topology that transfers data throw a preparation bolt then to a python prediction bolt. in prediction bolt i am collecting data in real time and creating group of data then sending them to prediction function. this topology works perfectly in one machine where the machine can process all the data, but not in distributed cluster as each machine work separately and some data needed for grouping can be processed by different machine. Is there a way that bolts communicate with each other and so we can group data even if they are on different machines? can you please advice and thank you -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (STORM-2751) Remove AsyncLoggingContext from Supervisor
[
https://issues.apache.org/jira/browse/STORM-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Joseph Evans resolved STORM-2751.
Resolution: Fixed
Fix Version/s: 1.0.6
1.1.2
1.2.0
2.0.0
Thanks [~kishorvpatil],
I merged this into master and all of the 1.* branches.
> Remove AsyncLoggingContext from Supervisor
> --
>
> Key: STORM-2751
> URL: https://issues.apache.org/jira/browse/STORM-2751
> Project: Apache Storm
> Issue Type: Bug
> Components: storm-core
>Reporter: Kishor Patil
>Assignee: Kishor Patil
>Priority: Minor
> Fix For: 2.0.0, 1.2.0, 1.1.2, 1.0.6
>
>
> If disk can not keep it up with all logging, the {{AsyncLoggingContext}}
> causes large heap memory be utilized causing the JVM to churn CPU.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (STORM-2744) Add in "restart timeout" for backpressure
[ https://issues.apache.org/jira/browse/STORM-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Joseph Evans resolved STORM-2744. Resolution: Fixed Fix Version/s: 2.0.0 Thanks [~ethanli], I merged this into master > Add in "restart timeout" for backpressure > - > > Key: STORM-2744 > URL: https://issues.apache.org/jira/browse/STORM-2744 > Project: Apache Storm > Issue Type: Improvement >Reporter: Ethan Li >Assignee: Ethan Li >Priority: Minor > Labels: pull-request-available > Fix For: 2.0.0 > > Time Spent: 2h > Remaining Estimate: 0h > > Instead of stopping indefinitely we want to add a timeout value to the > backpressure mechanism so that spouts won't get stuck if bolts fail to switch > back on. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (STORM-2648) Kafka spout can't show acks/fails and complete latency when auto commit is enabled
[ https://issues.apache.org/jira/browse/STORM-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated STORM-2648: -- Labels: pull-request-available (was: ) > Kafka spout can't show acks/fails and complete latency when auto commit is > enabled > -- > > Key: STORM-2648 > URL: https://issues.apache.org/jira/browse/STORM-2648 > Project: Apache Storm > Issue Type: New Feature > Components: storm-kafka-client >Affects Versions: 2.0.0, 1.1.0, 1.2.0 >Reporter: Stig Rohde Døssing >Assignee: Stig Rohde Døssing >Priority: Minor > Labels: pull-request-available > Time Spent: 2h > Remaining Estimate: 0h > > The storm-kafka-client spout currently emits tuples with no message ids if > auto commit is enabled. This causes the ack/fail/complete latency counters in > Storm UI to be 0. In some cases this is desirable because the user may not > care, and doesn't want the overhead of Storm tracking tuples. > [~avermeerbergen] expressed a desire to be able to use auto commit without > these counters being disabled, presumably to monitor topology performance. > We should add a toggle that allows users to enable/disable tuple anchoring in > the auto commit case. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
