Hi Jiadong,
Thanks for the feedback.
Our team has decided to just upload jar files via CLI.
Thanks
Regards
Patricia
On Thu, Aug 17, 2023, 11:52 PM jiadong.lu wrote:
> Hi Patricia
> Sorry for giving wrong advice. I tried the url path of "/v1/jar/upload"
> and it did respond the same 404. Fo
Hi Elakiya,
In general I think there would be two steps to start a job: launch jm node
including dispatcher, resource manager, and then submit sql job to
dispatcher. The dispatcher will launch a rest server, and the client will
connect to the rest server to submit a job.
>From your error message,
Hello,
Sorry for frequent questions. This is a question about 'reactive' mode.
1. As far as I understand, though I've setup `scheduler-mode: reactive`, it
will not change parallelism automatically by itself, by CPU usage or Kafka
consumer rate. It needs additional resource monitor features (such a
Hi!
I think what you need is probably not the reactive mode but a proper
autoscaler. The reactive mode as you say doesn't do anything in itself, you
need to build a lot of logic around it.
Check this instead:
https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-main/docs/custom-resou
… mirrored back to user list …
On additional thing you can do is to not split into 10 additional tasks but:
* Fan-out your original event into 10 copies (original key,
1-of-10-algorithm-key, event),
* key by the combined key (original key, algorithm key)
* have a single operator chai
Hi Galen,
> Gordon, is there a trick to running the sample code in
flink-statefun-playground against yet-unreleased code that I'm missing?
You'd have to locally build an image from the release branch, with a
temporary image version tag. Then, in the flink-statefun-playground, change
the image ver
Thanks.
If you were to build a local image, as you suggest, how do you access that
image when building the playground images? All the compilation of
playground code happens inside containers, so local images on the host
aren't available in those containers. Unless I'm missing something?
I've slig
Hi Galen,
> locally built code is copied into the build containers
so that it can be accessed during the build.
That's exactly what we had been doing for release testing, yes. Sorry I
missed that detail in my previous response.
And yes, that sounds like a reasonable approach. If I understand you
Yes, exactly! And in addition to the base Statefun jars and the jar for the
Java SDK, it does an equivalent copy/register operation for each of the
other SDK libraries (Go, Python, Javascript) so that those libraries are
also available when building the playground examples.
One more question: In o
Hi Galen,
The original intent of having a separate repo for the playground repo, was
that StateFun users can just go to that and start running simple examples
without any other distractions from the core code. I personally don't have
a strong preference here and can understand how it would make th
Gotcha, makes sense as to the original division.
>> Can this be solved by simply passing in the path to the artifacts
This definitely works if we're going to be copying the artifacts on the
host side -- into the build context -- and then from the context into the
image. It only gets tricky to hav
11 matches
Mail list logo
