brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ahgittin <...@git.apache.org>
Subject [GitHub] brooklyn-server pull request #561: better presentation for sensor publishing...
Date Thu, 16 Feb 2017 10:36:12 GMT
GitHub user ahgittin opened a pull request:

    https://github.com/apache/brooklyn-server/pull/561

    better presentation for sensor publishing tasks

    previously they didn't even have a name; now they have a nice name, description, and a
tag.
    there is some attempt to optimize the use of toString so it isn't hugely computationally
expensive,
    although this will increase expense a bit; i tend to think it's worth it for increased
visibility.
    (if we are publishing vast numbers of sensor events maybe we are doing something wrong,
and if this
    is identified as the bottleneck we can parameterise it, and in any case when we come to
be multi-host
    we'll need to revisit how we do this as currently we're thinking a good datastore is good
enough for
    the intended volumes, as opposed to a dedicated message bus.)

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/ahgittin/brooklyn-server activity-descriptions

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/brooklyn-server/pull/561.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #561
    
----
commit 2c2f3fcdc456358dff108a62e0cd5ce09783048c
Author: Alex Heneveld <alex.heneveld@cloudsoftcorp.com>
Date:   2017-02-16T10:31:50Z

    better presentation for sensor publishing tasks
    
    previously they didn't even have a name; now they have a nice name, description, and a
tag.
    there is some attempt to optimize the use of toString so it isn't hugely computationally
expensive,
    although this will increase expense a bit; i tend to think it's worth it for increased
visibility.
    (if we are publishing vast numbers of sensor events maybe we are doing something wrong,
and if this
    is identified as the bottleneck we can parameterise it, and in any case when we come to
be multi-host
    we'll need to revisit how we do this as currently we're thinking a good datastore is good
enough for
    the intended volumes, as opposed to a dedicated message bus.)

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message