I am getting “java.lang.IllegalArgumentException: Array of strings are not implemented yet” while trying to read double array data with fetpapi with fesapi.
clarification about FESAPI - 2.4.1.0.
We cloned master couple of months ago and fesapi library files had version 2.4.1.0.
I noticed that fesapi v2.5.0.0 was released in Jan 2023.
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.
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.
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.
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
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.
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.
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.
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 FetpapiClient.java
