mkoohafkan / dssrip2 Goto Github PK

When performing a dss_catalog call on a large DSS file, the JVM may run out of heap space, producing the error:

java.lang.OutOfMemoryError: Java heap space

The solution is to set the JVM parameter prior to the library call to dssrip2, increasing the allocated JVM memory. e.g.:

options(java.parameters = "-Xmx8000m")
library(dssrip2)

If dssrip2 could increase allocated memory prior to launching the JVM, that would be ideal.

Not time-sensitive, but it looks like httr will eventually be deprecated in favor of httr2.

dss_install_monolith() still needs to be consolidated.

I am unable to connect to program files. I have attached my version of HEC-DSSVue and HEC-DSSVue jar availible. My path is correct so I am unsure of the issue.

# remotes::install_github("mkoohafkan/dssrip2",force = TRUE)
require(dssrip2)
options(dss.home = "C:/Program Files/HEC/HEC-DSSVue")
options(dss.monolith = FALSE)
dss_connect('C:/Program Files/HEC/HEC-DSSVue')

Error message:
Error in get_jars(dss_home, monolith) :
No matches found for HEC-DSSVue jars:
hec.jar
rma.jar
lookup.jar
hec-dssvue.+.jar
help/dssvueHelp.jar

Version of HEC-DSSVue:

HEC-DSSVue jar availible:

Monolith is an independent collection of jars and DLL that does not require system install and will not conflict with existing DSSVue installations. Is there actually any value to supporting DSSVue installations?

Pros to supporting DSSVue

• Convenient for users who already have DSSVue installed
• Clear versioning

Cons

• Requires version-dependent configurations, since jars may be reorganized between versions. No obvious way to automatically determine DSSVue version.
• Possible Java complications since DSSVue is bundled with its own Java binaries, but R uses Java system install.

Related: #9

Adding the required DSS attributes to a data frame or tibble is pretty clunky right now. Brainstorm a better interface.

There are several attributes of a DSS record that don't translate directly to R data frames or rasters. Right now dss_read() adds one or more attributes to the data frame with naming convention dss.<attribute name> while dss_write() requires a user-supplied list with additional attributes. This is inconsistent. A more streamlined approach might be:

1. dss_read() adds an attribute dss_attributes which is a named list of DSS parameters.
2. new function dss_add_attributes() takes a user-supplied list of attributes and checks/formats it as an attribute dss_attributes.
3. dss_write() checks for an attribute dss_attributes that contains all the required attributes.

The general interface requirement is that you can do

dss_write(dss_read(file, pathname), file2, pathname2)
expect_equal(dss_read(file, pathname), dss_read(file2, pathname2))

# new_data created in R
new_data = dss_add_attributes(new_data, list(...))
dss_write(new_data, new_file, new_pathname)

Hi, I'm trying to use dssrip2 on my office computer. When I try to use the dss_read command, I get the following error:

Error in .jcall("RJavaTools", "Ljava/lang/Object;", "invokeMethod", cl, :
java.lang.NullPointerException

It seems to work fine on my personal computer, though. Any idea how to fix this?

Get CI working.

• download monolith jars via GitHub actions
• set monolith = TRUE in tests

Possibly useful

https://github.com/marketplace/actions/jar-download

https://github.com/marketplace/actions/setup-java-jdk

https://askubuntu.com/questions/98319/correct-installation-and-configuration-of-openjdk-and-r

Once rJava 1.0-7 or later makes its way to CRAN and .jvmState() is available, check the JVM state on package load. This is a pre-requisite to the functionality in autostart branch.

getting the catalog for large DSS-6 files is obscenely slow. We can use the same approach as the file handle store to cache the catalog (both condensed and non-condensed). calling dss_catalog(rebuild = TRUE) will trigger recreating the cache.

Some leftover code from dssrip creates several environments and functions containing Java object descriptions:

hecJavaObjectFieldsDB
hecJavaObjectMethodsDB
hecJavaConstantsDB
hecJavaConnectionDB
get_field()
use_method()

These are probably no longer needed and can be removed.

And maybe also update the links in Java Parameters vignette to official documentation.

May want to suggest users increase Java heap space options prior to initializing dssrip2, or do this as a default behavior. I have received the following error running dss_catalog function:

java.lang.OutOfMemoryError: GC overhead limit exceeded

Setting option to increase JVM heap space resolved issue:

options(java.parameters = "-Xmx8000m")