Sorry for the late reply, Malcolm. The task.class error you're seeing is because the config does not define app.class. For Samza 1.0 and later, the preferred way of defining your Samza application in the configuraions is to set app.class, which is the fully qualified class name of the implemented StreamApplication or TaskApplication class. If app.class is not defined, the fallback is to check the legacy task.class configuration. The task.class value is the fully qualified class name of the implemented StreamTask or AsyncStreamTask class. More info about the configs are here: http://samza.apache.org/learn/documentation/latest/jobs/samza-configurations.html#application-configurations
By the description of your errors, it looks like it's trying to class load the class defined by task.class but it can't find it. Are you trying to run the latest hello-samza sample? If you are still running into the issue, could you send us your configs and your logs? On Thu, Jul 18, 2019 at 10:49 PM Malcolm McFarland <mmcfarl...@cavulus.com> wrote: > Here's another twist: I'm attempting to create a "start-only" instance of > my Samza app by pulling the existing, functional tarball down from S3, > expanding it, and using the run-app.sh and the *.properties file within it > to start the YARN task. This all seems to work just fine, but when I start > the task in this manner, I'm seeing a bunch of failed attempts on YARN with > a 'Exception in thread "main" java.lang.ClassNotFoundException' error. This > seems bonkers, since all I'm doing is using exactly the same config file to > point YARN at exactly the same tarball in exactly the same place. I'm even > killing the previous process before restarting it, just in case there's > some sort of conflict there. How on Earth could the same sequence of steps > produce these two different results? Does the JAVA_PATH variable from the > box I *start* the task from affect the box that *runs* the task? > > Cheers, > Malcolm McFarland > Cavulus > > > This correspondence is from HealthPlanCRM, LLC, d/b/a Cavulus. Any > unauthorized or improper disclosure, copying, distribution, or use of the > contents of this message is prohibited. The information contained in this > message is intended only for the personal and confidential use of the > recipient(s) named above. If you have received this message in error, > please notify the sender immediately and delete the original message. > > > On Wed, Jul 17, 2019 at 8:46 PM Malcolm McFarland <mmcfarl...@cavulus.com> > wrote: > > > Hey Folks, > > > > I'm trying to setup a load-only installation of Samza -- in other words, > a > > process that starts a Samza processor task on YARN, but isn't using the > > actual config file that's bundled into the YARN package -- and I'm > getting > > some flack from run-app.sh that the task.class doesn't exist in the > > generic hello-samza installation I'm using. I'd really like to just be > able > > to load an already-existing Samza bundle (in this case, it's stored on > S3) > > without having to do an entire build of the bundle. Is this possible? If > > so, why would run-app.sh care if the bundle is built locally or not? > > > > Cheers, > > Malcolm McFarland > > Cavulus > > > > > > This correspondence is from HealthPlanCRM, LLC, d/b/a Cavulus. Any > > unauthorized or improper disclosure, copying, distribution, or use of the > > contents of this message is prohibited. The information contained in this > > message is intended only for the personal and confidential use of the > > recipient(s) named above. If you have received this message in error, > > please notify the sender immediately and delete the original message. > > >
