[jira] [Resolved] (STORM-2837) RAS Constraint Solver Strategy
[ https://issues.apache.org/jira/browse/STORM-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Joseph Evans resolved STORM-2837. Resolution: Fixed Fix Version/s: 2.0.0 I merged this into master. > RAS Constraint Solver Strategy > -- > > Key: STORM-2837 > URL: https://issues.apache.org/jira/browse/STORM-2837 > Project: Apache Storm > Issue Type: Improvement > Components: storm-server >Affects Versions: 2.0.0 >Reporter: Robert Joseph Evans >Assignee: Robert Joseph Evans > Labels: pull-request-available > Fix For: 2.0.0 > > Time Spent: 4h > Remaining Estimate: 0h > > We have a use case where a user has some old native code and they need it to > work with storm, but sadly the code is not thread safe so they need to be > sure that each instance of a specific bolt is in a worker without other > instances of the same bolt. It also cannot co-exist with other bolts for a > similar reason. I know that this is a fairly strange use case, but to help > fix the issue we wrote a strategy for RAS that can do a simple search of the > state space trying to honor these constrains and we thought it best to push > it back then to keep it internal. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (STORM-2862) More flexible logging in multilang (Python, Ruby, JS)
[
https://issues.apache.org/jira/browse/STORM-2862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated STORM-2862:
--
Labels: pull-request-available (was: )
> More flexible logging in multilang (Python, Ruby, JS)
> -
>
> Key: STORM-2862
> URL: https://issues.apache.org/jira/browse/STORM-2862
> Project: Apache Storm
> Issue Type: Improvement
> Components: storm-client, storm-multilang
>Affects Versions: 2.0.0, 1.1.1
>Reporter: Heather McCartney
>Assignee: Heather McCartney
>Priority: Trivial
> Labels: pull-request-available
>
> We're running a Storm topology written in Python, using storm.py from
> storm-multilang. As well as human-readable logs, the topology is also
> configured to write JSON logs which are sent to ELK.
> At the moment, when storm-core receives a "log" command, it outputs the pid,
> component name, and the message it received, like so:
> {{ShellLog pid:, name: }}
> The code that does this is (currently) in [ShellBolt line
> 254|https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L254]
> and [ShellSpout line
> 227|https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/spout/ShellSpout.java#L227].
> As well as the pid and component name, it would be great to have the task ID,
> tuple ID, and the ID of the originating tuple - but this would make parsing
> the string even more laborious than it is now, and would make the default log
> message too long.
> Would it be possible to put contextual information like this in the
> [ThreadContext|https://logging.apache.org/log4j/2.x/manual/thread-context.html]
> instead? Then our JSON layout could read from the context instead of parsing
> the string, and human-readable logs could use "%mdc" in the PatternLayout
> format string.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (STORM-2862) More flexible logging in multilang (Python, Ruby, JS)
Heather McCartney created STORM-2862:
Summary: More flexible logging in multilang (Python, Ruby, JS)
Key: STORM-2862
URL: https://issues.apache.org/jira/browse/STORM-2862
Project: Apache Storm
Issue Type: Improvement
Components: storm-client, storm-multilang
Affects Versions: 2.0.0, 1.1.1
Reporter: Heather McCartney
Assignee: Heather McCartney
Priority: Trivial
We're running a Storm topology written in Python, using storm.py from
storm-multilang. As well as human-readable logs, the topology is also
configured to write JSON logs which are sent to ELK.
At the moment, when storm-core receives a "log" command, it outputs the pid,
component name, and the message it received, like so:
{{ShellLog pid:, name: }}
The code that does this is (currently) in [ShellBolt line
254|https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L254]
and [ShellSpout line
227|https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/spout/ShellSpout.java#L227].
As well as the pid and component name, it would be great to have the task ID,
tuple ID, and the ID of the originating tuple - but this would make parsing the
string even more laborious than it is now, and would make the default log
message too long.
Would it be possible to put contextual information like this in the
[ThreadContext|https://logging.apache.org/log4j/2.x/manual/thread-context.html]
instead? Then our JSON layout could read from the context instead of parsing
the string, and human-readable logs could use "%mdc" in the PatternLayout
format string.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
