java.lang.IllegalArgumentException: Array of strings are not implemented yet

Hello @philippeVerney,

I am getting “java.lang.IllegalArgumentException: Array of strings are not implemented yet” while trying to read double array data with fetpapi with fesapi.

Following is from the client program from fetpapiClient/ at main · F2I-Consulting/fetpapiClient · GitHub

I also attempted to read Grid2dRepresentation as well like below and get the same exception:

SWIGTYPE_p_double zValues = fesapi.new_DoubleArray(jSize * iSize);

Could you please advise regarding this ?


Hi @shakirhusain

I will look at it when time permits.
Could you please confirm which FESAPI version you are using?
I guess you are using FETPAPI master by the way

Thanks for quick response @philippeVerney!
Yes, from master

FESAPI does not exist
I already see that no dataArray protocol is set in the JAVA example: fetpapiClient/ at main · F2I-Consulting/fetpapiClient · GitHub lines 25 to 30.
I think you would need to set it to deal with arrays. Something like
session.setDataArrayProtocolHandlers(new DataArrayHandlers(session));

I am not on a compute with an ETP server access so I won’t be able to do more quickly.

clarification about FESAPI -
We cloned master couple of months ago and fesapi library files had version
I noticed that fesapi v2.5.0.0 was released in Jan 2023.

Hi @philippeVerney

As you suggested we set

session.setDataArrayProtocolHandlers(new DataArrayHandlers(session)); in fetpapiClient/ at main · F2I-Consulting/fetpapiClient · GitHub

And as well

After this getSession().send(mb,0,0x02);
we are not getting call back in MyOwnDataArrayHandler.

Could you please advise regarding this ?
Sidrah Islam

Hi @sidrah855,

I just found some time to test.
Here is my environement:

  • FESAPI with java
  • FETPAPI master with FESAPI and with JAVA (avro 1.10.1, boost 1.75, no ssl)
  • FETPAPI client master
  • open etp server deployed on a private VPS over internet
  • open etp server is initialized with Volve data Volve_Demo_Reservoir_Grid_Depth.epc
  • I have changed line 68 of CoreHandlers to be “mb.getContext().setUri(“eml:///dataspace(‘demo/Volve’)”);”
  • My FETPAPI client program arguments are : secretVpsIP 9002 / “Basic Zm9vOmJhcg==”

I run my program, can connect, can GetAll and can GetXYZ without any other change.
To summarize, I cannot reproduce your bug.

The message that you have initially seen look to come from this line.
It looks that your server did not populate the DataArrayMetadata transportArrayType.
Which server are you using please? If you are using the FETPAPI server, it is not really maintained now that the open ETP server has been adopted by OSDU. I would encourage you to switch to the open ETP server.

Thanks for your response.
Wanted to mention that we are running openETP server as docker container from OSDU.
We got it from this URL: Open Subsurface Data Universe Software / Platform / Domain Data Management Services / Reservoir / Open ETP Server · GitLab


Did you run the exact same steps as I meaning :

  • open etp server is filled with Volve data
  • with the java client example modified to target the correct dataspace, you first connect
  • you then GetAll
  • you finally GetXYZ


Please also be aware that fetpapi master now require FESAPI v2.6.0.0.
However, you shouldn’t need to upgrade for your tests. Your version shoud be valid for these tests.


  1. Yes we had run the exact same steps as you mentioned but we got an exception on GetXYZ

  2. We are trying to write data to the ETP server, we also created a transactionHandler and started transaction in storeProtocol, the call back comes in on_startTransactoinResponse with boolean true which means transaction has started successfully. In on_startTransactoinResponse we are commiting transaction and call back comes in on_CommitTransactionResponse with boolean true which means transaction has been committed but data is not being written on ETP server.

@philippeVerney Could you please guide us is there any other direction for writing data to ETP server.

  1. Could you output the received exception please? We could maybe understand what the server complains about.
    You can either :
  • override CoreHandlers::on_ProtocolException and output the parameter
  • or call CoreHandlers::getProtocolExceptions and output the returned map
  1. As far as I see, you don’t push any data. You commit a transaction but there was nothing pushed during this transaction.
    Calling repo_.createBoundaryFeature creates the data on the repository but does not push this data on the server. It just creates the boundary feature locally in memory in the repository.
    You need to put the data from your repository to the server before to commit the transaction.
    Send a Store PutDataObjects message before to send a commitTransaction message.

About 2 : see a put dataobject in C++ there fetpapiClient/main.cpp at 7e726199c1caccf99cb6d786dab1e1f285da8d31 · F2I-Consulting/fetpapiClient · GitHub

In this particular example, I think you created a datarray identifier which is wrong.
I am not sure what is “dataobj” but it must be an HdfProxy in order to get some datarrays from. I am afraid it is a 2d grid instead.
Your “Uri” must be set to the URI of the HDF Proxy (of the 2d grid if you are interested in the 2d grid values).
Your “PathInRessource” looks to be set to an URI which makes no sens : it must be the path of the dataarray in the “HDF file” as mentionned in the 2d grid.

I would bet that the server is sending you a ProtocolException as a response for this sent message since your sent message looks to be not a valid one imho. You really have to override the CoreHandlers::on_ProtocolException method in order to be warned about this kind of errrors.
If the server send you back a protocolException, it would explain why you never get call back in MyOwnDataArrayHandler since the exception is sent to explain why the server cannot process your query.

Furthermore, this kind of dataarray query is quite advanced. FETPAPI with FESAPI is designed in order you would not have to deal with so much details for the general case.
On the other hand, it allows you to go at this level of detail if you much more control/performance. However, you really need in this case to know how the ETP standard (and not really FETPAPI) works.

It is nice and imho a good addition.
However, notice that you did not need to create a specialized MyOwnDataArrayHandlers (except if you want to make advanced stuff). Just setting the FETPAPI DataArrayHandlers would have been sufficient :
session.setDataArrayProtocolHandlers(new DataArrayHandlers(session));

If you don’t set this handler, your client is not informed that it is going to deal with the DataArray Protocol which may lead to a bug if you actually use it.
I even don’t understand exactly why I don’t see a bug on my environment even when I don’t set this handler and call GetXYZ. I’ll look at it.

Hi @philippeVerney,
Thank you for your continuous support!

While calling GetXYZ we are getting exception of oversize array.

Could you please guide us.

If we believe the server, it looks that FETPAPI does not split the array request in sufficient subrequests. Actually it looks that FETPAPI does not even try to split at all the array request and ask for the whole array at once which is too big.
This problem could occur if you would code your own DataArrayHandlers but it should not happen if you use the FETPAPI Handlers with the FETPAPI HDF Proxy.

What I don’t get is why I don’t face the same issue neither using VS2017 nor gcc4.8 and Java8.

I recently faced a weird issue on another computer using VS2022. The bug was caused by the optimization flags of VS2022. It may explain your bug as well depending on how you build the C++ layer.
Could you try to build the C++ library of FETPAPI without any optimization at all please?

You could also try to read much more little data array on the ETP server like obj_PolylineSetRepresentation_0f85bcf1-6bb8-4475-bfd2-7820c26114e7.xml in Volve_Demo_Fault_Horizon_TIME.epc. This is just to confirm, as a first step, that, at least, you can read arrays when they are not big.

Just ingest Volve_Demo_Fault_Horizon_TIME.epc into the open etp server and then tweak the FETPAPI java example in order to get this particular PolylineSetRepresentation in GetXyz instead of the first point set rep or the first ijk grid rep.

Thanks @philippeVerney for the prompt response.

Tried this but getting the same “array of strings not implemented yet” error. This is a random error that comes on the line getXyz.

It looks that I’ll need spend much more time on this issue. I hope to find time.
I’ll need to reproduce the bug in order to debug it. If you can give me your full environment (c++ build and java version), it could help. Or, better, if you can write me a client Docker image reproducing the bug, I could start from there.

The only remaining clues for me are:

  • get rid of C++ optimization
  • ensure you set your dataarrayhandlers as previously discussed
  • ensure you set your HdfProxy as it is done line 104 of

I will gat back to you on the environment details.

Data array handler and proxy is already set.

Do you recommend getting datasubarrays in case of large arrays?