Hi Peter,

I think the direction you're going in sounds OK. For the HttpRequestSensor
to work properly I think you'll want "uri" in the config rather than "URI",
and the jsonPath value should be "$.server_version" rather than
"/server_version".  This will eventually give you the value "1.0.3 built
07-02-2019" for the ctakesReady sensor (scraped from the JSON in the "/up"
response).   You are right, you will need to transform that to a boolean
value in order to refer to that boolean value in the latch in the cluster.
I'm not sure what the best way to do that transformation is, but the regex
replacement could well do the job.

Anyone else have any suggestions about the best way to do that
transformation?

Regards
Geoff







On Sat, 3 Aug 2019 at 22:01, Peter Abramowitsch <[email protected]>
wrote:

> Hi Geoff
>
> I'm truly sorry for asking so many questions.  I only write after trying a
> lot of different options, looking through source, test cases and examples.
> It is tough going when one doesn't have as much familiarity as you.
>
> Here's a paraphrase of what I've configured....
>
> Application
>     *service1*
>        name "hts"
>        entity -  an API server based on VanillaJavaApp (Jetty under the
> hood)  that has a very long initialization phase and make take a minute or
> more to be ready.   It has a simple /up  url for testing whether it is
> ready to start processing.  As soon as it returns a 200 status and this:
> {"server_version":"1.0.3 built 07-02-2019"}  , it is ready:
>
>
> *   service2*
>          entity:   DynamicCluster of about 20 instances of
>                Another  VanillaJavaApp  client application  that works its
> way through a chunk of a large data set sending requests to the above
> server, beginning as soon as it is ready.
>                This client app exits if the server is not present via the
> /up command mentioned above.  So it should not even be started until then
>
>
> *What I'd like to do, is to retard the spawning of the cluster until the
> server side is ready (not just running)*
>
>
> *My strategy was to create an HttpRequestSensor in service1 that would poll
> that /up command*
>
> brooklyn.initializers:
>       - type: org.apache.brooklyn.core.sensor.http.HttpRequestSensor
>         brooklyn.config:
>           period: 20000
>           name: ctakesReady
>           targetType: java.lang.String
>           URI: $brooklyn:formatString("http://localhost:%s
> /up",$brooklyn:config("port")
> )
>           suppressDuplicates: true
>           jsonPath: "/server_version"
>
>
>
> *Then to create a variable in the server entity's map, which transformed
> the sensor result into a boolean-like value*
>
> server.isUp:
>         regexReplacement:
>           - $brooklyn:sensor("ctakesReady")
>           - ".*"
>           - "true"
>
> *And finally, in the dynamicCluster's startup to add a latch*
>
> id: client_cluster
>     type: org.apache.brooklyn.entity.group.DynamicCluster
>     brooklyn.config:
>       latch.start:
> $brooklyn:component("hts").attributeWhenReady("server.isUp")
>       cluster.initial.size: 2
>       dynamiccluster.memberspec:
>         $brooklyn:entitySpec:
>           ......
>
>
>
> I've tested all the bits in Brooklyn separately:  I can launch the server,
> I can create the cluster,  I can get that cluster to talk to a server I
> launch manually, but I just can't tie it all together
>
> In the logs I can see that the HttpRequestSensor task is scheduling each
> 20s but I can't tell if it is doing what I want.   I can't tell what
> happens when the HttpRequestSensor receives a connection refused... which
> it will do for the first minute or two.
>
> The only thing I can tell is I'm getting the following error, maybe because
> it is trying to access ctakesReady before the sensor has a chance to create
> it.
>
> 2019-08-03T12:37:27,005 DEBUG 123 o.a.b.c.f.Poller [er-OjlhJH1g-3908]
> PollJob for org.apache.brooklyn.feed.http.HttpFeed$2@6fb72eb8 handling
> java.lang.NullPointerException using
> org.apache.brooklyn.core.feed.DelegatingPollHandler@19d3dd8a[ctakesReady @
> paxy3zlxqx <- http[ctakesReady]]
> 2019-08-03T12:37:27,005 DEBUG 123 o.a.b.c.f.AttributePollHandler
> [er-OjlhJH1g-3908] Read of VanillaJavaAppImpl{id=paxy3zlxqx}->Sensor:
> ctakesReady (java.lang.String) gave exception (in grace period):
> java.lang.NullPointerException
> ......
> 2019-08-03T12:38:07,011 WARN  123 o.a.b.c.f.AttributePollHandler
> [er-OjlhJH1g-3907] Read of VanillaJavaAppImpl{id=paxy3zlxqx}->Sensor:
> ctakesReady (java.lang.String) gave exception (grace period expired,
> occurring for 40s 6ms): java.lang.NullPointerException
>
> I feel as if there should be a way to create that HTTP sensor with a
> starting value.  Also I'm sure there may be a better way to link the
> success of the HTTPSensor to the latch without the regex transformation,
> but I just can't find a good example.   All of the examples just use a
> handy boolean attribute value that's already present in the entity
> definition.
>
> There's need to solve my problem completely - but if you can point me in
> the right direction, that would be great.
>
>  Many thanks
>
> Peter
>

Reply via email to