Project Task #9043

Project WP #665: WP7 - Supporting Blue Environment: VREs Development [Months: 7-30]

Project Task #666: T7.1 Aquaculture Atlas Generation VRE [Months: 7-30]

Project Task #8830: developments of the online viewing and editing tools

Project Task #8831: Data Publication in two environments

Develop shapefile custom uploader R process

Added by Emmanuel Blondel over 2 years ago. Updated over 2 years ago.

Status:ClosedStart date:Jun 27, 2017
Priority:NormalDue date:
Assignee:Emmanuel Blondel% Done:

100%

Sprint:WP07
Lead beneficiary:12 - CLS Participants:5 - FAO
Milestones:
Duration:

Description

R process to harmonize shapefile data upload/update & layer config into Geoserver. Will perform:
• harmonization tasks, file renaming as deemed necessary
• data upload/update (overwriting in this case)
• layer publication/update

Input params will be:
• a list of target countries, to select the scope of shapefile
• shapefile 1 (farms)
• shapefile 2 (cages)

Output will be a basic file recap of the uploads.

R process will be scalable (with business logic that could evolve, e.g. move data storage to postgis)

To be plugged as R SAI/dataminer process.

staging_shapefiles.log (85.1 KB) Andrea Dell'Amico, Jul 05, 2017 11:57 AM


Subtasks

Project Task #9071: Install geosapi R packageClosed_InfraScience Systems Engineer


Related issues

Related to BlueBRIDGE - Project Task #9040: AquacultureAtlasGeneration (AAPS) - Enable SAI/DataMiner/... Closed Jun 26, 2017 Jun 30, 2017
Related to gCube - Feature #9114: DataMiner - Add pagination to Workspace Explorer Closed Jun 30, 2017
Related to BlueBRIDGE - Support #9242: Need of 2 user accounts in Geonetwork for AAPS and PAIM Closed Jul 11, 2017

History

#1 Updated by Emmanuel Blondel over 2 years ago

  • Related to Project Task #9040: AquacultureAtlasGeneration (AAPS) - Enable SAI/DataMiner/RStudio stack on VRE added

#2 Updated by Emmanuel Blondel over 2 years ago

  • % Done changed from 0 to 80

Process is almost ready. Waiting for #9040 for publishing as SAI/DataMiner algorithm in AAPS VRE.
@nlongepe@cls.fr i've run it directly and published the 2 layers for Greece UC: staging:grc_farms, and staging:grc_cages. These are draft. Since not all fields provided in your shapefiles have a length < 10, the process applies extra truncating. To avoid it, I would suggest that you reduce the field names length, in particular where possible to remove the prefix "farm_" or "cage_", not needed, and possibly to use alternate naming, so name length are all <=10. Example for FARMS:

Field name length:
farm_id edit_name edit_timest farm_name design prod_system material feed_system status species_nam farm_confid source_im_d farm_surfac
7 9 11 9 6 11 8 11 6 11 11 11 11

My suggestions:

farm_id
edit_name
edit_time
name
design
prod_sys
material
feed_sys
status
species
confid
src_im_d
surface

Let me know

#3 Updated by Emmanuel Blondel over 2 years ago

Some additions for feedback @nlongepe@cls.fr
• the "edit_name" is the name of the editor right, can you confirm?
• @anton.ellenbroek@fao.org suggested values for the status: New / Validated / Rejected. So by default all status values should be set to 'New' in your shapefiles. @mgoacolou@cls.fr We will further refine the status 'actions' to be handled through the web-app in #9042

#4 Updated by Emmanuel Blondel over 2 years ago

i've submitted this process, identified as AAPS_staging_publisher, for deployment in RPrototypingLab VRE / DataMiner (according to exchange in #9040)

#5 Updated by Emmanuel Blondel over 2 years ago

  • Status changed from New to In Progress

The algorithm is now published https://i-marine.d4science.org/group/rprototypinglab/data-miner?OperatorId=org.gcube.dataanalysis.wps.statisticalmanager.synchserver.mappedclasses.transducerers.AAPS_STAGING_PUBLISHER thanks to @scarponi@isti.cnr.it for his prompt support

I'm still troubleshooting the algorithm: The first thing is the way Dataminer provides the file to the algorithm (strangely with .csv extension, which at first view appears weird in logs; and as temp dir, not in current working dir). I've finally modified the algorithm to bypass this specific environment setting Now the process does not fail... but doesn't stop at all... it got stuck at 10% since minutes now. @gianpaolo.coro@isti.cnr.it Can you please provide me ongoing log for process ID: 54eae810-0982-4785-a8e6-6839f3d006c8 ?

FYI, it's not a time consuming process, in Rstudio in about 7-8s it's done.

Thanks in advance for your feedback

#6 Updated by Emmanuel Blondel over 2 years ago

  • Assignee changed from Emmanuel Blondel to Gianpaolo Coro
  • Status changed from In Progress to Feedback

#7 Updated by Gianpaolo Coro over 2 years ago

Hi Emmanuel, usually this happens when some R package is missing. Could you please give me the list of packages you are using and two test files to execute the algorithm?

#8 Updated by Nicolas Longépé over 2 years ago

@emmanuel.blondel@fao.org I have changed the name of the variables in the shapefiles, edited the "status" variable as you suggested (even though it was originally conceived to determine whether the cages/farms were still active... but OK to drop it), and uploaded the new versions in the WP7 directory here https://goo.gl/lJ5ejt

thanks

#9 Updated by Emmanuel Blondel over 2 years ago

@nlongepe@cls.fr my fault, i thought it was the validation status we talked recently. Please provide 2 fields then, 1 for status, that should be the definition you say: Active/Inactive. And add a new field within the limitation of 10characters that should correspond to the validation status: New / Validated / Rejected. Let me know when done

#10 Updated by Emmanuel Blondel over 2 years ago

@gianpaolo.coro@isti.cnr.it i've liaised earlier yesterday for package geosapi, because it was not installed everywhere, but in this case it was clearly indicated in the log the missing package. Packages used here are sp, rgdal, geosapi, and jsonlite. As said geosapi was installed yesterday, and the others were already available. See 60b6b9d8-f31b-44eb-8cdd-114a4571da4a process. For the tests, i've shared with you AquacultureAtlasGeneration/Data & AquacultureAtlasGeneration/Processes WS folders

#11 Updated by Nicolas Longépé over 2 years ago

Emmanuel Blondel wrote:

@nlongepe@cls.fr my fault, i thought it was the validation status we talked recently. Please provide 2 fields then, 1 for status, that should be the definition you say: Active/Inactive. And add a new field within the limitation of 10characters that should correspond to the validation status: New / Validated / Rejected. Let me know when done

Done

#12 Updated by Emmanuel Blondel over 2 years ago

Yes, @nlongepe@cls.fr please add them to the VRE folder AquacultureAtlasGeneration > Data > Greece I don't have permissions to do it.

#13 Updated by Nicolas Longépé over 2 years ago

It is now at the right place

#14 Updated by Emmanuel Blondel over 2 years ago

@gianpaolo.coro@isti.cnr.it To better see what's happening in the algorithm, i've temporarily pointed it to qa geoserver where i can inspect the data directory. The algorithm is in charge of doing sequently the validation, checking and upload of 2 shapefiles for AAPS. What i did is to deactivate the 2d publication (ie publication of the 2d input file), the algorithm worked. Reversely, i tried to deactivate the first shapefile publication (corresponding the first file parameter of the DB algorithm), and this is where the algorithm get stuck. Something happens with the 2d File Input parameter, that makes DM get stuck. Any idea? AFAIK, DM allows users to specify N file input parameters, right? Thanks in advance for your help

#15 Updated by Gianpaolo Coro over 2 years ago

Hi Emmanuel,
I see your process is using this geoserver: https://geoserver1-spatial-dev.d4science.org/geoserver
It gets stuck exactly the "Uploading data and publish layer 'grc_cages' to Geoserver" log, thus when it tries to upload the shapefile on the geoserver.
The reason of the process blocking is an uncaught exception that does not allow the process to end.

In particular, the issue is likely to happen at this line:

out <- manager$uploadShapefile(ws, ds, endpoint = "file",
configure = "none", update = "overwrite",
paste0(name, ".zip"), "UTF-8")

The error I see is

"[geosapi][ERROR] Error while fetching layer Error in publishAAPSShapefile(AAPS_GS, sp, output, type) : object 'type' not found"

Please, try to surround that line with logs and a try{}catch{} to manage it. I cannot do it since SAI says I do not have sufficient privileges.

#16 Updated by Gianpaolo Coro over 2 years ago

This is the complete answer from the Geoserver:

<- Server: nginx
<- Date: Thu, 29 Jun 2017 16:11:52 GMT
<- Content-Length: 0
<- Connection: keep-alive
<- Access-Control-Allow-Credentials: true
<- Access-Control-Allow-Methods: GET, POST, OPTIONS
<- Access-Control-Allow-Headers: Accept,Authorization,Cache-Control,Content-Type,DNT,If-Modified-Since,Keep-Alive,O rigin,User-Agent,X-Mx-ReqToken,X-Requested-With
<-
[geosapi][INFO] Successfull data upload!
[geosapi][INFO] Fetching layer 'grc_cages'
-> GET /geoserver/rest/layers/grc_cages.xml HTTP/1.1
-> Host: geoserver1-spatial-dev.d4science.org
-> Accept-Encoding: gzip, deflate
-> Cookie: JSESSIONID=4D0FAE33AAE7343B74FB7581CD76B9A3
-> Accept: application/json, text/xml, application/xml, */*
-> User-Agent: geosapi-0.2.0
-> Authorization: Basic YWRtaW46Z2Vvc2VydmVy
->
<- HTTP/1.1 404 Not Found
<- Server: nginx
<- Date: Thu, 29 Jun 2017 16:11:53 GMT
<- Content-Type: text/plain
<- Transfer-Encoding: chunked
<- Connection: keep-alive
<- Content-Encoding: gzip
<-
[geosapi][ERROR] Error while fetching layer
Error in publishAAPSShapefile(AAPS_GS, sp, output, type) :
  object 'type' not found

#17 Updated by Emmanuel Blondel over 2 years ago

Thanks Gianpaolo for your feedback, i will check further these lines

#18 Updated by Emmanuel Blondel over 2 years ago

Ok that error was a typo when a refactored a bit the R script to debug, modifying the "type" variable to be "productType". The code (that i deactivate) normally do it sequencially the publication for 2 products ("farm", corresponding to the first input file, and "cage", the second input file), but it's still stuck for the second file. Let me see if I can give privileges for the SAI folder

#19 Updated by Gianpaolo Coro over 2 years ago

Hi Emmanuel, in the staging algorithm I have added lines 209-224 that add a try-catch around the publication process, but the process seems to be working. Could you please return to the condition in which you had the error? Otherwise I cannot figure out what to look at.

#20 Updated by Emmanuel Blondel over 2 years ago

@gianpaolo.coro@isti.cnr.it i didn't see your try-catch, possibly because i've edited in the same time, apologies. I've identified where it goes stuck: when trying to upload it to Geoserver. I further tested the algorithm and it's a status quo, by the way here some findings:

  • algorithm works well in RStudio for both "farm" and "cage" products.

in DataMiner, here is the situation:
* the algorithm works well for "farm" (file provided as 1st File Parameter).
* It doesn't work for the "cage" (provided as 2d File Parameter)
* I've tried to invert the inputs, so to try to upload the cage file through the 1st File Input parameter. This is to see if it deals with the data or the fact it is with the 2d File parameter. And.. it goes stuck. Which means it excludes any problem dealing with the fact it is with 2d input file, and means for this specific cage file it doesn't work in Dataminer. But.... in RStudio, with the same file it works like a charm.

So at this point i'm really stuck.. It concerns one dataset, and only the Dataminer context, which is really weird.

#21 Updated by Emmanuel Blondel over 2 years ago

@gianpaolo.coro@isti.cnr.it @pasquale.pagano@isti.cnr.it The DataMiner seems completely stuck in RPrototypingLab. All requests stay in "Accepted" status, and the check computations list is not accessible (I get a timeout message through an alert window).

I'd like to understand why the present R process is not working in Dataminer, while it is working very well when executed from Rstudio. Is there any particular limitation, or different server configuration than what we have in server backing RStudio? In addition, in order to troubleshoot this, i would need access through SFTP / SSH, so I could inspect logs at runtime. could you please provide it? Thanks in advance

#22 Updated by Paolo Scarponi over 2 years ago

Hello Emmanuel,

as for the "check the computation" page loading issue, i might be related to the number of executed processes you have in such folder. There is also a task scheduled to fix this problem (see task #9114)

About the broken functionality of your algorithm once deployed it should depend either on some input/output definition mistake or some dependencies conflict, am I right @gianpaolo.coro@isti.cnr.it ?

Do you need access to the dataminer instance wherein the algorithm is running? I don't know how security is managed in this case, maybe @andrea.dellamico@isti.cnr.it knows if we can give you access to the macihine(s).

#23 Updated by Emmanuel Blondel over 2 years ago

Hello @scarponi@isti.cnr.it the access to dataminer instance would be definitely useful to inspect log at runtime. I exclude I/O issue, the algorithm works for the first file, but not for the 2d one. I've also performed isolated tests through the DM algorithm to see if there were limitations, I want to do more tests today, so far the upload works with the "farms" shapefile but bigger shapefiles like the "cages" one, but also other shapefiles i would take are not uploaded, and this where the process get stuck. The whole process works in few seconds in Rstudio.

Let me know if you can provide me access to machine/logs. Thanks

#24 Updated by Giancarlo Panichi over 2 years ago

  • Related to Feature #9114: DataMiner - Add pagination to Workspace Explorer added

#25 Updated by Paolo Scarponi over 2 years ago

"the upload works with the "farms" shapefile but bigger shapefiles like the "cages" one, but also other shapefiles i would take are not uploaded" with this you mean that the file upload onto the workspace gets stuck or the algorithm fails to load the file to operate on it?

#26 Updated by Emmanuel Blondel over 2 years ago

No, i don't upload to workspace, i pick up files from the workspace, I process them, zip them as shapefile and upload them to Geoserver through geosapi package. Apparently the DM process gets stuck when trying to upload the zipped shapefile to Geoserver, but it gets stuck only in DM, and only for some datasets.

#27 Updated by Paolo Scarponi over 2 years ago

I was talking with @fabio.sinibaldi@isti.cnr.it about your issue and he might have some suggestions/ideas to solve it. I will add him as a watcher. Moreover, to be completely sure that the R version and the dataminer version of the algorithm are the same you may want to republish it again. There might have been some issues during prior repackaging operations.

#28 Updated by Fabio Sinibaldi over 2 years ago

Hi, just to be sure : how does the algorithm retrieve the geoserver instance to use? More important : are the two versions of the algorithm (one from RStudio and one from DM) using the same geoserver instance? I ask this because a possible issue might be due to a restriction in nginx configuration. If they use the same instance we can exclude this cause.

#29 Updated by Emmanuel Blondel over 2 years ago

For the repackaging: I don't count anymore the nb of times I did repackaging while troubleshooting, I never had repackaging issue, each time the execution was reflecting the changes performed earlier in SAI. So it's not a problem a repackaging.

For the target geoserver, yes of course i'm doing the tests targeting the same Geoserver, and it works from RStudio. So i've excluded a restriction on the target server config (PS: for the timebeing i hardcode geoserver instance & credentials, also because i'm asked to develop in RPrototypingLab).

I'm now testing through the same algorithm isolated pieces of R code consisting in grabing some zipped shapefiles (e.g. from Worspace, from Geoserver), and push them as they are to a target Geoserver, which is where the algo gets stuck.

I've finished some tests i've started on friday, suspecting an issue with the size of the files i try to upload to Geoserver through DataMiner. Through the DM algo, i've just tested grabing a zipped shapefile and push it as it is. The complete zipped shapefile tested is 0.88Mb (374 features), its upload works in RStudio, not in DM. I've tried to upload the shapefile with reduced nb of features and increasing to see if it was working (clearly the shapefile uploader works), see below:

  • 1f (feature): 0.0025Mb --> upload OK
  • 10f: 0.007Mb --> upload OK
  • 25f: 0.076Mb --> upload OK
  • 50f: 0.14Mb --> upload OK
  • 100f: 0.294Mb --> upload OK
  • 150f: 0.354Mb --> upload OK
  • 200f: 0.459Mb --> upload OK
  • 220f: 0.5219Mb --> upload OK
  • 250f: 0.59Mb --> upload OK
  • 300f: 0.76Mb --> upload OK
  • 310f: 0.785Mb --> upload OK
  • 315f: 0.793Mb --> upload OK
  • 320f: 0.837Mb --> upload OK
  • 325f: 0.8599Mb --> upload OK
  • 326f: 0.8659Mb --> upload OK
  • 327f: GET STUCK
  • 330f: GET STUCK
  • 340f: GET STUCK
  • 350f: GET STUCK
  • complete file: GET STUCK

#30 Updated by Emmanuel Blondel over 2 years ago

  • Assignee changed from Gianpaolo Coro to Andrea Dell'Amico

Some more comments:
* curl_version() and curl_options() are identical.
* I've also performed tests on some features (e.g. feature 327 here above) to exclude problems of content.

I'm reassigning this to @andrea.dellamico@isti.cnr.it, he's probably the right person to cross-check server stuff. At this stage, i've no more ideas where to look at... :-|

Andrea, as summary:
* I have an R script that takes a zipped shapefile and uploads it to Geoserver data dir using the Geoserver REST API (i've been running tests on https://geoserver1-spatial-dev.d4science.org/geoserver/web/)
* This script sequently uploads 2 shapefiles. the firs one is 129.5 Kb (it works), the second one is 1.2Mb (it doesn't work)
* I've isolated the upload logic and performed more upload tests through DM (same in Rstudio), with different files. With the file size increasing (the only pattern i've identified), it get stuck in DM (while it works on RStudio)
* of course, i've performed DM & RStudio pointing to the same Geoserver (see above url)

Thank you so much in advance if you could help us solving this nasty issue

#31 Updated by Andrea Dell'Amico over 2 years ago

One first comment, before investigating the logs: the only nginx reverse proxy involved is the one running on the geoserver. As the uploads from rstudio work, it cannot be the problem. And all our configuration have a much bigger limit for uploads anyway.

#32 Updated by Andrea Dell'Amico over 2 years ago

@emmanuel.blondel@fao.org I need a new test from the dataminer. From the logs I see that an exception occurs on the geoserver, but tomcat was restarted half an our ago and the old logs deleted. I only have the nginx logs, where the last failed upload from a dataminer is at 12:36. From the nginx logs on geoserver1-spatial-dev.d4science.org:

146.48.122.28 - admin [04/Jul/2017:11:32:20 +0200] "PUT /geoserver/rest/workspaces/staging/datastores/staging_shapefiles/file.shp?configure=none&update=overwrite HTTP/1.1" 201 0 "-" "geosapi-0.2.0"
146.48.122.28 - admin [04/Jul/2017:11:34:39 +0200] "PUT /geoserver/rest/workspaces/staging/datastores/staging_shapefiles/file.shp?configure=none&update=overwrite HTTP/1.1" 201 0 "-" "geosapi-0.2.0"
146.48.122.28 - admin [04/Jul/2017:11:52:06 +0200] "PUT /geoserver/rest/workspaces/staging/datastores/staging_shapefiles/file.shp?configure=none&update=overwrite HTTP/1.1" 201 0 "-" "geosapi-0.2.0"
146.48.122.28 - admin [04/Jul/2017:12:12:10 +0200] "PUT /geoserver/rest/workspaces/staging/datastores/staging_shapefiles/file.shp?configure=none&update=overwrite HTTP/1.1" 500 87 "-" "geosapi-0.2.0"
146.48.122.28 - admin [04/Jul/2017:12:36:52 +0200] "PUT /geoserver/rest/workspaces/staging/datastores/staging_shapefiles/file.shp?configure=none&update=overwrite HTTP/1.1" 500 87 "-" "geosapi-0.2.0"

The last entry should correspond to this one on the dataminer logs:

analysis/Analysis.log:[geosapi][INFO] Uploading SHP data in datastore 'staging_shapefiles' (workspace 'staging')
analysis/Analysis.log:-> PUT /geoserver/rest/workspaces/staging/datastores/staging_shapefiles/file.shp?configure=none&update=overwrite HTTP/1.1
analysis/Analysis.log:04/07/2017 12:37:03 DEBUG Thread-18 AnalysisLogger - Dataspace->Properties of the folder: {computation_id=AAPS_STAGING_PUBLISHER_ID_58d4abe4-2691-41d7-8ea1-2da53615aeb0, VRE=/d4science.research-infrastructures.eu/gCubeApps/RPrototypingLab, operator_name=AAPS_STAGING_PUBLISHER, operator_id=org.gcube.dataanalysis.wps.statisticalmanager.synchserver.mappedclasses.transducerers.AAPS_STAGING_PUBLISHER, operator_description=AAPS Farms & Cages CLS Shapefiles publisher to staging workspace, start_date=04/07/2017 12:36:49, end_date=04/07/2017 12:36:53, status=completed, execution_platform=LOCAL, input3_farms=http://data.d4science.org/R0dLNkVLMmVhaGU2MUQ4SlcwU2RLWjRsRE4xdDFaTW5HbWJQNStIS0N6Yz0, input5_cages=http://data.d4science.org/eHoxbUpDYlREVTI2MUQ4SlcwU2RLVVA5MHZwMEN3OUlHbWJQNStIS0N6Yz0, input1_country=Greece, input6_scope=/d4science.research-infrastructures.eu/gCubeApps/RPrototypingLab, input7_user.name=emmanuel.blondel, input8_usertoken=1ff80498-9a0f-4f1b-936a-498bc857c507-843339462, output1_LogFile=http://data.d4science.org/UC9KU3lRY0d2aVc2MUQ4SlcwU2RLYnMxenc0Z1JGanZHbWJQNStIS0N6Yz0, output2_outputFile=http://data.d4science.org/OHA3R2ZiZm1ZOSs2MUQ4SlcwU2RLU3h3UlB4MlFHWlBHbWJQNStIS0N6Yz0}

Where it has been marked as complete.

Since there are no useful logs from the geoserver's tomcat instance, I cannot say anything about the exception on the geoserver's side.

#33 Updated by Emmanuel Blondel over 2 years ago

I'm going to perform the original test, where the data miner computation get stuck at 10%. I let you know when triggered.

#34 Updated by Emmanuel Blondel over 2 years ago

@andrea.dellamico@isti.cnr.it at now i can't run tests again, the geoserver is not responding.

-> GET /geoserver/rest/ HTTP/1.1
-> Host: geoserver1-spatial-dev.d4science.org
-> Accept-Encoding: gzip, deflate
-> Accept: application/json, text/xml, application/xml, /
-> User-Agent: geosapi-0.2.0
-> Authorization: Basic YWRtaW46Z2Vvc2VydmVy
->
<- HTTP/1.1 500 Internal Server Error
<- Server: nginx
<- Date: Tue, 04 Jul 2017 15:05:50 GMT
<- Content-Type: text/html;charset=utf-8
<- Content-Length: 1105
<- Connection: keep-alive
<- Content-Language: en
<-

#35 Updated by Emmanuel Blondel over 2 years ago

Geoserver seems back now, but it doesn't point anymore to the right data directory. I get the default data directory... with demo namespaces/datastores/layers

#36 Updated by Andrea Dell'Amico over 2 years ago

Emmanuel Blondel wrote:

Geoserver seems back now, but it doesn't point anymore to the right data directory. I get the default data directory... with demo namespaces/datastores/layers

I fixed that, but it seems that there's a configuration test on that server. I'll let you know

#37 Updated by Fabio Sinibaldi over 2 years ago

Sorry, I didn't notice you are using geoserver1-spatial-dev.d4science.org.
As stated for other cases, this is a bad choice. Again, we are currently using it to test configurations and security, and the installation changes frequently. This is the infrastructure development environment, not suited to develop on top of infrastructure facilities.
As you stated, "i'm asked to develop in RPrototypingLab". This means you are expected to use resources assigned to that particular context, not resources from other ones and especially not from a development environment, which are needed by us in order to develop and test what we have to deliver to you.

#38 Updated by Emmanuel Blondel over 2 years ago

Of course this is a parentesis to the DM problem...
(
Fabio, i'm TESTING, so i'm using this instance because i requested for AAPS for that purpose. I can fish out the ticket where i've requested this instance if you want... and here it is #5880! Please stop arguing about best practices in software development and tests, i'm well aware of all of that and i practice them daily in FAO SDI through DEV/QA/PROD flows. In the meantime, i've been using this instance in particular because CLS is doing exploitation tests using the AAPS production geoserver, where i've uploaded the layers successfully (through RStudio of course, not Dataminer), and what is a problem in DM cannot be a blocker for downstream layer exploitation activities on CLS side.

If this dev instance i requested month ago for AAPS and that i'm using now has been dedicated to other tasks on your side, then I can understand but please provide a test instance for AAPS, with geoserver (same version) & access to data directory. Thanks
)

#39 Updated by Emmanuel Blondel over 2 years ago

@andrea.dellamico@isti.cnr.it in order to move forward with tests, i've pointed the DM process to http://geoserver-aquacultureatlas.d4science.org/geoserver/ where i've created a new workspace (staging_test) and datastore (staging_shapefiles_test). I've just run the DM algorithm as it should run, ie upload "grc_farms" shapefile, and then upload "grc_cages" shapefile. The first was uploaded (you can check on data directory), the second is not uploaded. Process is stuck at 10%. I hope you can find something meaningful from the logs with that.. Before i've run it with DM, i tried it again from RStudio (you may find it in the logs), everything worked fine. Thanks a lot in advance

#40 Updated by Emmanuel Blondel over 2 years ago

I've just received this from DM (with no logs): The computation 084d9e2e-b120-44fe-92cd-fefbedd1cdb6 of Aaps Staging Publisher has failed. Computation Failed!

#41 Updated by Fabio Sinibaldi over 2 years ago

I'm not talking about best practices, those are far away from how we let you use the resources. I'm talking about the fact that that resource is being used by other tasks, thus it's not usable to develop algorithms (and actually the time we spend in order to debug issues due to a misuse of the infrastructure is time lost in developing what we need to deliver).

The fact that you are "TESTING" is meaningless from this point of view, because I don't think you would pick a development version of RStudio to test your scripts as well as a not released JDK or tomcat. You use released stable (hopefully) software to rely on, and the same goes for our frameworks and resources. We make exceptions where needed, obvioulsy.
The ticket you linked was to have a test machine for a new kind of installation involving spatialite, but after that task has been completed (we developed a provisioning rule for that particular case and provided a production node with those characteristics), that machine is not for you to use anymore.
I sincerely hope we don't need to destroy it / change its name / enforce firewall rules in order to stop you from using it.

You have a dedicated production instance with spatialite. If it is not enough, you can ask for another dedicated instance. In case you don't receive it (it's not up to me to decide how many resources give to your case) you have to work with the one already provided. On the other hand, if you get this dedicated resource for your tests, it needs to be in production.

#42 Updated by Andrea Dell'Amico over 2 years ago

Emmanuel Blondel wrote:

in order to move forward with tests, i've pointed the DM process to http://geoserver-aquacultureatlas.d4science.org/geoserver/ where i've created a new workspace (staging_test) and datastore (staging_shapefiles_test). I've just run the DM algorithm as it should run, ie upload "grc_farms" shapefile, and then upload "grc_cages" shapefile. The first was uploaded (you can check on data directory), the second is not uploaded. Process is stuck at 10%. I hope you can find something meaningful from the logs with that.. Before i've run it with DM, i tried it again from RStudio (you may find it in the logs), everything worked fine. Thanks a lot in advance

The only piece of information that I can obtain from the tomcat logs is that it's the geoserver that's failing. But I don't know why, because it does not log anything. I've only found the error 500 in the access log:

[04/Jul/2017:19:01:18 +0200] "PUT /geoserver/rest/workspaces/staging_test/datastores/staging_shapefiles_test/file.shp?configure=none&update=overwrite HTTP/1.1" 500 136 "-" "geosapi-0.2.0"

And the corresponding nginx entry:

146.48.122.241 - admin [04/Jul/2017:19:01:18 +0200] "PUT /geoserver/rest/workspaces/staging_test/datastores/staging_shapefiles_test/file.shp?configure=none&update=overwrite HTTP/1.1" 500 136 "-" "geosapi-0.2.0"

#43 Updated by Emmanuel Blondel over 2 years ago

I think you looked to older logs, not targeting the issue (sorry when i've created the new workspace/datastore, i did a small error with the naming, and this is at the time you point out ~ 19:01).

Around 20:32, i've launched another test through DM:

From Geoserver, when an upload is sucessful I get this:

2017-07-04 20:32:58,354 DEBUG [org.geoserver] - Thread 55 locking in mode WRITE
2017-07-04 20:32:58,354 DEBUG [org.geoserver] - Thread 55 got the lock in mode WRITE
2017-07-04 20:32:58,354 INFO [org.geoserver.catalog.rest] - PUT file, mimetype: application/zip
2017-07-04 20:32:58,370 INFO [org.geoserver.catalog.rest] - Using existing datastore: staging_shapefiles_test
2017-07-04 20:32:58,373 DEBUG [org.geoserver.catalog.rest] - Removing existing features from grc_farms
2017-07-04 20:32:58,376 DEBUG [org.geoserver.catalog.rest] - Adding features to grc_farms
2017-07-04 20:32:58,403 DEBUG [org.geoserver] - Thread 55 locking in mode WRITE
2017-07-04 20:32:58,403 DEBUG [org.geoserver] - Thread 55 releasing the lock in mode WRITE

Indeed it works for grc_farms. For grc_cages, at the time i write it's 20:56, DM is still stuck at 10%, and there is no log in Geoserver with ref to org.geoserver.catalog.rest nor with the REST path /rest/workspaces/staging_test/datastores/staging_shapefiles_test/file.shp (that should appear if the request was sent to geoserver) The more recent reference to the latter is around 20:32:58 for grc_farms (before the log i pasted above), which means that the request has not been sent at all to Geoserver...

#44 Updated by Emmanuel Blondel over 2 years ago

21:38, and still nothing in Geoserver logs concerning the 2d file upload. DM process stuck at 10%

#45 Updated by Emmanuel Blondel over 2 years ago

@andrea.dellamico@isti.cnr.it at this datetime 2017-07-05T10:15:00 still nothing received on Geoserver logs for the second data to upload. DM process still at 10%...

#46 Updated by Pasquale Pagano over 2 years ago

From what I read in this thread, it seems that the issue is on DM and not on the GS. Please @scarponi@isti.cnr.it look at the logs of DM in RPrototypingLab and let us know asap.

#47 Updated by Andrea Dell'Amico over 2 years ago

Again, from the nginx logs on the geoserver. If I understand correctly, this one is a successful operation from rstudio:

146.48.122.190 - - [04/Jul/2017:19:03:08 +0200] "GET /geoserver/rest/web HTTP/1.1" 401 1079 "-" "libcurl/7.35.0 r-curl/2.7 httr/1.2.1"
146.48.122.190 - admin [04/Jul/2017:19:03:09 +0200] "GET /geoserver/rest/rest/about/version.xml HTTP/1.1" 200 407 "-" "geosapi-0.2.0"
146.48.122.190 - - [04/Jul/2017:19:03:09 +0200] "GET /geoserver/rest/web HTTP/1.1" 401 1079 "-" "libcurl/7.35.0 r-curl/2.7 httr/1.2.1"
146.48.122.190 - admin [04/Jul/2017:19:03:09 +0200] "GET /geoserver/rest/rest/about/version.xml HTTP/1.1" 200 407 "-" "geosapi-0.2.0"
146.48.122.190 - - [04/Jul/2017:19:03:09 +0200] "GET /geoserver/rest/web HTTP/1.1" 401 1079 "-" "libcurl/7.35.0 r-curl/2.7 httr/1.2.1"
146.48.122.190 - admin [04/Jul/2017:19:03:09 +0200] "GET /geoserver/rest/rest/about/version.xml HTTP/1.1" 200 407 "-" "geosapi-0.2.0"
146.48.122.190 - - [04/Jul/2017:19:03:09 +0200] "GET /geoserver/rest/web HTTP/1.1" 401 1079 "-" "libcurl/7.35.0 r-curl/2.7 httr/1.2.1"
146.48.122.190 - admin [04/Jul/2017:19:03:09 +0200] "GET /geoserver/rest/rest/about/version.xml HTTP/1.1" 200 407 "-" "geosapi-0.2.0"
146.48.122.190 - - [04/Jul/2017:19:03:09 +0200] "GET /geoserver/web HTTP/1.1" 302 0 "-" "libcurl/7.35.0 r-curl/2.7 httr/1.2.1"


146.48.122.190 - admin [04/Jul/2017:19:03:10 +0200] "PUT /geoserver/rest/workspaces/staging_test/datastores/staging_shapefiles_test/file.shp?configure=none&update=overwrite HTTP/1.1" 201 0 "-" "geosapi-0.2.0"
146.48.122.190 - admin [04/Jul/2017:19:03:10 +0200] "GET /geoserver/rest/layers/grc_farms.xml HTTP/1.1" 200 373 "-" "geosapi-0.2.0"
146.48.122.190 - admin [04/Jul/2017:19:03:17 +0200] "PUT /geoserver/rest/workspaces/staging_test/datastores/staging_shapefiles_test/file.shp?configure=none&update=overwrite HTTP/1.1" 201 0 "-" "geosapi-0.2.0"
146.48.122.190 - admin [04/Jul/2017:19:03:17 +0200] "GET /geoserver/rest/layers/grc_cages.xml HTTP/1.1" 200 373 "-" "geosapi-0.2.0"
146.48.122.190 - admin [04/Jul/2017:19:03:17 +0200] "POST /geoserver/rest/reload HTTP/1.1" 200 0 "-" "geosapi-0.2.0"

It succeeds in less than 10 seconds.

The following one should be your request from the dataminer:

146.48.122.28 - admin [04/Jul/2017:20:32:57 +0200] "GET /geoserver/rest/ HTTP/1.1" 200 400 "-" "geosapi-0.2.0"
146.48.122.28 - - [04/Jul/2017:20:32:57 +0200] "GET /geoserver/rest/web HTTP/1.1" 401 1079 "-" "libcurl/7.35.0 r-curl/2.7 httr/1.2.1"
146.48.122.28 - admin [04/Jul/2017:20:32:57 +0200] "GET /geoserver/rest/rest/about/version.xml HTTP/1.1" 200 407 "-" "geosapi-0.2.0"
146.48.122.28 - - [04/Jul/2017:20:32:57 +0200] "GET /geoserver/rest/web HTTP/1.1" 401 1079 "-" "libcurl/7.35.0 r-curl/2.7 httr/1.2.1"
146.48.122.28 - admin [04/Jul/2017:20:32:57 +0200] "GET /geoserver/rest/rest/about/version.xml HTTP/1.1" 200 407 "-" "geosapi-0.2.0"
146.48.122.28 - - [04/Jul/2017:20:32:57 +0200] "GET /geoserver/rest/web HTTP/1.1" 401 1079 "-" "libcurl/7.35.0 r-curl/2.7 httr/1.2.1"
146.48.122.28 - admin [04/Jul/2017:20:32:57 +0200] "GET /geoserver/rest/rest/about/version.xml HTTP/1.1" 200 407 "-" "geosapi-0.2.0"
146.48.122.28 - - [04/Jul/2017:20:32:57 +0200] "GET /geoserver/rest/web HTTP/1.1" 401 1079 "-" "libcurl/7.35.0 r-curl/2.7 httr/1.2.1"
146.48.122.28 - admin [04/Jul/2017:20:32:57 +0200] "GET /geoserver/rest/rest/about/version.xml HTTP/1.1" 200 407 "-" "geosapi-0.2.0"
146.48.122.28 - - [04/Jul/2017:20:32:57 +0200] "GET /geoserver/web HTTP/1.1" 302 0 "-" "libcurl/7.35.0 r-curl/2.7 httr/1.2.1"
146.48.122.28 - admin [04/Jul/2017:20:32:58 +0200] "PUT /geoserver/rest/workspaces/staging_test/datastores/staging_shapefiles_test/file.shp?configure=none&update=overwrite HTTP/1.1" 201 0 "-" "geosapi-0.2.0"
146.48.122.28 - admin [04/Jul/2017:20:32:58 +0200] "GET /geoserver/rest/layers/grc_farms.xml HTTP/1.1" 200 373 "-" "geosapi-0.2.0"
146.48.122.28 - admin [04/Jul/2017:20:34:03 +0200] "PUT /geoserver/rest/workspaces/staging_test/datastores/staging_shapefiles_test/file.shp?configure=none&update=overwrite HTTP/1.1" 408 0 "-" "geosapi-0.2.0"

There isn't any request toto grc_cages.xml, and I guess the reason is that the PUT /geoserver/rest/workspaces/staging_test/datastores/staging_shapefiles_test/file.shp?configure=none&update=overwriteaction fails with 408 (request timeout).
All the requests that come from the dataminers fail in the same way, mostly (there's also some 500 but maybe it's another problem?)

The Tomcat counterpart:

127.0.0.1 - - [04/Jul/2017:20:32:57 +0200] "GET /geoserver/rest/ HTTP/1.1" 200 400 "-" "geosapi-0.2.0"
127.0.0.1 - - [04/Jul/2017:20:32:57 +0200] "GET /geoserver/rest/web HTTP/1.1" 401 1079 "-" "libcurl/7.35.0 r-curl/2.7 httr/1.2.1"
127.0.0.1 - - [04/Jul/2017:20:32:57 +0200] "GET /geoserver/rest/rest/about/version.xml HTTP/1.1" 200 407 "-" "geosapi-0.2.0"
127.0.0.1 - - [04/Jul/2017:20:32:57 +0200] "GET /geoserver/rest/web HTTP/1.1" 401 1079 "-" "libcurl/7.35.0 r-curl/2.7 httr/1.2.1"
127.0.0.1 - - [04/Jul/2017:20:32:57 +0200] "GET /geoserver/rest/rest/about/version.xml HTTP/1.1" 200 407 "-" "geosapi-0.2.0"
127.0.0.1 - - [04/Jul/2017:20:32:57 +0200] "GET /geoserver/rest/web HTTP/1.1" 401 1079 "-" "libcurl/7.35.0 r-curl/2.7 httr/1.2.1"
127.0.0.1 - - [04/Jul/2017:20:32:57 +0200] "GET /geoserver/rest/rest/about/version.xml HTTP/1.1" 200 407 "-" "geosapi-0.2.0"
127.0.0.1 - - [04/Jul/2017:20:32:57 +0200] "GET /geoserver/rest/web HTTP/1.1" 401 1079 "-" "libcurl/7.35.0 r-curl/2.7 httr/1.2.1"
127.0.0.1 - - [04/Jul/2017:20:32:57 +0200] "GET /geoserver/rest/rest/about/version.xml HTTP/1.1" 200 407 "-" "geosapi-0.2.0"
127.0.0.1 - - [04/Jul/2017:20:32:57 +0200] "GET /geoserver/web HTTP/1.1" 302 - "-" "libcurl/7.35.0 r-curl/2.7 httr/1.2.1"
127.0.0.1 - - [04/Jul/2017:20:32:57 +0200] "GET /geoserver/web/;jsessionid=1CFC6001949802C41AACE981F543F001 HTTP/1.1" 200 2243 "-" "libcurl/7.35.0 r-curl/2.7 httr/1.2.1"
127.0.0.1 - - [04/Jul/2017:20:32:58 +0200] "PUT /geoserver/rest/workspaces/staging_test/datastores/staging_shapefiles_test/file.shp?configure=none&update=overwrite HTTP/1.1" 201 - "-" "geosapi-0.2.0"
127.0.0.1 - - [04/Jul/2017:20:32:58 +0200] "GET /geoserver/rest/layers/grc_farms.xml HTTP/1.1" 200 373 "-" "geosapi-0.2.0"

As you can see, the 20:34 request has not been logged by the geoserver. The geoserver does not log anything other that the accesses, so I can't know what's happening.
This, and the dataminer (or the algorithm?) cannot cope with the 408 return code so it waits indefinitely.

#48 Updated by Emmanuel Blondel over 2 years ago

Thanks Andrea, a quick comment on the logs: do not pay attention at logs earlier (19:03). As commented above, prior to do the testing with DataMiner, i've retested with RStudio, and there it works. Nginx side, you will get same kind of logs but successful. The one you looked at is the one when i've run it from RStudio, the reason why you see it worked for grc_cages as well.

At 20:32, i've run exactly the same process but from DM. The first one was successfully uploaded, the second nothing.

About "(there's also some 500 but maybe it's another problem?)":
From Dataminer yesterday, i got error status 500 when the Geoserver was down (the dev instance, when i was using it), so you can exclude this case.

For some unknown reason Dataminer doesn't send files to geoserver and get stuck, and one assumption i made through my tests above is that it is linked to the file size. Indeed, small files are correctly uploaded, and above a given filesize threshold, it gets stuck. Let me know if you find something useful in DataMiner.

#49 Updated by Andrea Dell'Amico over 2 years ago

Emmanuel Blondel wrote:

Thanks Andrea, a quick comment on the logs: do not pay attention at logs earlier (19:03). As commented above, prior to do the testing with DataMiner, i've retested with RStudio, and there it works. Nginx side, you will get same kind of logs but successful. The one you looked at is the one when i've run it from RStudio, the reason why you see it worked for grc_cages as well.

Yes indeed, I posted them so that we can compare them to the ones from the dataminer

At 20:32, i've run exactly the same process but from DM. The first one was successfully uploaded, the second nothing.

And that's what the second and third log snippets show.

About "(there's also some 500 but maybe it's another problem?)":
From Dataminer yesterday, i got error status 500 when the Geoserver was down (the dev instance, when i was using it), so you can exclude this case.

Hm. Those logs are from geoserver-aquacultureatlas.d4science.org. But maybe it's the mistake you write about in #9043#note-43.

For some unknown reason Dataminer doesn't send files to geoserver and get stuck, and one assumption i made through my tests above is that it is linked to the file size. Indeed, small files are correctly uploaded, and above a given filesize threshold, it gets stuck. Let me know if you find something useful in DataMiner.

Possibly, but there's the 408 error code that's puzzling. And it comes from the geoserver (the logs I posted are all from geoserver-aquacultureatlas.d4science.org)

I'm attaching the dataminer's log produced by the 20.32 computation, but @scarponi@isti.cnr.it is better suited to analyze the dataminer's behaviour.

#50 Updated by Paolo Scarponi over 2 years ago

Emmanuel, could you please provide me with the equivalent http request to launch your process so that I can launch it and check the logs while it is running.

#51 Updated by Emmanuel Blondel over 2 years ago

To make the error more meaningful at R level, i've added the explicit http status message in case of error: see https://github.com/eblondel/geosapi/commit/b76ad709b209e92f58a6135d1fd98bd0b19f305c You may want to reinstall geosapi from Github to get this.

@scarponi@isti.cnr.it The integration test that you can run is similar to the cURL call given at http://docs.geoserver.org/2.10.x/en/user/rest/examples/curl.html#uploading-a-shapefile

As R code, better, if you have access to one of the R running DM instance. This code below is one i've tried through DM the last days, and it fails.


require(geosapi)

#geoserver config
AAPS_GS <- GSManager$new(
  url = "https://geoserver-aquacultureatlas.d4science.org/geoserver",
  user = "admin",
  pwd = "********",
  logger = "DEBUG"
)

productType <- "cage"
fileToDownload <- "http://data.d4science.org/eVJJNWJ5anNKN1pSLzcybU4zRmJoUG5TVUgrT0JNZ0xHbWJQNStIS0N6Yz0"
myfile <- paste0(productType, ".zip")
download.file(url = fileToDownload, destfile = myfile)
cat(sprintf("File size: %s Mb\n", file.size(myfile)/1e6))
cat("Try upload the file to Geoserver \n")
out <- AAPS_GS$uploadShapefile("staging_test", "staging_shapefiles_test", endpoint = "file", configure = "none", update = "overwrite", myfile, "UTF-8")

Note i've just run these few lines from RStudio, you should receive some entry in the server around 12:35

Let me know if it helps

#52 Updated by Emmanuel Blondel over 2 years ago

Sorry i've slightly edited the R code above. I send you the geoserver password by email.

#53 Updated by Paolo Scarponi over 2 years ago

Sorry Emmanuel but I meant the equivalent HTTP request for the dataminer process, if you run once your process from the interface you can retrieve it from there.

#55 Updated by Emmanuel Blondel over 2 years ago

  • Related to Support #9242: Need of 2 user accounts in Geonetwork for AAPS and PAIM added

#56 Updated by Emmanuel Blondel over 2 years ago

  • Status changed from Feedback to In Progress

#57 Updated by Emmanuel Blondel over 2 years ago

@scarponi@isti.cnr.it i cannot change the priority of the ticket, but consider it as maximal. THanks in advance to report when you have news about its fixing.

#58 Updated by Paolo Scarponi over 2 years ago

Emmanuel could you please share your project with me so that I can try to debug it?

#59 Updated by Emmanuel Blondel over 2 years ago

There is nothing to debug in the algorithm logic it's working, otherwise i could not have published the outputs in staging through RStudio. You now have write access to it. It's under VRE Folders > AquacultureAtlasGeneration > Processes > AAPS_Staging_publisher. However, Instead of dealing with the complete algorithm, again I suggest you to pick up the piece of code that fails under Dataminer and that i've isolated for your convenience. I've pasted a reproducible test here: #9043#note-51 and that i repaste here below. It will show that DM client machine is failing in sending properly data Geoserver, with error status code 408 (while on RStudio client machine it works).


require(geosapi)

#geoserver config
AAPS_GS <- GSManager$new(
  url = "https://geoserver-aquacultureatlas.d4science.org/geoserver",
  user = "admin",
  pwd = "********",
  logger = "DEBUG"
)

productType <- "cage"
fileToDownload <- "http://data.d4science.org/eVJJNWJ5anNKN1pSLzcybU4zRmJoUG5TVUgrT0JNZ0xHbWJQNStIS0N6Yz0"
myfile <- paste0(productType, ".zip")
download.file(url = fileToDownload, destfile = myfile)
cat(sprintf("File size: %s Mb\n", file.size(myfile)/1e6))
cat("Try upload the file to Geoserver \n")
out <- AAPS_GS$uploadShapefile("staging_test", "staging_shapefiles_test", endpoint = "file", configure = "none", update = "overwrite", myfile, "UTF-8")

#60 Updated by Gianpaolo Coro over 2 years ago

Hi Emmanuel, I have inspected the issue and I think it is in your "geosapi" library. I guess the error could be in the fact that you provide "local" files instead of absolute paths to the 'httr' functions or perhaps there are some variables that get lost. I say "could", because I could not alter your package thus I proceeded in the following way:

1 - imported your functions for the PUT on GeoServer in the SAI code
2 - added some logs in these functions
3 - provided the absolute file path of the zip file to the PUT function
4 - changed the PUT authentication function call

It works (for farms and cages both separately and together). You find my functions in the "REWRITING OF GEOSAPI FUNCTIONS" section at the beginning of the SAI code. You might want to report these in your 'geosapi' package and retry.

#61 Updated by Emmanuel Blondel over 2 years ago

I will look to it. The behavior of geosapi is fine, it aligns with the GeoServer REST API. The only place where it didn't work is DM with "big" (>0.8 Mb) files
How do you explain then:
* that it always works fine from RStudio (the RPrototypingLab one)
* it always work in DM for small files (e.g. grc_farms), and not for bigger (e.g. grc_cages).

Again, this is very weird. In R, we don't have to provide absolute paths, this is the meaning of "wd" working directory and the reason we set it. Ff my working directory is correctly set (which is the case since it works for grc_farms), then we should be able to work with relative paths. If absolute paths does the trick, it's a "patch" i will consider (but only in the algorithm), but it still doesn't explain why DM acts differently.

#62 Updated by Emmanuel Blondel over 2 years ago

@gianpaolo.coro@isti.cnr.it I've extended the debugging a bit more, taking the lines of codes you dropped there. I've tested the following:
* applying the normalizePath to filename, it had no effect. The code got stuck
* i've tried to apply separately the httr:PUT call (both yours and geosapi, the diff with geosapi one is that we provide authenticate together with other headers). Both works, so it's not a problem of configuration of httr:PUT

Then i've realized that in your testing code you deactivated the capacity to execute http calls with verbose. And amazingly.. here is the problem :-| If I encapsulate my httr httr:PUT call with the facility with_verbose also provided by httr (https://rdrr.io/cran/httr/man/verbose.html), which is the case when i request geosapi to give verbose httr logs (typically to print all curl requests sent and received data), it get stuck. If I reduce the level of logs ("INFO" or NULL), it works...
Any idea why this httr::with_verbose would break on DM?

#63 Updated by Gianpaolo Coro over 2 years ago

I don't know, I just skipped it because it was unnecessary...so natural I did not even noticed that.

That command reports information about the flow between the client and server but I don't think there are security issues. Perhaps there is a mixture of packages that causes conflicts between logs levels (why not using simple 'cat', anyway?) and verbose, since the installed R environment is very large.

#64 Updated by Emmanuel Blondel over 2 years ago

  • Assignee changed from Paolo Scarponi to Emmanuel Blondel
  • Status changed from In Progress to Closed

Logs of http calls are unecessary? :-) ok... At least it is required for config at package level for the users that wants to debug, it's a minimum to provide for libraries dealing with REST API. Cat statements are already provided in both loggers (INFO, DEBUG) + the algorithm, but this is not enough for full debugging. QA requirement. BTW with_verbose is commonly used for http calls made with httr package (especially when you send data).

I suppose the reason why wrapping httr calls in it make DM stuck will remain a mistery (at least for now), sounds like DM doesn't like when we want to handle too much debug-level logs. IMHO i believe that CNR should look into that, because the issue is probably not httr (DM is the only place where it doesn't work..), and it might be a nasty issue behind that might have adverse impacts on other stuff.

For my part I close this ticket since I finally found the weird way to bypass this DM issue. Thanks anyway for taking some of your time today to look in the script

Also available in: Atom PDF