oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nguyen, Ricky" <rngu...@chla.usc.edu>
Subject Re: Issue with query_tool when all product types are not populated
Date Thu, 23 Feb 2012 22:32:16 GMT
I've run into this issue with using filemgr-client CLI. I think when the WHERE clause is empty
or missing, the parser is trying to send NULL values (as the search criteria) over xmlrpc.

Query tool appears to work with "SELECT * FROM MyProductType"

-Ricky


On Feb 23, 2012, at 1:29 PM, holenoter wrote:

hey sean,

this part of your log output tells me your shell is expanding your *'s:

>>>> WARNING: XMLRepositoryManager: Unable to find product type:
>>>>[convert_map
>>>> filemgr filemgr-client migrate_xml_policy query_tool], returning null

-brian

On Feb 23, 2012, at 01:16 PM, "Hardman, Sean H (388J)" <sean.h.hardman@jpl.nasa.gov<mailto:sean.h.hardman@jpl.nasa.gov>>
wrote:

Hey Brian,

Restoring to the original filemgr-client script (using $* instead of
"$@"), I get the same result with single or double quotes.

Sean

On 2/23/12 11:47 AM, "Brian Foster" <holenoter@me.com<mailto:holenoter@me.com>>
wrote:

>Hey Sean,
>
>Maybe try using single quotes instead of double... i.e. ... -query
>'SELECT * FROM *'... your shell is prob expanding your *'s
>
>-Brian
>
>"Hardman, Sean H (388J)" <sean.h.hardman@jpl.nasa.gov<mailto:sean.h.hardman@jpl.nasa.gov>>
wrote:
>
>>Hey Chris,
>>
>>I would love to prove that theory correct but I am not using variables to
>>specify my policy directories. I am using absolute paths. Your reply did
>>prompt me to run through the tests again and I did discover something in
>>the filemgr-client script. In April of last year, I created an issue [1]
>>regarding the query_tool script and its lack of support for quoted
>>parameters. The resolution was to replace $* in the script with "$@". Now
>>that the filemgr-client script needs to support the same arguments that
>>the query_tool script supports, I am thinking it needs the same patch as
>>well. I made that change locally and although the query still fails as
>>documented in [2], the error below that you reference no longer is
>>generated by the server. I am not entirely clear on the connection
>>between
>>this patch and the original error (maybe you or Brian could enlighten
>>me),
>>but it does appear worthy of a new JIRA issue.
>>
>>Sean
>>
>>[1] https://issues.apache.org/jira/browse/OODT-185
>>[2] https://issues.apache.org/jira/browse/OODT-384
>>
>>On 2/23/12 6:21 AM, "Mattmann, Chris A (388J)"
>><chris.a.mattmann@jpl.nasa.gov<mailto:chris.a.mattmann@jpl.nasa.gov>>
wrote:
>>
>>>Hey Sean,
>>>
>>>Thanks, the below helped, as I think I know now what your problem is.
>>>Fast forward to here:
>>>
>>>On Feb 21, 2012, at 11:01 AM, Hardman, Sean H (388J) wrote:
>>>>
>>>> And generates the following on the server side:
>>>>
>>>> Feb 21, 2012 9:32:29 AM
>>>> org.apache.oodt.cas.filemgr.repository.XMLRepositoryManager
>>>> getProductTypeByName
>>>> WARNING: XMLRepositoryManager: Unable to find product type:
>>>>[convert_map
>>>> filemgr filemgr-client migrate_xml_policy query_tool], returning null
>>>> java.lang.NullPointerException
>>>
>>>This looks like an incorrect ENV var issue, where you assumed in your
>>>product type policy that a particular environment variable was present
>>>when you started file manager, but in the end, it wasn't and you
>>>defaulted
>>>to the current directory (which looks like bin) where you started file
>>>manager
>>>from as your policy directory.
>>>
>>>Can you please confirm that your product type repository path for these
>>>three references an environment variable that is actually present when
>>>you
>>>started the file manager? One way to do this is to simply make sure it's
>>>there
>>>explicitly in the session (via export or setenv) and then /filemgr
>>>restart.
>>>
>>>HTH,
>>>Chris
>>>
>>>>
>>>> On 2/20/12 11:45 PM, "Brian Foster" <holenoter@me.com<mailto:holenoter@me.com>>
wrote:
>>>>
>>>>> Hey Sean,
>>>>>
>>>>> Try using the new SqlQuery action in 0.4 filemgr
>>>>>
>>>>> -Brian
>>>>>
>>>>> On Feb 20, 2012, at 6:30 PM, "Hardman, Sean H (388J)"
>>>>> <sean.h.hardman@jpl.nasa.gov<mailto:sean.h.hardman@jpl.nasa.gov>>
wrote:
>>>>>
>>>>>> I first noticed this behavior in release 0.3 and just reaffirmed
it
>>>>>>in
>>>>>> a latest and greatest build of 0.4-SNAPSHOT. To the best of my
>>>>>> knowledge, this was not the case in previous versions. When
>>>>>>querying a
>>>>>> File Manager instance with a Lucene Catalog on the back end, the
>>>>>> query_tool will throw an exception unless there is a product
>>>>>>ingested
>>>>>> for each product type listed in the policy (see the stack trace
>>>>>>below).
>>>>>>
>>>>>> I assume I am not the first person to notice this behavior. Is this
>>>>>> worthy of a JIRA issue?
>>>>>>
>>>>>> Thanks,
>>>>>> Sean
>>>>>>
>>>>>>
>>>>>> bash-3.2$ ./query_tool --url ${FILEMGR_URL} --sql -query "SELECT
*
>>>>>>FROM
>>>>>> *"
>>>>>> Feb 20, 2012 5:52:26 PM
>>>>>> org.apache.oodt.cas.filemgr.catalog.LuceneCatalog paginateQuery
>>>>>> WARNING: Query: [q=] for Product Type: [urn:pds:CatalogObject]
>>>>>>returned
>>>>>> no results
>>>>>> java.lang.NullPointerException
>>>>>> at
>>>>>>
>>>>>>org.apache.oodtcas.filemgr.system.XmlRpcFileManager.complexQuery(Xml
>>>>>>Rp
>>>>>>cF
>>>>>> ileManager.java:602)
>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>> at
>>>>>>
>>>>>>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
>>>>>>ja
>>>>>>va
>>>>>> :39)
>>>>>> at
>>>>>>
>>>>>>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
>>>>>>so
>>>>>>rI
>>>>>> mpl.java:25)
>>>>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>>>> at org.apache.xmlrpc.Invoker.execute(Invoker.java:130)
>>>>>> at
>>>>>>org.apache.xmlrpc.XmlRpcWorker.invokeHandler(XmlRpcWorker.java:84)
>>>>>> at org.apache.xmlrpc.XmlRpcWorker.execute(XmlRpcWorker.java:146)
>>>>>> at org.apache.xmlrpc.XmlRpcServer.execute(XmlRpcServer.java:139)
>>>>>> at org.apache.xmlrpc.XmlRpcServer.execute(XmlRpcServer.java:125)
>>>>>> at org.apache.xmlrpc.WebServer$Connection.run(WebServer.java:761)
>>>>>> at org.apache.xmlrpc.WebServer$Runner.run(WebServer.java:642)
>>>>>> at javalang.Thread.run(Thread.java:680)
>>>>>> org.apache.xmlrpc.XmlRpcException: java.lang.Exception:
>>>>>> org.apache.oodt.cas.filemgr.structs.exceptions.CatalogException:
>>>>>>Failed
>>>>>> to perform complex query : null
>>>>>> at
>>>>>>
>>>>>>org.apache.xmlrpc.XmlRpcClientResponseProcessor.decodeException(XmlRp
>>>>>>cC
>>>>>>li
>>>>>> entResponseProcessor.java:104)
>>>>>> at
>>>>>>
>>>>>>org.apache.xmlrpc.XmlRpcClientResponseProcessor.decodeResponse(XmlRpc
>>>>>>Cl
>>>>>>ie
>>>>>> ntResponseProcessor.java:71)
>>>>>> at
>>>>>>
>>>>>>org.apache.xmlrpc.XmlRpcClientWorker.execute(XmlRpcClientWorker.java:
>>>>>>73
>>>>>>)
>>>>>> at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:194)
>>>>>> at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:185)
>>>>>> at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:178)
>>>>>> at
>>>>>>
>>>>>>org.apache.oodt.cas.filemgr.system.XmlRpcFileManagerClient.complexQue
>>>>>>ry
>>>>>>(X
>>>>>> mlRpcFileManagerClient.java:974)
>>>>>> at
>>>>>>
>>>>>>org.apache.oodt.cas.filemgr.tools.QueryTool.performSqlQuery(QueryTool
>>>>>>.j
>>>>>>av
>>>>>> a:252)
>>>>>> at
>>>>>>org.apache.oodt.cas.filemgr.tools.QueryTool.main(QueryTool.java:242)
>>>>>> Exception in thread "main"
>>>>>> org.apache.oodt.cas.filemgr.structs.exceptions.CatalogException:
>>>>>> java.lang.Exception:
>>>>>> org.apache.oodt.cas.filemgr.structs.exceptions.CatalogException:
>>>>>>Failed
>>>>>> to perform complex query : null
>>>>>> at
>>>>>>
>>>>>>org.apache.oodt.cas.filemgr.system.XmlRpcFileManagerClient.complexQue
>>>>>>ry
>>>>>>(X
>>>>>> mlRpcFileManagerClient.java:980)
>>>>>> at
>>>>>>
>>>>>>org.apache.oodt.cas.filemgr.tools.QueryTool.performSqlQuery(QueryTool
>>>>>>.j
>>>>>>av
>>>>>> a:252)
>>>>>> at
>>>>>>org.apache.oodt.cas.filemgr.tools.QueryTool.main(QueryTool.java:242)
>>>>>>
>>>>
>>>
>>>
>>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>Chris Mattmann, Ph.D.
>>>Senior Computer Scientist
>>>NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>>Office: 171-266B, Mailstop: 171-246
>>>Email: chris.a.mattmann@nasa.gov<mailto:chris.a.mattmann@nasa.gov>
>>>WWW: http://sunset.usc.edu/~mattmann/
>>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>Adjunct Assistant Professor, Computer Science Department
>>>University of Southern California, Los Angeles, CA 90089 USA
>>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>
>>




---------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, 
is for the sole use of the intended recipient(s) and may contain confidential
or legally privileged information. Any unauthorized review, use, disclosure
or distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of this original message.  

---------------------------------------------------------------------


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message