That's great Peter, glad you've got it going. Cheers Geoff
On Mon, 5 Aug 2019 at 03:50, Peter Abramowitsch <[email protected]> wrote: > Thanks Geoff > > I've made progress. The HttpRequest Sensor is working, and I used a > Transformer type Enricher to turn a textual sensor into a pseudo boolean > using Regex. But it would it would be much tidier if one could still use a > Closure with a ternary expression via something like FunctionFromClosure, > but it looks as if all of that was deprecated. > > Anyway thanks for your help! The latch works beautifully and thank > goodness it accepts "true" to be the same as boolean true > > > [image: image.png] > > On Sun, Aug 4, 2019 at 3:48 PM Geoff Macartney <[email protected]> > wrote: > >> 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 >> > >> >
