Forum Discussion

TysonSouza's avatar
TysonSouza
New Contributor
5 years ago

getFetchSize is not supported

I currently have ReadyAPI 3.0.0 and when i run a Test Step that has a Select statement i get an error getFetchSize() is not supported. 

1) Firstly i connect successfully to Azure CosmosDB (I have the correct cdataJDBCdrivers, etc)

2) Then in the Test Step=>ConfigureTab=>SQL Query section,  I try to run a simple Select statement "Select c.* from <CosmosDBTableName> c "  i get the error getFetchSize() is not supported. 

Interestingly in the Test Step=>ConfigureTab=>BuildQuery, it shows me the same query and i am able to execute the query and also get the correct results.

 

Any input on how to overcome the issue with getFetchSize() is not supported. Please refer to the Errorlog below

 

Tue Dec 17 15:45:51 PST 2019: ERROR: XcoreXcosmosdbX190X7216.pce: getFetchSize() is not supported.
XcoreXcosmosdbX190X7216.pce: getFetchSize() is not supported.
at XcoreXcosmosdbX190X7216.vce.getFetchSize(Unknown Source)
at com.eviware.soapui.support.xml.XmlUtils.createResultSetElement(XmlUtils.java:1454)
at com.eviware.soapui.support.jdbc.JdbcUtils.parseResultSet(JdbcUtils.java:196)
at com.eviware.soapui.support.jdbc.JdbcUtils.createResultSetHolder(JdbcUtils.java:171)
at com.eviware.soapui.impl.wsdl.panels.teststeps.JdbcResponse.<init>(JdbcResponse.java:47)
at com.eviware.soapui.impl.wsdl.panels.teststeps.JdbcSubmit.createResponse(JdbcSubmit.java:275)
at com.eviware.soapui.impl.wsdl.panels.teststeps.JdbcSubmit.runQuery(JdbcSubmit.java:178)
at com.eviware.soapui.impl.wsdl.panels.teststeps.JdbcSubmit.run(JdbcSubmit.java:150)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

  • richie's avatar
    richie
    Community Hero

    Hi TysonSouza 

     

    This is total guess as I've never used CosmosDB before - but you're getting an issue with the getfetchsize() method immediately once the query executes.

     

    I have noticed differing behaviour between the QueryBuilder and executing via the SQL query editable field before now - so cant really comment on that - but have you tried executing your query from outside of ReadyAPI! at all?

     

    Typically when I've had problems like this before now - I've tried executing the same query (using the same drivers/JDBC connection string) to execute the query in some other DB interrogation tool (DB Visualiser etc.)  The fact your getting an issue with the getfetchsize() method leads me towards thinking you have a driver issue.

     

    HOWEVER - this is cloud based DB - right?  Are you sure there isn't any resource slicing going on?  i.e. your SaaS contract might have restrictions on pulling a full tables worth of data (especially if the query you're executing doesn't run any indexes)

     

    Have you tried using fetch (or maybe there's a nonANSI standard SQL command for CosmosDB to restrict the number of rows returned like "select top X from table;" in SQL Server SQL?

     

    To reiterate:

    If there's any resource slicing - you might not have the privilege to pull a full tables worth of data without restricting the number of records in the result set - so I'd alter the query to pull only a few records first to test this.

    Next - I'd identify the fields in your table with indexes and use that - search on the indexed column and see if that works

    Finally - I'd try the unaltered query in a separate DB interrogation tool (ensuring to use the same drivers/connection string you're using in ReadyAPI!)

     

    hope the above helps!

     

    nice one

     

    rich

     

    I'd also (

    • TysonSouza's avatar
      TysonSouza
      New Contributor

      Thanks for your response Richie. 

      [Richie]: This is total guess as I've never used CosmosDB before - but you're getting an issue with the getfetchsize() method immediately once the query executes.

      [Tyson]: Yes, this is with Microsoft Azure CosmosDB and yes once the query executes, I see this on the Request log "2019-12-17 20:34:08.906 - Error getting response; null" and when i view the Error log, that is where it has the getfetchsize() is not support message is recorded.

       

      [Richie]: I have noticed differing behaviour between the QueryBuilder and executing via the SQL query editable field before now - so cant really comment on that - but have you tried executing your query from outside of ReadyAPI! at all?

      [Tyson]: Yes using the same driver/jar, i was able to connect with DBVisualizer and all the queries that i wanted to execute does get executed successfully with correct results including the simple Select statement.

       

      [Richie]: HOWEVER - this is cloud based DB - right?  Are you sure there isn't any resource slicing going on?  i.e. your SaaS contract might have restrictions on pulling a full tables worth of data (especially if the query you're executing doesn't run any indexes)

      [Tyson]: Yes this is CloudDB. As an example, I had also tried with an explicit "where condition" in the select statement which should return only 1 result row . This query when tried via ReadyAPI QueryBuilder i.e BuildQuery and also in DBVisualizer works correctly and returns only 1 result row, but if i try the same using the "SQL Query" I get the same getfetchsize() error immediately after the query executes.  I have also tried with indexed columns but with the same results.  Any other thoughts/ideas?

        Ideally what i want to accomplish though is once the Test step is executed (SQLQuery or Build Query option whichever one is successful, though currently BuildQuery seems to return the results but not SQLQuery) i want to parse the JSON response of the query and get the needed values.  Is there a way to accomplish this from BuildQuery option results so that i can explore that if no solution for SQLQuery option error (My advance apologies if this has to be a separate question, if so please advise and i will follow-through).  

      • richie's avatar
        richie
        Community Hero
        Hi TysonSouza,

        To be clear....whatever query that is executed via the sql window (as well as when you execute the testcase containing the problematic JDBC step) always fails to execute no matter whether executing on a index, adding a where clause filter or attempting to restrict the returned resultset in some way so there isnt a default getfetchsize call made?
        You also noticed when executing the test via querybuilder it executes fine, but when executing any other way it fails to retrieve thr resultset and this getfetchsize method issue is reported in the trace?

        Sounds like you've done everything i would've tried to fix this yourself, but i don't think there's an easy way around this.
        I dont actually know the querybuilder function other than clicking in it once or twice (second time being today) cos i just type in the sql in the sql form field.
        Id suggest theres definitely a ReadyAPI! defect going on here as you can execute successfully via querybuilder but not from the sql window. The querybuilder populates the sql window with the dynamic generated sql, right? The thing is, the querybuilder is just building your query with an execution option to verify your query does what it wants, right?

        Id raise a support ticket with smartbear for this....they need to know there is an issue interrogating CosmosDB emphasising there is no issue when executing via querybuilder, but there is a problem when executing the step and containing testcase.

        The only thing i can suggest in the meantime (cos youve got a total blocker as far as i can see) whilst youre waiting for Smartbear to investigate is try upgrading and downgrading your driver .jar/JRE....perhaps a different version of .jar/JRE might get you around thr issue?
        I know this sounds like a total longshot, but i had a "similar" problem with a totally different RDBMS called MIMER and altering the jre/.jar file versions got me around the problem.
        Last longshot....can you downgrade your ReadyAPI! version...maybe v2.8 or v2.6? Maybe check the release notes and see if there were any changes to the jdbc component so worth downgrading to check?

        Lastly i've been doing some reading....there's only been a CosmosDB connection driver for the last year....before then a driver wasnt available (raising the questions whats the point of a db you cant connect to!?!?!?) so perhaps there are teething troubles?

        Oh...one last thing that sometimes catches people out....your ReadyAPI! has the same bittype (no i dont know the correct term) as your java, right? So if running x86 java you need 32bit ReadyAPI!, Likewise if youre running 64bit java then you need 64bit ReadyAPI!....this can cause problems if not lined up properly.

        Ok..thats it from me...im sorry i cant be of more help....when raising the ticket with Smartbear ensure you mention youve already confirmed queyr executes successfully in dbvisualiser and works in querybuilder but not when executing the step

        Cheers

        Rich