asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yingyi Bu <buyin...@gmail.com>
Subject Re: REST API question
Date Mon, 10 Aug 2015 21:45:32 GMT
Sounds like a great improvement!

Best,
Yingyi

On Mon, Aug 10, 2015 at 2:32 PM, Chris Hillery <chillery@hillery.land>
wrote:

> That's a good question. At first glance it appears the answer is "no",
> unfortunately. I'm not intimately familiar with that code, but it looks
> like it might be possible to support it. It would be easy enough to have a
> flag that told the insert (and other DMLs) to return immediately with some
> kind of key. Then I think it would be possible to have another "is this job
> done yet" HTTP endpoint that accepted that key, the way that queryResults
> does today. That would allow the user to poll for the response.
>
> Ceej
> aka Chris Hillery
>
> On Mon, Aug 10, 2015 at 2:18 PM, Yingyi Bu <buyingyi@gmail.com> wrote:
>
> > >>I would suggest that for long-running queries, using the
> deferred-results
> > >>APIs makes more sense than counting on a TCP connection to stay up.
> >
> > That makes sense to me.
> > Is the option also available for DMLs (inserts and deletes) which do not
> > have any
> > returned results?
> > A user may want to how long a "long running" DML takes and whether it
> > succeeds or not.
> >
> > Best,
> > Yingyi
> >
> >
> >
> > On Mon, Aug 10, 2015 at 2:06 PM, Chris Hillery <chillery@hillery.land>
> > wrote:
> >
> > > My first guess would be that Jetty (in the AsterixDB server) is timing
> > out
> > > the HTTP connection as idle. The default timeout is either 5 minutes or
> > 30
> > > seconds, depending on the Jetty version. We can configure that, but I'm
> > not
> > > sure having it set to multiple hours is a reasonable out-of-the-box
> > > experience.
> > >
> > > I would suggest that for long-running queries, using the
> deferred-results
> > > APIs makes more sense than counting on a TCP connection to stay up.
> > >
> > > Ceej
> > > aka Chris Hillery
> > >
> > > On Mon, Aug 10, 2015 at 1:09 PM, Yingyi Bu <buyingyi@gmail.com> wrote:
> > >
> > > > Right, probably it is a timing issue --- but I'm not sure it's a
> server
> > > > side problem or a client side problem..
> > > >
> > > > Best,
> > > > Yingyi
> > > >
> > > > On Mon, Aug 10, 2015 at 12:56 PM, Ian Maxon <imaxon@uci.edu> wrote:
> > > >
> > > > > I've had this happen before as well, it's annoying to have to
> either
> > > > scour
> > > > > the logs or look in the Hyracks adminconsole to see what really
> > > happened.
> > > > > Is it possible that we are timing out the HTTP connection
> > incorrectly?
> > > > >
> > > > > - Ian
> > > > >
> > > > > On Mon, Aug 10, 2015 at 11:24 AM, Yingyi Bu <yingyib@ics.uci.edu>
> > > wrote:
> > > > >
> > > > > > Hi guys,
> > > > > >
> > > > > >     I ran an insert DDL from the REST API.  From the cc/nc logs,
> > it
> > > > > looks
> > > > > > the insert job finished without any exceptions in about 1.5
> hours.
> > > > > Also, a
> > > > > > simple count aggregation on the target dataset of the insert
> > > statement
> > > > > > returns the correct result.  However, my HTTP client program
> hangs
> > > > > > forever.  Smaller insert jobs do not have that problem.  Does
> > anyone
> > > > have
> > > > > > similar experience or know what's going on?
> > > > > >     Thanks!
> > > > > >
> > > > > > Best,
> > > > > > Yingyi
> > > > > >
> > > > >
> > > >
> > >
> >
>

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