- Feb 19, 2019
-
-
Vincenzo Forchì authored
-
- Jan 28, 2019
-
-
Grégory Mantelet authored
UWSToolBox). _ See GitHub Issue #100 _
-
- Oct 22, 2018
-
-
Grégory Mantelet authored
file (actually, replaces the real backup file by the temporary one). Sometimes a temporary backup file (i.e. a file named like `*.backup.temp-*`) is not deleted. This means that the log rotation fails and that, potentially, some jobs have not been updated/deleted. This commit is there is re-enforce the replacement operation.
-
- Sep 21, 2018
-
-
Marc DeXeT authored
-
- Sep 19, 2018
-
-
marcdexet-cnrs authored
-
- Sep 14, 2018
-
-
marcdexet-cnrs authored
-
- Sep 05, 2018
-
-
Grégory Mantelet authored
The property `upload_default_db_limit` has been deprecated. Indeed, in the current state of the TAP protocol, this makes no sense: the user can not change the limit size (in bytes or rows) for uploaded tables. The property `upload_max_file_size` has been deprecated. It is actually duplicated: `upload_max_db_limit`, if expressed in bytes already lets put a limit on the maximum size of an uploaded table/file. The property `upload_max_request_size` has been added. It lets set a maximum size for a whole HTTP Multipart Request. By default it is set to 250MB. The default value of `upload_max_db_size` is now 1 million rows. The UPLOAD feature is still disabled by default (i.e. `upload_enabled=false`).
-
Grégory Mantelet authored
This bug occurred "just" due to an un-desired inverted test, since UWS-1.1 is implemented (UWSLib-4.3 and TAPLib-2.2).
-
- Aug 21, 2018
-
-
Grégory Mantelet authored
Thus, the UPLOAD management is much more stable and relies on a well documented and maintained library (but at the cost of the additionnal size of the final JAR). The most important point is the capability to efficiently limit the size of the incoming file and on the disk/memory management when uploading the file(s) and in case of error during this process (i.e. files must be deleted).
-
Grégory Mantelet authored
attribute. In this way, it is possible to run two different instances of a UWS/TAP service with a different temporary directory in the same JVM.
-
- Aug 20, 2018
-
-
Grégory Mantelet authored
The attribute `version` in the node `job` is never restored ; it is just informative. Thus, it is now silently ignored. The attribute `length` of an upload was badly spelled. The attribute `mime-type` of a result was backuped as `mime-type` but restored as `mime`. Hence the absence of this piece of information when restoring a job.
-
Grégory Mantelet authored
_This latter will soon be removed from UWSLib._
-
- Aug 10, 2018
-
-
Grégory Mantelet authored
-
- Aug 07, 2018
-
-
Grégory Mantelet authored
(possibly NULL) was used instead of the class variable (which is NEVER NULL).
-
Grégory Mantelet authored
passed by reference.
-
Grégory Mantelet authored
Then, UWS or TAP implementors are free to use whatever logging system they want (e.g. log4j, logback, ...).
-
- Jul 30, 2018
-
-
Grégory Mantelet authored
This error occurred generally during the backup process while trying to backup the job list of a specific user. If several of his jobs were running and changing state during the backup process, this ConcurrentModificationException was thrown. This generally happens when the same user submits a lot of shorts jobs in the same time. This exception was due to a non thread-safe usage of UWSParameters.additionalParams. To fix this issue, instead of creating it as a normal HashMap, it is now created as a ConcurrentHashMap. The same modification has also been applied to UWSParameters.params. In addition of the replacement of HashMap into ConcurrentHashMap, all `synchronized` blocks have been removed....there should not be needed any more.
-
- Jul 27, 2018
-
-
Grégory Mantelet authored
When enabled, it was generating a file each minute on the day before the specified day of week. For instance: if the log rotation frequency was `W 1 0 0` (so, weekly on Sunday at 00:00). The rotation was performed on Saturday midnight. But, because of a bad index correction, the rotation kept going on the whole day of Saturday. Since the rotated file is suffixed by the timestamp with hours and minutes (no seconds), it actually generated a new log file for each minute of the saturday. Of course, each time the file contained only one line (or 2 with some luck)...which is pretty useless.
-
- Jul 04, 2018
-
-
Grégory Mantelet authored
backup file. The previous commit was only applied on the whole backup file.
-
- Jul 02, 2018
-
-
Grégory Mantelet authored
Instead of writing the new backup content in the final backup file directly, write it first in a temporary file and then change the files name. This fix prevents incomplete backup files (particularly in case of one backup file per user) when stopping/restarting by force.
-
- May 18, 2018
-
-
Grégory Mantelet authored
When a custom key was encountered, the library tried to fetch its value as a String...but it is not always a String. Instead, now it is fetch as an Object (possibly a JSONObject or JSONArray).
-
- Mar 02, 2018
-
-
gmantele authored
-
gmantele authored
The UWS-1.x standard defines the quote as an ISO-8601 date. UWS-Lib stores it as a number of seconds (i.e. estimated job duration). This fix ensures that this integer/long quote value is returned as a date. Note: The backup and restoration processes are not affected by this change. The backup file format is still the same: a quote stored as a long value.
-
- Feb 26, 2018
-
-
gmantele authored
It is possible to choose how the blocking mechanism should behave (e.g. what the max. waiting period, how many requests can be blocked in the same time, what happen when the blocking times out, ...). Indeed, the policy to apply must actually be an extension of the interface BlockingPolicy. Already two implementations are provided in the library (LimitedBlockingPolicy and UserLimitedBlockingPolicy), but a custom policy can perfectly be created and apply to a UWS service. By default, no policy is set. In such case, the service will block the time specified by the user, which may be -1 (i.e. wait indefinitely). A BlockingPolicy can help controlling the waiting/blocking process and protect the resources of the server.
-
gmantele authored
- PHASE: list only jobs in the specified PHASE. If this parameter is repeated jobs matching any of the specified phases will be returned. - AFTER: list jobs created after the specified ISO-8601 date (included). If this parameter is repeated, only the most recent date is retained. - LAST: list the N-th most recently created jobs, ordered by descending creation time These filter parameters are additive: their constraints are joint as with an AND operator (except for PHASE parameters ; see above). If no filter is specified, all jobs EXCEPT the ARCHIVED ones are listed. The only way to list ARCHIVED jobs is to use PHASE=ARCHIVED (with or without other filter parameters). The filtering API has been made in a generic manner so that it is easily possible to create and add new filters. See the interface JobFilter and the class JobListRefined for more details.
-
gmantele authored
and ALWAYS_ARCHIVE. When archiving a job, its former phase is stored in jobInfo under the name 'oldPhase' if no jobInfo is already set. Archiving a job means that all input files and results are destroyed ; the error summary and jobInfo (even if it is a file) are kept. Each archive operation ends with a log message ; in ERROR if failed or in INFO if successful. This commit also includes the following things: - reformat on 80 characters width the Javadoc of all modified classes - fix a bug with the phase transitions: since it is not possible any more to go from PENDING to EXECUTING directly, UWSJob.start(...) must first ensure to be on QUEUED phase. This bug has also been fixed in TAPJob. Similarly, before going into ARCHIVED phase the job must be set into ABORTED phase if not already in a final phase.
-
gmantele authored
A JUnit test case has been added in order to check that all possible phase transitions are respecting the UWS-1.1 standard. However, there is anyway a bit more freedom for some of them: - it is possible to go to and come from UNKNOWN at any time, whatever is the source or target phase. - it is possible to go to ERROR or ABORTED from the phases HELD and SUSPENDED. This fact was not specified in the State Machine figure of the UWS standard but the following sentence at section "2.1.3 Execution Phase" (page 7) should allow that: "At any time before the COMPLETED phase a job may either be ABORTED or may suffer an ERROR." - the UWS-1.1 document has an inconsistency about the HELD phase. At section "2.1.3 Execution Phase" (page 7), the following sentence implies that it is only possible to go to HELD from PENDING (because it would not be possible to queue the job). And so, when PHASE=RUN is sent by the UWS client, if now possible, the job should go in phase QUEUED. However the State Machine figure suggests that it is possible to go to HELD only from EXECUTING and that a PHASE=RUN would make the job go back to EXECUTING (if now possible). Because of this inconsistency, the UWSLibrary made possible the following transitions: PENDING/EXECUTING->HELD->QUEUED/EXECUTING. (note: a figure illustrating the phase transitions supported by the UWSLibrary-4.3 has been created in the directory `img` of the UWS-Tutorial website under the file name `state_machine.png`...which of course will be visible only when uwslib-4.3 will be released) Besides, this commit also include almost a full rewriting of the Javadoc of JobPhase and ExecutionPhase. The Javadoc of UWSJob has just been reformated so that comments do not exceed 80 (+2) characters. This reformating aims to improve the human reading of the Javadoc while looking at the source files ; however this should not affect much the HTML version of the Javadoc.
-
gmantele authored
This property is displayed in the XML and JSON serialization of a job item. It is also backuped and restored from a UWS backup file. /!\ WARNING: Small modification of the API! Since creationTime must be set by the UWS service at creation of a job, this date must also be imported at backup restoration. Hence the modification of the interface uws.service.UWSFactory and its implementations (particularly tap.AbstractTAPFactory). Similarly the class uws.job.UWSJob and tap.job.TAPJob have underwent exactly the same modification in one of their constructors. This commit also adds the new optional jobRef items: creationTime, runID and ownerID in the XML and JSON serializations.
-
gmantele authored
<job>. This commit also: - set the version of the UWS protocol to 1.1 (cf UWS.VERSION) - add a static constant for the standardID (cf UWS.STANDARD_ID) - add a xlink:type and xlink:href for jobListRef in the uws XML - set the @version Javadoc attribute of all modified classes to 4.3 (scheduled version of the UWSLibrary supporting UWS-1.1)
-
gmantele authored
serialization of all results if such information are available. This commit also fix few comments about the result's XML serialization. The processing of xlink:type of a result reference is made similar as the one of jobRef.
-
- Jan 31, 2018
-
-
gmantele authored
-
- Sep 27, 2017
-
-
gmantele authored
This commit also includes the 2 following points: - for (really really tiny) optimisation purpose, replace String by a char when there is only one character to append to a StringBuffer - add a bit more details about Result.type in the Javadoc (it should be a xlink:type and not a random custom type)
-
gmantele authored
Until now, it was possible to destroy the job by posting ACTION=DELETE with a URL like below: {root-uws}/{job-list}/{job-id}/foo/bar That is completely wrong. The correct URL for this action must always be: {root-uws}/{job-list}/{job-id} This commit fixes this error in UWSServlet and UWSService.
-
gmantele authored
The configuration of the DestructionTimeController was never effective in the UWSServlet with a configuration file: the wrong instance was set.
-
gmantele authored
synchronized although the collection of observers is synchronized (Vector) ; using an Iterator ensures the synchronization and avoids concurrency problems.
-
gmantele authored
- uws.service.UWS.VERSION (static final) - tap.resource.TAP.VERSION (static final) Dealing with several protocol versions in the same time is quite difficult and may significantly alter the libraries API in an unstable way. That's why, for the TAP and UWS libraries, only one version is implemented (i.e. the last one). To use a older version of the protocol, one must use an older version of the corresponding library. About the versioning of the ADQL standard, there is no need to set any version number somewhere because a different ADQL version implies a different grammar. It means that a different parser is required for each ADQL version. For the moment, there is only one version, so no need to change anything to the ADQL library about ADQL version. Later, ADQLParser should become an interface and a factory will have to be used in order to get the parser corresponding to the desired ADQL version.
-
- Sep 15, 2017
-
-
gmantele authored
This commit resolves partially the issue #28 Ideally, there should be an implementation of UWSLog and TAPLog working with Log4j and another for SLF4J (and eventually for other logging mechanism). Additionally, an implementation storing log messages in database would be interesting. All these ideas may be implemented in UWSLib and TAPLib in a future version.
-
gmantele authored
_This commit aims to fix the issue #47_
-
- Sep 11, 2017
-
-
gmantele authored
and HashMap more generic by returning resp. a List and Map instead.
-
- Jun 19, 2017
-
-
gmantele authored
Additionally when an XML document is submitted in an HTTP POST request (i.e. with the Content-Type = (text|application)/(.+-)?xml), this is immediately set as a jobInfo in the created job.
-