Known Problems

The following is a list of problems that the OGSA-DAI team know about and which will be addressed in future. If you have any others that you feel should be added to this list then please let us know.

You may also want to consult the platform-specific FAQ and general FAQ.

• Performance:
  1. Forwarding very large amounts of data to an OGSA-DAI service or retrieving these from an OGSA-DAI service may give rise to java.lang.OutOfMemoryError errors on the OGSA-DAI server. There is a FAQ which describes possible solutions.
  2. For eXist we have found that the Web services container may run out of memory if it is hosting OGSA-DAI or other Grid middleware (e.g. Globus Toolkit) as well as eXist.
  3. Retrieving database metadata with the extractDatabaseSchema activity for DB2/Cloudscape can sometimes retrieve unrelated meta-data and also cause OGSA-DAI to crash.
  4. Retrieving database metadata for all available tables with the extractDatabaseSchema activity for Oracle causes a server-side java.lang.OutOfMemoryError.
  5. Attempting to return a very large data set in a response can cause a server-side java.lang.OutOfMemoryError. This can be avoided by submitting an asynchronous request (one that uses an outputStream) and retreiving the results using a data service's data transport operations.
  6. Queries of tables for millions of small rows can eventually cause a server-side java.lang.OutOfMemoryError even if using stream activities and data transport operations.
  7. The fileWritingActivity attempts to read the whole file in a oner and so could cause a server-side java.lang.OutOfMemoryError for very large files.
  8. Some databases, such as dBASE IV database on Microsoft Windows 2000, allow unusual characters, such as 0xC to be contained in certain field types. When field values containing this character, OGSA-DAI encodes them into invalid XML that subsequently causes Xerces-dependent components to raise an org.xml.sax.SAXParseException.
  9. Activities that have two outputs can sometimes cause java.lang.OutOfMemoryErrors to occur server-side if manipulating large amounts of data. This can arise when using the GZIP activities for example.
     • Such activities are driven by one of the two connected activities and the other activity can accumulate data without processing it. So, for example for the GZIP activities OGSA-DAI focuses on the GZIP meta-data output steam and data only flows from this stream when a file has been completely unzipped. Therefore for large files the whole contents of the file flows into the activity and is buffered without being sent on.
     • OGSA-DAI's GZIP activities will warn if memory usage is close to maximum and throw an OGSA-DAI exception server-side so that the Web services container does not crash.
• Error and exception handling:
  1. The failure of a single activity in a request will cause the status of all other activities to be set to TERMINATED, even those that are not connected and succeeded.
  2. The data transport activities can gulp exceptions. For example if an sqlQueryStatement with a incorrectly formed SQL query statement is connected to an outputStream activity then attempting to pull data from the outputStream using the data transport operations results in no data - no indication of an error is given to the client.
  3. The uk.org.ogsadai.exception.DAILogger methods can sometimes log the wrong line numbers. Searching the logs will usually reveal where the problem actually arose.
  4. If an error occurs during execution of a relational activity then server-side information may be returned to the client. This is because OGSA-DAI does not, as yet, parse java.sql.SQLExceptions from database drivers to identify problems caused as a result of a client (e.g. a syntactically-incorrect SQL query) and those due to failures server-side (e.g. the wrong password in a roleMap file or a loss of connection to the database.
• Security:
  1. There is no mechanism to provide authorisation control for data transport streams. Thus anybody who is authorised to access the service and data service resource and is able to guess the name of your data stream could read your data before you do.
  2. There is no mechanism to provide any authorisation control for data written to the stream servlet. Thus anybody who guesses the name of your data stream could read your data from the servlet before you do.
  3. For OGSA-DAI WSRF, only GSI Secure Conversation message-level security is supported for inter-service communications using the data transport activities [23].
  4. Encrypted role map files are currently unsupported.
  5. If a client does not provide a certificate then deliverFromGridFTP and deliverToGridFTP in a request will fail.
• General:
  1. The fileAccessActivity encodes text line-by-line if Base 64 encoding is being used. This may give different results from encoding a whole file in a oner.
  2. Note that when deploying new data service resources dynamically via configurable data service this only works if the JARs required by the data service resource (e.g. database driver JARs) are already within the web service container's library directories. If this is not the case then the container has to be restarted.
  3. The data service terminate operation currently does nothing. It is intended as a placeholder for future development.
  4. Meta-data from a database, returned by the extractDatabaseSchemaActivity, can be case-sensitive depending upon the database. For example MySQL might return a table called littleblackbook while DB2 returns LITTLEBLACKBOOK.
  5. The uk.org.ogsadai.common.BinaryLob class contains unimplemented methods which throw java.lang UnsupportedMethodException.
  6. Conversion of java.sql.ResultSet to XML WebRowSet returns empty key-column and map properties in the properties element.
  7. The table-name tag in WebRowSet XML is empty in results produced by Oracle or SQLServer. This is a problem of the JDBC drivers that do not provide table names in the metadata of a java.sql.ResultSet [15].
  8. deliverFromGridFTP and deliverToGridFTP do not allow the setting of certain GridFTP parameters.
  9. The deliverToStream activity only works if services are deployed in Tomcat.
  10. The data accessed from the getNBlocks operation of a data service is returned in an aggregated form. There is no delimitation of each of the N blocks [5].
  11. Once initiated the commands to add data services or submit queries cannot be prematurely cancelled in the data browser. The user must wait for the command to complere or timeout [16].
  12. The implementation of the xUpdateStatement activity only supports XUpdate statements provided in-line, not those provided from the output of another activity [57].
  13. No cleanup if client-service communication times out. Service will just reply as usual [52].
  14. The undeployment of data service resources from a Web services container is not yet supported.
  15. There is no read until end-of-file support in fileAccessActivity. The more-flexible readFile activity does support this however [26].
  16. Bad parameter values to the OGSA-DAI clients can cause seemingly incorrect error messages. For example: if the data service client is used with a bad dai.url parameter e.g.

      $ ant dataServiceClient -Ddai.urlxxx -Ddai.resource.id=SQLOne
        -Ddai.action=examples/Perform/JDBC/query/select1Row.xml
      

      the error message says incorrectly that:

      You have forgotten to provide a data service resource ID using 
      the -Ddai.resource.id= flag or an action, using the 
      -Ddai.action=[ PERFORM-DOC | 'deploy' | 'undeploy'] flag!
      

      Even though both those parameters do exist. This is not an OGSA-DAI problem but rather how ANT handles command-line properties - it cannot find the = so it chooses the following space as the point at which a property and its value is delimited.