[
https://issues.apache.org/jira/browse/FALCON-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110365#comment-14110365
]
Shwetha G S edited comment on FALCON-166 at 8/26/14 7:06 AM:
-------------------------------------------------------------
{quote}
numResults defaults to "-1", which means return all instances.
{quote}
The default behaviour shouldn't be return all instances. It can cause memory
issues. Any number like 10 is fine
{quote}
If endDate is empty, it defaults to max of (startDate + 10 * frequency *
frequencyTimeUnit) OR (currentTimestamp). This will fetch 10 instances (if they
are scheduled). This will ensure there is large enough time window to get some
instances.
{quote}
On what basis, will you choose (startDate + 10 * frequency * frequencyTimeUnit)
OR (currentTimestamp)? Length will already control the number of instances to
return. It doesn't make any sense to compute end again depending on that
{quote}
This is bad, what I had suggested to Balu is to have some multiplication
factor for end date based on frequency that results in few instances being
returned.
{quote}
If the new param length can control number of instances returned, why not set
end to now?
was (Author: shwethags):
{quote}
numResults defaults to "-1", which means return all instances.
{quote}
The default behaviour shouldn't be return all instances. Any number like 10 is
fine
{quote}
If endDate is empty, it defaults to max of (startDate + 10 * frequency *
frequencyTimeUnit) OR (currentTimestamp). This will fetch 10 instances (if they
are scheduled). This will ensure there is large enough time window to get some
instances.
{quote}
On what basis, will you choose (startDate + 10 * frequency * frequencyTimeUnit)
OR (currentTimestamp)? Length will already control the number of instances to
return. It doesn't make any sense to compute end again depending on that
{quote}
This is bad, what I had suggested to Balu is to have some multiplication
factor for end date based on frequency that results in few instances being
returned.
{quote}
If the new param length can control number of instances returned, why not set
end to now?
> Instance status start and end dates are rigid and inconvenient
> --------------------------------------------------------------
>
> Key: FALCON-166
> URL: https://issues.apache.org/jira/browse/FALCON-166
> Project: Falcon
> Issue Type: Sub-task
> Components: webapp
> Affects Versions: 0.3
> Reporter: Venkatesh Seetharam
> Assignee: Balu Vellanki
> Fix For: 0.6
>
> Attachments: Falcon-Jira-166-v1.patch, Falcon-Jira-166-v2.patch,
> Falcon-Jira-166-v3.patch, Falcon-Jira-166.patch
>
>
> There are 2 annoying issues that was brought up by [~srimanth.gunturi] while
> working on FALCON-164. The use case is to get the status for a given entity
> for the past 1 or 2 or 3 or 7 days.
> 1. Instance status with out an end date fetches for a very small window
> Instance status take end date as optional but assumes one second from the
> start date which is too small a window.
> {code}
> private Date getEndDate(Date start, String endStr) throws FalconException
> {
> Date end;
> if (StringUtils.isEmpty(endStr)) {
> end = new Date(start.getTime() + 1000); // next sec
> } else {
> end = EntityUtil.parseDateUTC(endStr);
> }
> return end;
> }
> {code}
> May be assuming the current time might be appropriate instead.
> 2. The start date has to be on or after the start of the entity.
> If the user has created the entity 2 days back but specified the start date
> for looking at the instances in the past 7 days, it should fetch what is
> valid rather than complain that the start date is before the entity's start.
> This is quite unwieldy to work with in a dashboard use case. I'm not sure
> what the performance impact is for this API to be changed.
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
