How to stop H2OContext but the process don't need to exit about sparkling-water HOT 10 CLOSED

Hi @king1402 ,

right now we do not support stopping of H2O services. If you are interested you can make PR to deal with this issue.

from sparkling-water.

thanks very much
could you tell me What PR means

from sparkling-water.

Ahh, sorry, PR means pull requests. It is common way how to contribute into open-source projects.

from sparkling-water.

Looking at the h2o code, it will be difficult, as h2o use a lot of static variables

Any suggestions on a workaround for this?
it is very difficult to write unit tests for sparkling water since usually each suite will create it's own spark context, but the h2o context can only be created once

from sparkling-water.

Hi @lev112

yup, we are working on that and iterating H2O's API - and we appreciate any feedback!

Regarding your questions - there are two kinds of tests:

1. sharing SparkContext and H2OContext: for example here: https://github.com/h2oai/sparkling-water/blob/master/core/src/test/scala/org/apache/spark/rdd/H2OSchemaRDDTest.scala

2. each test needs a fresh H2OContext. In this case you have to implement test suite per test and make sure that your testing framework forks a new JVM for each test suite: see https://github.com/h2oai/sparkling-water/blob/master/examples/src/integTest/scala/water/sparkling/itest/local/RegularExamplesSuite.scala

Let me know if it works for you!

from sparkling-water.

hi @mmalohlava

thanks for your response.

for 1, I'm sharing context between tests in a test class, but there are a few different test class that are used,

for 2, I'm running the tests in intellij, and as far as I can tell, forking tests is not supported

looking forward for any changes in that area

from sparkling-water.

Hi @lev112

for 1., you should use one context per test class right now

for 2, i normally setup configuration in the following way:

from sparkling-water.

We are iterating H2O code to support stopping H2O inside a single JVM, right now H2O can't be fully stopped in a single JVM

from sparkling-water.

Any update on this problem

from sparkling-water.

No update so far

from sparkling-water.