Uploaded image for project: 'Pentaho Analysis - Mondrian'
  1. Pentaho Analysis - Mondrian
  2. MONDRIAN-1056

When JDBC connection for some XML/A datasource are not availalbe, the entire DISCOVER request fails with "Uncaught error SOAP-ENV:Server.00HSBE02: XMLA Discover unparse results error"

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Severity: Medium
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      Ubuntu 11.10; biserver-ce-3.10.0-stable; Mondrian: mondrian-3.3.0.14703.jar
    • Notice:
      When an issue is open, the "Fix Version/s" field conveys a target, not necessarily a commitment. When an issue is closed, the "Fix Version/s" field conveys the version that the issue was fixed in.

      Description

      I am have multiple catalogs in pentaho-solutions/system/olap: the predefined SteelWheels and SampleData, and I also have FoodMart, which I manually installed by publishing the foodmart sample schema via schema workbench. The JDBC connections for the predefined ones are also untouched, and point to the hsql database. The connection for the foodmart catalog points to a mysql connection.

      I use XML/A to discover the available data sources using this request:

      <?xml version="1.0" encoding="UTF-8"?>
      <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
      <SOAP-ENV:Body>
      <Discover xmlns="urn:schemas-microsoft-com:xml-analysis" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
      <RequestType>DISCOVER_DATASOURCES</RequestType>
      <Restrictions>
      </Restrictions>
      <Properties>
      </Properties>
      </Discover>
      </SOAP-ENV:Body>
      </SOAP-ENV:Envelope>

      If the both databases are running, I get the expected response, listing one row with datasource info:

      <row>
      <DataSourceName>Provider=Mondrian;DataSource=Pentaho</DataSourceName>
      <DataSourceDescription>Pentaho BI Platform Datasources</DataSourceDescription>
      <URL>http://localhost:8080/pentaho/Xmla?userid=joe&#38;password=password</URL>
      <DataSourceInfo>Provider=Mondrian;DataSource=Pentaho</DataSourceInfo>
      <ProviderName>PentahoXMLA</ProviderName>
      <ProviderType>MDP</ProviderType>
      <AuthenticationMode>Unauthenticated</AuthenticationMode>
      </row>

      (rest of response ommitted)
      This is expected behaviour.

      However, if I shutdown the mysql server (for the foodmart catalog) and I restart the bi-server (restart is necessary to observe) and I post the same discover request, I get this response:

      ?xml version="1.0" encoding="UTF-8"?>
      <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" >
      <SOAP-ENV:Header>
      </SOAP-ENV:Header>
      <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
      <faultcode>SOAP-ENV:Server.00HSBE02</faultcode>
      <faultstring>XMLA Discover unparse results error</faultstring>
      <faultactor>Mondrian</faultactor>
      <detail>
      <XA:error xmlns:XA="http://mondrian.sourceforge.net">
      <code>00HSBE02</code>
      <desc>The Mondrian XML: Connection refused</desc>
      </XA:error>
      </detail>
      </SOAP-ENV:Fault>
      </SOAP-ENV:Body>
      </SOAP-ENV:Envelope>

      There are two problems with that.
      #1 the message "XMLA Discover unparse results error" is obscure and doesn't indicate what the real problem is. A better error message is inside the detail, but a generic XML/A client may not know how to parse that since the format of the detail is not defined by the standard (AFAIK).
      #2 The error should not occur in the first place. IIUC, the XML/A "DataSource" concept which we are requesting info about is simply the entry point for doing specific XML/A requests. Whether or not all, some or none of its associated catalogs are in fact available to service requests should not affect the DataSourceInfo discover request at all. An error for this request would be appropriate if it is clear that the XML/A service is completely unable to service any requests, but that does not seem the case here.

      So, my suggestion is to not let the discover datasourceinfo request fail because a connection for one or more (or indeed any) of the catalogs happens not to be available. In the worst case, just one temporarily failing connection blocks access to all others.

      There are related issues with the discover catalogs request. When the mysql server is brought down after doing the initial successful DataSourceInfo request and a request is issued to discover the available catalogs, mondrian will report the availability of the foodmart catalog, altough it is clear that this cannot be used since its JDBC connection is unavailable. One can argue that it could in these circumstances still be useful to allow various discover requests to succeed against the schema cache, however, I would prefer to know if the catalog is in fact available in full for any and all operations (including the ones that do require a working JDBC connection).

      I suppose it is ok for mondrian to keep the catalog in its cache even if it detects (in the course of serving a discover request) that the JDBC connection isn't available anymore, but it should IMO not report the existence of any of the connection's associated catalogs until the JDBC connection becomes available again.

      In my opinion, this change in behaviour will make the XML/A experience much more robust and useful

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              rbouman Roland Bouman (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: