Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding basic OR-matching for Streams. #1292

Merged
merged 10 commits into from Jul 14, 2015
Merged

Conversation

dennisoelkers
Copy link
Member

  • Adds attribute to streams that defines their matching type
  • Matching type is AND per default if matching type is not specified
  • Allowing to specify matching type during stream creation via REST api
  • Adding basic integration tests

@dennisoelkers dennisoelkers force-pushed the feature-stream-matcher-or-operator branch 2 times, most recently from 4a99ac1 to 3494e53 Compare July 9, 2015 11:08
- Adds attribute to streams that defines their matching type
- Matching type is AND per default if matching type is not specified
- Allowing to specify matching type during stream creation via REST api
- Adding basic integration tests
Unbreaks creating a stream with an unspecified matching type.
@dennisoelkers dennisoelkers force-pushed the feature-stream-matcher-or-operator branch from 72d3518 to db76998 Compare July 13, 2015 13:08
@bernd bernd self-assigned this Jul 13, 2015
@@ -258,8 +260,11 @@ public void increment() {
}

public boolean isMatched() {
// If a stream has multiple stream rules, all of the rules have to match.
return ruleCount == matches;
switch (stream.getMatchingType()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about storing the matching type in a field in the constructor? That would avoid calling stream.getMatchingType() over and over again.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a simple getter, so it's probably inlined anyway.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, okay. The getter does a hash map lookup, does that get inlined as well?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it's getting inlined. Sorry for the noise, just want to understand it. 😃

                            @ 197   org.graylog2.streams.StreamRouterEngine$StreamMatch::isMatched (91 bytes)   inline (hot)
                              @ 7   org.graylog2.streams.StreamImpl::getMatchingType (28 bytes)   inline (hot)
                               \-> TypeProfile (2700/2700 counts) = org/graylog2/streams/StreamImpl
                                @ 6   java.util.LinkedHashMap::get (25 bytes)   inline (hot)
                                 \-> TypeProfile (2609/2609 counts) = java/util/LinkedHashMap
                                  @ 2   java.util.HashMap::getEntry (86 bytes)   inline (hot)
                                    @ 19   java.util.HashMap::hash (55 bytes)   inline (hot)
                                      @ 27   java.lang.String::hashCode (55 bytes)   inline (hot)
                                    @ 33   java.util.HashMap::indexFor (6 bytes)   inline (hot)
                                    @ 68   java.lang.String::equals (81 bytes)   (intrinsic)
                                  @ 17   java.util.LinkedHashMap$Entry::recordAccess (35 bytes)   inline (hot)
                                    @ 6   java.util.LinkedHashMap::access$000 (5 bytes)   accessor
                                    @ 23   java.util.LinkedHashMap$Entry::remove (23 bytes)   inline (hot)
                                    @ 28   java.util.LinkedHashMap::access$100 (5 bytes)   accessor
                                    @ 31   java.util.LinkedHashMap$Entry::addBefore (30 bytes)   inline (hot)
                                @ 24   org.graylog2.plugin.streams.Stream$MatchingType::valueOf (11 bytes)   inline (hot)
                                  @ 4   java.lang.Enum::valueOf (73 bytes)   inline (hot)
                                    @ 1   java.lang.Class::enumConstantDirectory (114 bytes)   too big
                              @ 12   java.lang.Enum::ordinal (5 bytes)   accessor

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries, many thanks for your thoughtful investigation! 👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, but inlining the methods of a hash lookup is still slower than a constant/variable lookup. So if the method is called very often (as in: for every incoming message), we could still benefit from saving the matching type into a final variable in the constructor.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will change with the next PR related to the new stream router engine anyway.

bernd added a commit that referenced this pull request Jul 14, 2015
…ator

Adding basic OR-matching for Streams.
@bernd bernd merged commit 6a195e6 into master Jul 14, 2015
@bernd bernd deleted the feature-stream-matcher-or-operator branch July 14, 2015 16:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants