The following questions and answers deal with frequent problems in setting OGSA-DAI up. 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 Known Problems pages.
The list of officially supported databases is on the Supported Data Resources page.
Some versions of Oracle distribute a JDBC driver as a set of classes bundled in a ZIP file, e.g. oracle-jdbc.zip. This should be renamed to a have a .jar extension (i.e. oracle-jdbc.jar).
If you have already deployed the data service resource then the Oracle JDBC driver will be in the web service container lib directory, alongside the OGSA-DAI JARs, you should rename it. This page on where files reside after deployment tells you where these can be found.
On Sun Solaris you may get a "TAR file corrupted" error when trying to untar using Sun's version of tar. It is known that Sun's tar cannot handle long pathnames, which are often present in Java package structures.
You should use gnutar instead (you can get this from http://www.gnu.org/software/tar if you do not have it already).
The instructions for doing this are available in the enabling logging pages.
There are a number of possible causes for this. It may be useful to refer to the page on where files reside after deployment as this tells you where your data service resource configuration files reside on the server.
org.xml.sax.SAXParseException: SchemaLocation: schemaLocation value = 'http://ogsadai.org.uk/namespaces/2005/03/config file:///D:/Programme/Apache Software Foundation/Tomcat 5.5/webapps/wsrf/share/schema/ogsadai/xsd/data_resource_config.xsd' must have even number of URI's.
This indicates that a serious problem has occurred server-side. The message will include a unique ID. This unique ID will correspond to error information recorded in the server-side logs. From this the service deployer can track down the cause of the problem you have experienced.
Naturally, if you set up your Web services container and deployed the OGSA-DAI services and data service resources then it is you who are the service deployer!
If the server-side logs do not display enough detail then the logging level should be set to INFO or, if desperate, DEBUG.. The instructions for doing this are available in the enabling logging pages.
This indicates that you do not have sufficient authorisation to execute your request. For example your credentials may not be accepted by the service. The message will include a unique ID. This unique ID will correspond to error information recorded in the server-side logs. From this the service deployer can see what you were doing and whether you should be authorised to do it.
Naturally, if you set up your Web services container and deployed the OGSA-DAI services and data service resources then it is you who are the service deployer!
This problem can occur if you do not have our client-config.wsdd file in your CLASSPATH. Without this file the client toolkit cannot add WS-Addressing information to a request and so the server does not know which resource at which your request is directed.
You should ensure that the client-config.wsdd file is in your CLASSPATH and rerun your client.
If the problem still happens then there is a server-side problem and you should consult the OGSA-DAI service deployer.
Clients (for example the end-to-end client) may timeout before an asynchronous request has had time to complete. It is possible to alter the amount of time before the request times out.
You can set the timeout using the client toolkit. For example:
import uk.org.ogsadai.client.toolkit.TimeoutProperty; import uk.org.ogsadai.client.toolkit.service.DataService; ... DataService myServiceStub = ... // Set timeout in milliseconds TimeoutProperty timeout = new TimeoutProperty(1000000); myServiceStub.setConnectionProperty(timeout);
Giving a TimeoutProperty value of 0 means infinity.
Check that the three driver files, msbase.jar, mssqlserver.jar and msutil.jar are in the web service container's lib directory. These are located alongside the OGSA-DAI JARS and this page on where files reside after deployment tells you where these can be found.
This is a known problem. If you submit a request containing both an inputStream and an outputStream linked together and then submit a block of data to that inputStream (via the data transport putBlock operation), you cannot immediately retrieve that block from the outputStream (via the data transport getBlock or getNBlocks operations).
Instead, at least 3 blocks of data must be submitted to the inputStream before the first block can be retrieved from the outputStream, and a fourth block must be submitted before the second can be retrieved, etc. When the closing block is submitted to the inputStream, the remaining blocks can then be retrieved from the outputStream.
Unfortunately, the larger the number of connected activities, the more more blocks that must be submitted before blocks are available from outputStream activities.
If manipulating large sets of data the Java Virtual Machine may run out of memory. This can be alleviated by increasing the memory heap size for the virtual machine using the Xms<size> flag.
For relational databases, sometimes the default behaviour of some JDBC drivers is to retrieve the entire result sets into memory before passing control back to OGSA-DAI. We recommend trying different database management systems and their respective JDBC drivers.
The risk of this error arising may also be reduced by using asynchronous data transport functionalty (e.g. inputStream and outputStream activities and the data transport getNBlocks and putBlock operations) to stream the data to and from the service in chunks.
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.
The MySQL JDBC driver recommended for OGSA-DAI is not compatible with the latest versions of MySQL. This is the case for MySQL 4.1.6 and 4.1.7 and may be the case for other versions. This problem usually causes the following error message to be logged:
java.sql.SQLException: Cannot connect to MySQL server on host:port. Is there a MySQL server running on the machine/port you are trying to connect to? (java.lang.NumberFormatException)
This problem can be sorted by selecting the latest version of the MySQL JDBC driver JAR when deploying data service resources that expose the latest versions of MySQL. These are available from:
If you have already deployed a data service resource using the incompatible JAR, follow these steps:
MySQL Connector/J 3.1 has been tested successfully with MySQL 4.1.6 and 4.1.7 and the current releases of OGSA-DAI.
This can happen when contacting an OGSA-DAI WSRF service when using either OGSA-DAI WSRF or OGSA-DAI WSI clients. You will likely see the following in the server-side logs:
2006-01-11 19:59:33,518 ERROR impl.DataServiceImpl [Thread-9,throwInternalFault:750] Internal Error! Consult the OGSA-DAI Service Provider with ID 1137016773518:0. ... 2006-01-11 19:59:33,519 ERROR impl.DataServiceImpl [Thread-9,throwInternalFault:752] Internal Error: Could not access resource-related information. Exception: class org.globus.wsrf.InvalidResourceKeyException ... Stack trace: org.globus.wsrf.InvalidResourceKeyException: ResourceKey must not be null.
On the client-side this is manifested as a InternalFault or InternalException.
This warning occurs when a client has not added information on the resource to the message transmitted to the service so the service does not know which resource at which a request is directed.
If a client is invoking the operations getVersion or listResources operations of data service then the warning can be ignored. This is because these operations are service-wide i.e. they are not run on a specific resource so no resource information is sent by the client. The Globus Toolkit throws up the warning regardless.In all other situations - where a client wants the service to run an operation on a specific resource - the warning cannot be ignored. The most common cause of this warning is that the ID of resource is missing from the message transmitted to the service. To specify this requires a configuration file - client-config.wsdd - that we provide to be available in a directory that is in the CLASSPATH:
If you ensure that this file is in a directory that is in the CLASSPATH then the OGSA-DAI WSRF will receive the information on the resource being targetted by the client's request.
Attempting to use the xmlResourceManagement activity to store an XML document with a size over 5MB may cause the following error:
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
This is due to the current implementation of the xmlResourceManagement activity which requires the whole document to be stored in memory by the service container. The situation can be improved by allocating more memory to Tomcat and your client application using JVM arguments such as -Xmx300m. Please see the Tomcat and JVM documentation for more details.
The example below shows how to set the CATALINA_OPTS environmental variable on Windows in order to allocate more memory the next time Tomcat is started.
set CATALINA_OPTS="-server -Xms300m -Xmx300m -XX:NewRatio=2 -Xconcurrentio"
Note that when storing large XML documents, the inputStream activity and the data transport functionality should be used to deliver the document content to the data service resource. This is instead of embedding the document content within the xmlResourceManagement activity request, which would require the entire document to be stored in memory at the client and the service.
The best solution to this problem would be to modify the implementation of the uk.org.ogsadai.activity.xmldb.commands.CreateResourceCommand class to use the streaming XMLResource#setContentAsSAX method instead of the XMLResource#setContentAsDOM(newDocument) method which is currently used. This should allow much larger XML documents to be stored through OGSA-DAI, however it is a non-trivial change.
The software used to unpack the release may introduce problems into the OGSA-DAI/setenv.sh and OGSA-DAI/setenv.csh scripts which means they will not run without modification. This is due to carriage returns at the end of lines which confuses the shell interpreter. This problem can arise if you use WinZIP to download OGSA-DAI and then unpack and runn under UNIX or Linux.
The problem is evident under sh if you see the following:
$ source setenv.sh sh: : command not found sh: setenv.sh: line 5: syntax error near unexpected token `do ' sh: setenv.sh: line 5: `do
The problem is evident under csh if you see the following:
$ source setenv.csh set: Syntax error
You can:
This happens if the Tomcat common/lib/saaj.jar differs from webapps/YOUR-WEB-APP/WEB-INF/lib/saaj.jar or if common/lib/axis.jar differs from webapps/YOUR-WEB-APP/WEB-INF/lib/axis.jar
You should ensure that the JARs are identical via copying one over the other.
Yes you can update the configuration files for a data service resource, but only if the data service exposing the resource is configurable (i.e. supports the deploy and undeploy operations):
OGSA-DAI does not parse SQL statements, they are passed straight through to the underlying data resource via a JDBC driver. Therefore, as long as the JDBC driver used accepts the proprietary SQL, OGSA-DAI will allow it. Note that if requesting results in the WebRowSet format, proprietary datatypes may not be supported properly by OGSA-DAI.
Custom metadata can be published as data resource properties for JDBC and XMLDB data resources by adding the desired information to the data resource accessor configuration document. For details, see the configuration how-tos for JDBC data resource accessors and XMLDB data resource accessors.
The following file activities can cause potential security problems:
It is recommended that the above activities are not enabled in production installations. You should edit the activity configuration documents of data service resources and comment these activities out (or delete them). These documents are located in: OGSA-DAI/skeletons/activityConfig*.
On Windows 2000/NT/XP, the Xindice 1.0 XUpdate service does not operate correctly under Java 1.4. Whenever a query matches some existing data, and an update should be performed, a QueryProcessingError is thrown. This problem can be resolved by modifying two lines of the Xindice 1.0 source code and re-building Xindice, as described below:
XINDICE_HOME\java\src\org\apache\xindice\core\xupdate\XObjectImpl.java
return (NodeList) _xobj.nodeset();
to,
return (NodeList) _xobj.nodelist();
XINDICE_HOME\java\src\org\apache\xindice\core\query\XPathQueryResolver.java
int endFunc = pos + cmp.getOpMap().[pos+1] - 1;
to,
int endFunc = pos + cmp.getOpMap().elementAt(pos+1) - 1;
| Up: OGSA-DAI User Guide | ||
| © International Business Machines Corporation, 2002-2006 | © The University of Edinburgh, 2002-2006 |