Re: [VOTE] Moving Usergrid to the Attic

[Michael Russo]

This vote has passed. I'll continue the process of moving Usergrid to the
Attic.
Thanks everyone for the support and contributions over the years! It's been
a pleasure
working on the project.

-Russo

On Fri, Dec 3, 2021 at 12:34 AM Bobby Nielsen
 wrote:

> +1
>
> Den fre. 3. dec. 2021 kl. 01.23 skrev Dave :
>
> > +1
> >
> > On Thu, Dec 2, 2021 at 12:10 PM Rod Simpson  wrote:
> >
> > > +1
> > > On Dec 2, 2021, 10:05 AM -0700, Michael Russo ,
> > wrote:
> > > > (trying this again as the first email didn't seem to get delivered to
> > the
> > > > mailing list)
> > > >
> > > > Following the process outlined here,
> > > https://attic.apache.org/process.html,
> > > > I'm calling a vote to move Usergrid to the Attic.
> > > >
> > > > There have been no contributions in the last year and only a couple
> in
> > > the
> > > > year before that. There's no active development or maintenance of the
> > > > project. Given this is the case, I'm calling a vote to move Usergrid
> to
> > > the
> > > > Attic.
> > > >
> > > > This vote will close 72 hours from now on 2021-12-05 9:00:00 PT.
> > > >
> > > > +1 Move to the Attic
> > >
> >
>
>
> --
> De bedste hilsner / Kind regards,
>
> *Bobby Nielsen*
> Co-founder & CTO
>
>
> *m:* +45 28442269
> *e:* bo...@wiredrelations.com
> *w:* https://wiredrelations.com
>
> --
> This email and any files and attachments transmitted with it are
> confidential and may be legally privileged. If you are not the intended
> recipient of this email, you are hereby notified that any action taken or
> omitted in reliance to this email or any file or attachment transmitted
> with it is prohibited and may be unlawful. If you have received this email
> by mistake, please notify the sender immediately by sending a reply, and
> then delete this email from your system.
> You can read about how we collect
> and process your personal data, and your rights as a data subject, at:
> https://wiredrelations.com/privacy/ <https://wiredrelations.com/privacy/>
>

[VOTE] Moving Usergrid to the Attic

[Michael Russo]

(trying this again as the first email didn't seem to get delivered to the
mailing list)

Following the process outlined here, https://attic.apache.org/process.html,
I'm calling a vote to move Usergrid to the Attic.

There have been no contributions in the last year and only a couple in the
year before that. There's no active development or maintenance of the
project. Given this is the case, I'm calling a vote to move Usergrid to the
Attic.

This vote will close 72 hours from now on 2021-12-05 9:00:00 PT.

+1 Move to the Attic

[VOTE] Moving Usergrid to the Attic

[Michael Russo]

Following the process outlined here, https://attic.apache.org/process.html,
I'm calling a vote for us to move Usergrid to the Attic.

There have been no contributions in the last year and only a couple in the
year before that. There's no active development or maintenance of the
project. Given this is the case, I'm calling a vote to move Usergrid to the
Attic.

This vote will close 72 hours from now on 2021-12-04 15:00 PT.

+1 Move to the Attic

Re: Usergrid!

[Michael Russo]

Hi Bobby,

What version are you using? I think you might be using an older version. In
the master branch, the cursor issue is fixed:
https://github.com/apache/usergrid/blob/master/stack/rest/src/main/java/org/apache/usergrid/rest/management/organizations/OrganizationsResource.java#L128

However, in the 2.1.0 branch, you can see that "cursor" is not being set in
the response:
https://github.com/apache/usergrid/blob/2.1.0/stack/rest/src/main/java/org/apache/usergrid/rest/management/organizations/OrganizationsResource.java#L87

You can try using the tools JAR file to get the data you need but in a file
in CSV format.. specifically the organization export:
https://github.com/apache/usergrid/blob/master/stack/tools/src/main/java/org/apache/usergrid/tools/OrganizationExport.java.
Readme for building/running the jar is here:
https://github.com/apache/usergrid/tree/master/stack/tools.

Thanks.
-Michael

On Fri, Jun 18, 2021 at 3:00 PM Dave  wrote:

> I’m sorry, I meant to say I do NOT remember the answer to that question;
> and I’m not sure if I ever knew the answer.
>
> Best regards,
> Dave
>
>
> On Fri, Jun 18, 2021 at 5:25 PM Bobby Nielsen
>  wrote:
>
> > Please help me with a little question.
> >
> > Sorry to bother you, but I thought you might know if there is a
> limitation
> > on the number of orgs in Usergrid?
> >
> > GET /management/orgs only returns 1000 and query param limit has no
> effect,
> > and no cursor seems to be available on this resource.
> >
> > Please help. This is a production issue.
> >
> > Thanks,
> > Bobby
> >
> > -- Videresendt mail -
> > Fra: Dave 
> > Dato: fre. 18. jun. 2021 kl. 19.58
> > Emne: Re: Usergrid!
> > Til: Bobby Nielsen 
> >
> >
> > I remember the answer to that question. You should ask on the Usergrid
> dev
> > list, there are still some Usergrid old timers subscribed there.
> >
> > On Fri, Jun 18, 2021 at 5:43 AM Bobby Nielsen 
> > wrote:
> >
> > > Hi Dave,
> > >
> > > Sorry to bother you, but I thought you might know if there is a
> > limitation
> > > on the number of orgs in Usergrid?
> > >
> > > GET /management/orgs only returns 1000 and query param limit has no
> > > effect, and no cursor seems to be available on this resource.
> > >
> > > Please help. This is a production issue. Thanks.
> > >
> > > --
> > > De bedste hilsner / Kind regards,
> > >
> > > *Bobby Nielsen*
> > > Co-founder & CTO
> > >
> > >
> > > *m:* +45 28442269
> > > *e:* bo...@wiredrelations.com
> > > *w:* https://wiredrelations.com
> > >
> > > This email and any files and attachments transmitted with it are
> > > confidential and may be legally privileged. If you are not the intended
> > > recipient of this email, you are hereby notified that any action taken
> or
> > > omitted in reliance to this email or any file or attachment transmitted
> > > with it is prohibited and may be unlawful. If you have received this
> > email
> > > by mistake, please notify the sender immediately by sending a reply,
> and
> > > then delete this email from your system.
> > >
> > > You can read about how we collect and process your personal data, and
> > your
> > > rights as a data subject, at: https://wiredrelations.com/privacy/
> > >
> > --
> > De bedste hilsner / Kind regards,
> >
> > *Bobby Nielsen*
> > Co-founder & CTO
> >
> >
> > *m:* +45 28442269
> > *e:* bo...@wiredrelations.com
> > *w:* https://wiredrelations.com
> >
> > --
> > This email and any files and attachments transmitted with it are
> > confidential and may be legally privileged. If you are not the intended
> > recipient of this email, you are hereby notified that any action taken or
> > omitted in reliance to this email or any file or attachment transmitted
> > with it is prohibited and may be unlawful. If you have received this
> email
> > by mistake, please notify the sender immediately by sending a reply, and
> > then delete this email from your system.
> > You can read about how we collect
> > and process your personal data, and your rights as a data subject, at:
> > https://wiredrelations.com/privacy/  >
> >
>

Re: Usergrid Next Steps/Attic

[Michael Russo]

It's been a month with no replies. Anyone have
additional thoughts/proposals on the topic of moving Usergrid to the Attic?

-Michael R.

On Mon, May 10, 2021 at 10:06 AM Michael Russo 
wrote:

> Hi,
>
> In Aug 2018, a vote to move Usergrid to the Attic did not pass as there
> was interest in bringing contributions from a private fork back into the
> project. In Feb 2019, I asked the dev community for help to resolve some
> long standing issues. We haven't gotten consistent contributions to bring
> the project back to a healthy state. Now in 2021, Usergrid is essentially
> in the same state it was back in Aug 2018 but it's aged even more:
>
> 1. No activity on the mailing lists or JIRA
> 2. Usergrid still only supports Cassandra 1.x(unsupported) and
> Elasticsearch 1.7.x (EOL'd).
> https://github.com/apache/usergrid/tree/master/stack#requirements
> 3. Elasticsearch licensing has changed and there is a fair amount of
> effort required to ensure Usergrid stays within license on newer versions.
> See https://issues.apache.org/jira/browse/LEGAL-571.
> 4. Modernizing the deployment has not happened.
> (containerization/kubernetes, supporting more cloud providers than just
> AWS, etc.)
>
> We should again discuss the possibility about moving Usergrid to the Attic
> given that it's been 2.5 years with not much change. Thoughts?
>
> -Michael R.
>

Usergrid Next Steps/Attic

[Michael Russo]

Hi,

In Aug 2018, a vote to move Usergrid to the Attic did not pass as there was
interest in bringing contributions from a private fork back into the
project. In Feb 2019, I asked the dev community for help to resolve some
long standing issues. We haven't gotten consistent contributions to bring
the project back to a healthy state. Now in 2021, Usergrid is essentially
in the same state it was back in Aug 2018 but it's aged even more:

1. No activity on the mailing lists or JIRA
2. Usergrid still only supports Cassandra 1.x(unsupported) and
Elasticsearch 1.7.x (EOL'd).
https://github.com/apache/usergrid/tree/master/stack#requirements
3. Elasticsearch licensing has changed and there is a fair amount of effort
required to ensure Usergrid stays within license on newer versions. See
https://issues.apache.org/jira/browse/LEGAL-571.
4. Modernizing the deployment has not happened.
(containerization/kubernetes, supporting more cloud providers than just
AWS, etc.)

We should again discuss the possibility about moving Usergrid to the Attic
given that it's been 2.5 years with not much change. Thoughts?

-Michael R.

Re: Interest in taking over / helping resolve the following issues

[Michael Russo]

Rahul,

Your last email is a broken image (e.g. I think the image contents got
stripped).

On Fri, Apr 5, 2019 at 2:43 PM Rahul Singh 
wrote:

> [image: image.png]
>
>
> rahul.xavier.si...@gmail.com
>
> http://cassandra.link
>
> I'm speaking at #DataStaxAccelerate, the world’s premiere #ApacheCassandra
> conference, and I want to see you there! Use my code Singh50 for 50% off
> your registration. www.datastax.com/accelerate
>
>
> On Fri, Apr 5, 2019 at 5:36 PM Michael Russo 
> wrote:
>
>> Rahul,
>>
>> I added you to the Contributors roles for the Usergrid project in JIRA.
>> Can
>> you check if you have better access now?
>>
>> -Michael
>>
>> On Fri, Apr 5, 2019 at 2:16 PM Rahul Singh 
>> wrote:
>>
>> > Wierd. I'm logged in as me (xingh) but cannot seem to see any way to
>> assign
>> > it to myself. I can add comments, files ,etc.
>> >
>> >
>> >
>> > rahul.xavier.si...@gmail.com
>> >
>> > http://cassandra.link
>> >
>> > I'm speaking at #DataStaxAccelerate, the world’s premiere
>> #ApacheCassandra
>> > conference, and I want to see you there! Use my code Singh50 for 50% off
>> > your registration. www.datastax.com/accelerate
>> >
>> >
>> > On Fri, Apr 5, 2019 at 4:47 PM Keyur Karnik 
>> > wrote:
>> >
>> > > Rahul, you should be able to assign them to yourself as long as you
>> > create
>> > > an account.
>> > >
>> > > On Fri, Apr 5, 2019, 13:10 Rahul Singh 
>> > > wrote:
>> > >
>> > > > Can someone assign these tickets to me if no one else is working on
>> > them?
>> > > > rahul.xavier.si...@gmail.com
>> > > >
>> > > > http://cassandra.link
>> > > >
>> > > > I'm speaking at #DataStaxAccelerate, the world’s premiere
>> > > #ApacheCassandra
>> > > > conference, and I want to see you there! Use my code Singh50 for 50%
>> > off
>> > > > your registration. www.datastax.com/accelerate
>> > > >
>> > > >
>> > > > On Tue, Mar 5, 2019 at 11:56 PM Rahul Singh <
>> > > rahul.xavier.si...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > >
>> > > > > My username is "xingh" on the ASF Jira . I noticed there are lots
>> of
>> > > > items
>> > > > > in JIRA that could be set to "Done" since they are already merged.
>> > > > >
>> > > > > My goal is to get the velocity of issue resolution to released
>> build
>> > to
>> > > > be
>> > > > > consistent even if it's 1 issue a week, hopefully better than
>> that.
>> > > > >
>> > > > > Here's my short list of Issues / Epics that I can work on.
>> > > > >
>> > > > > RD.Usergrid.Issues
>> > > > >
>> > > > >- EPIC
>> > > > >   - https://issues.apache.org/jira/browse/USERGRID-932
>> > > > >- RELEASE
>> > > > >   -
>> > > > https://issues.apache.org/jira/projects/USERGRID/versions/12333013
>> > > > >  - https://issues.apache.org/jira/browse/USERGRID-1347
>> > > > >  - https://issues.apache.org/jira/browse/USERGRID-403
>> > > > >  - https://issues.apache.org/jira/browse/USERGRID-402
>> > > > >  - https://issues.apache.org/jira/browse/USERGRID-557
>> > > > >  - https://issues.apache.org/jira/browse/USERGRID-1249
>> > > > >   - ISSUES
>> > > > >   - https://issues.apache.org/jira/browse/USERGRID-946
>> > > > >   - https://issues.apache.org/jira/browse/USERGRID-1262
>> > > > >   - https://issues.apache.org/jira/browse/USERGRID-134
>> > > > >   - https://issues.apache.org/jira/browse/USERGRID-497
>> > > > >   - https://issues.apache.org/jira/browse/USERGRID-167
>> > > > >   - https://issues.apache.org/jira/browse/USERGRID-951
>> > > > >   - https://issues.apache.org/jira/browse/USERGRID-56
>> > > > >   - https://issues.apache.org/jira/browse/USERGRID-369
>> > > > >   - https://issues.apache.org/jira/browse/USERGRID-841
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>

Re: Interest in taking over / helping resolve the following issues

[Michael Russo]

Rahul,

I added you to the Contributors roles for the Usergrid project in JIRA. Can
you check if you have better access now?

-Michael

On Fri, Apr 5, 2019 at 2:16 PM Rahul Singh 
wrote:

> Wierd. I'm logged in as me (xingh) but cannot seem to see any way to assign
> it to myself. I can add comments, files ,etc.
>
>
>
> rahul.xavier.si...@gmail.com
>
> http://cassandra.link
>
> I'm speaking at #DataStaxAccelerate, the world’s premiere #ApacheCassandra
> conference, and I want to see you there! Use my code Singh50 for 50% off
> your registration. www.datastax.com/accelerate
>
>
> On Fri, Apr 5, 2019 at 4:47 PM Keyur Karnik 
> wrote:
>
> > Rahul, you should be able to assign them to yourself as long as you
> create
> > an account.
> >
> > On Fri, Apr 5, 2019, 13:10 Rahul Singh 
> > wrote:
> >
> > > Can someone assign these tickets to me if no one else is working on
> them?
> > > rahul.xavier.si...@gmail.com
> > >
> > > http://cassandra.link
> > >
> > > I'm speaking at #DataStaxAccelerate, the world’s premiere
> > #ApacheCassandra
> > > conference, and I want to see you there! Use my code Singh50 for 50%
> off
> > > your registration. www.datastax.com/accelerate
> > >
> > >
> > > On Tue, Mar 5, 2019 at 11:56 PM Rahul Singh <
> > rahul.xavier.si...@gmail.com>
> > > wrote:
> > >
> > > >
> > > > My username is "xingh" on the ASF Jira . I noticed there are lots of
> > > items
> > > > in JIRA that could be set to "Done" since they are already merged.
> > > >
> > > > My goal is to get the velocity of issue resolution to released build
> to
> > > be
> > > > consistent even if it's 1 issue a week, hopefully better than that.
> > > >
> > > > Here's my short list of Issues / Epics that I can work on.
> > > >
> > > > RD.Usergrid.Issues
> > > >
> > > >- EPIC
> > > >   - https://issues.apache.org/jira/browse/USERGRID-932
> > > >- RELEASE
> > > >   -
> > > https://issues.apache.org/jira/projects/USERGRID/versions/12333013
> > > >  - https://issues.apache.org/jira/browse/USERGRID-1347
> > > >  - https://issues.apache.org/jira/browse/USERGRID-403
> > > >  - https://issues.apache.org/jira/browse/USERGRID-402
> > > >  - https://issues.apache.org/jira/browse/USERGRID-557
> > > >  - https://issues.apache.org/jira/browse/USERGRID-1249
> > > >   - ISSUES
> > > >   - https://issues.apache.org/jira/browse/USERGRID-946
> > > >   - https://issues.apache.org/jira/browse/USERGRID-1262
> > > >   - https://issues.apache.org/jira/browse/USERGRID-134
> > > >   - https://issues.apache.org/jira/browse/USERGRID-497
> > > >   - https://issues.apache.org/jira/browse/USERGRID-167
> > > >   - https://issues.apache.org/jira/browse/USERGRID-951
> > > >   - https://issues.apache.org/jira/browse/USERGRID-56
> > > >   - https://issues.apache.org/jira/browse/USERGRID-369
> > > >   - https://issues.apache.org/jira/browse/USERGRID-841
> > > >
> > > >
> > >
> >
>

new committer: Keyur Karnik

[Michael Russo]

The Project Management Committee (PMC) for Apache Usergrid
has invited Keyur Karnik to become a committer and we are pleased
to announce that he has accepted.

Keyur has been actively contributing to Usergrid, helping the project get
to a better state.

Commits: https://github.com/apache/usergrid/commits?author=keyurkarnik
  - These include new features, test stability, and bufixes.

Mailing List:
https://lists.apache.org/list.html?*@usergrid.apache.org:lte=1M:keyur
  - Recent volunteer for setting up Jenkins CI integration for the project.

Being a committer enables easier contribution to the
project since there is no need to go via the patch
submission process. This should enable better productivity.
Being a PMC member enables assistance with the management
and to guide the direction of the project.

 Welcome Keyur!

Getting Usergrid to a Better Stable State

[Michael Russo]

Happy New Year Everyone!

There are a handful of items that make contributing to/using Usergrid more
difficult. I'm emailing to see if we can get some volunteers for tackling
each of these items.

1. We have one unsigned binary. I believe it was released back in 2016.
Either this binary is not needed it needs signed.
https://checker.apache.org/projs/usergrid.html

2. The community website page that loads some google map is no longer
working: http://usergrid.apache.org/community/. I just see an error
message: "Oops! Something went wrong."

3. It would be good if we could leverage ASF Jenkins infrastructure to get
some builds going, nightly or otherwise. Does anyone have time to set this
up and see if there is an integration with Github/Gitbox for running tests
upon PR creation? https://cwiki.apache.org/confluence/display/INFRA/Jenkins

4. We should consider doing another release v2.2.0. The current master
branch has many fixes on top of v2.1.0. Does anyone have cycles to lead the
effort of getting a new release out there?

Thanks in advance. If you have some cycles to help, just mail back on this
thread and confirm. I can help too, but wanted to email the community
first.

Thanks.
Michael R.

Re: [RESULT] Move usergrid repos to gitbox.apache.org

[Michael Russo]

To close this out, the migration to gitbox is completed.

Committers: You can update your Apache git remote URLs to
https://gitbox.apache.org/repos/asf/usergrid.git   (previously
https://git-wip-us.apache.org/repos/asf/usergrid.git)

Also, to take advantage of working directly from Github, your Github
account will need to be linked to Apache. Visit
https://gitbox.apache.org/setup.

Thanks.
-Michael

On Sun, Jan 6, 2019 at 4:03 PM Michael Russo 
wrote:

> The vote has passed and I've opened
> https://issues.apache.org/jira/browse/INFRA-17568.
>
> On Thu, Jan 3, 2019 at 11:10 AM Rod Simpson  wrote:
>
>> +1
>>
>> On Thu, Jan 3, 2019, 11:19 AM Dave >
>> > +1
>> >
>> > Finally, Usergrid committers will be able to merge GitHub PRs with the
>> > click of a button.
>> >
>> > On Thu, Jan 3, 2019 at 12:07 PM Michael Russo 
>> > wrote:
>> >
>> > > Hi All,
>> > >
>> > > Given the recent notices from Apache Infra team, I'm proposing that
>> we go
>> > > ahead and migrate all of the usergrid repos to gitbox.apache.org
>> before
>> > > the
>> > > forced migration. This will not change community
>> contribution/interaction
>> > > via Github. See the notice email
>> > > <
>> > >
>> >
>> https://lists.apache.org/thread.html/b9ab62075cc7fcb8ee0c2c0b1d4c39f2ae5918bd4c041dc9bf8350ef@%3Cdev.usergrid.apache.org%3E
>> > > >for
>> > > more details.
>> > >
>> > > Please vote on the early migration.
>> > >
>> > > The vote will be open for 72 hours.
>> > > [ ] +1 Go ahead with the move to gitbox
>> > > [ ] +0 no opinion
>> > > [ ] -1 Do not migrate early to gitbox because ...
>> > >
>> > > Thanks.
>> > > -Michael
>> > >
>> >
>>
>

[RESULT] Move usergrid repos to gitbox.apache.org

[Michael Russo]

The vote has passed and I've opened
https://issues.apache.org/jira/browse/INFRA-17568.

On Thu, Jan 3, 2019 at 11:10 AM Rod Simpson  wrote:

> +1
>
> On Thu, Jan 3, 2019, 11:19 AM Dave 
> > +1
> >
> > Finally, Usergrid committers will be able to merge GitHub PRs with the
> > click of a button.
> >
> > On Thu, Jan 3, 2019 at 12:07 PM Michael Russo 
> > wrote:
> >
> > > Hi All,
> > >
> > > Given the recent notices from Apache Infra team, I'm proposing that we
> go
> > > ahead and migrate all of the usergrid repos to gitbox.apache.org
> before
> > > the
> > > forced migration. This will not change community
> contribution/interaction
> > > via Github. See the notice email
> > > <
> > >
> >
> https://lists.apache.org/thread.html/b9ab62075cc7fcb8ee0c2c0b1d4c39f2ae5918bd4c041dc9bf8350ef@%3Cdev.usergrid.apache.org%3E
> > > >for
> > > more details.
> > >
> > > Please vote on the early migration.
> > >
> > > The vote will be open for 72 hours.
> > > [ ] +1 Go ahead with the move to gitbox
> > > [ ] +0 no opinion
> > > [ ] -1 Do not migrate early to gitbox because ...
> > >
> > > Thanks.
> > > -Michael
> > >
> >
>

[VOTE] Move usergrid repos to gitbox.apache.org

[Michael Russo]

Hi All,

Given the recent notices from Apache Infra team, I'm proposing that we go
ahead and migrate all of the usergrid repos to gitbox.apache.org before the
forced migration. This will not change community contribution/interaction
via Github. See the notice email
for
more details.

Please vote on the early migration.

The vote will be open for 72 hours.
[ ] +1 Go ahead with the move to gitbox
[ ] +0 no opinion
[ ] -1 Do not migrate early to gitbox because ...

Thanks.
-Michael

[jira] [Assigned] (USERGRID-1348) Fix ignored test in CollectionDeleteTest

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo reassigned USERGRID-1348:
---

Assignee: Keyur Karnik

> Fix ignored test in CollectionDeleteTest
> 
>
> Key: USERGRID-1348
> URL: https://issues.apache.org/jira/browse/USERGRID-1348
> Project: Usergrid
>  Issue Type: Bug
>  Components: Stack
>Affects Versions: 2.2.0
>Reporter: Keyur Karnik
>Assignee: Keyur Karnik
>Priority: Minor
> Fix For: 2.2.0
>
>
> The CollectionDeleteTest has been ignored with a "fix later" comment. This 
> test fails sporadically and will require some debugging.
> This should not affect actual functionality as Collection Delete has been 
> tested and found working.
> Ref :
> https://github.com/apache/usergrid/blob/3c31713fe366d446c0b1bacd2b89dd3c5eed8db8/stack/core/src/test/java/org/apache/usergrid/persistence/CollectionDeleteTest.java#L46



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Moving Usergrid to the Attic

[Michael Russo]

-1 vote

It looks like there are some fresh contributions coming to Usergrid (new
posting to the dev mailing list). I'll also contribute by reviewing some of
the upcoming pull requests.

Michael Russo |  Software Engineer |  russomich...@google.com |  +1 (650)
946-8608


On Mon, Aug 20, 2018 at 5:22 PM Ed Anuff  wrote:

> Sounds like there are some incoming pull requests coming shortly (upgrading
> C* and ES).  Should know more in a day or so.
>
> Ed
>
> On Mon, Aug 20, 2018 at 9:17 AM, Todd Nine  wrote:
>
> > Hey all,
> >
> > Following the process outlined here,
> https://attic.apache.org/process.html
> > ,
> > I'm calling a vote for us to move Usergrid to the Attic.
> >
> > We appealed to the user community for contributions before our last board
> > report, however no contributions have occurred over the last 3 months.
> > Given this is the case, I'm calling a vote to move Usergrid to the Attic.
> >
> > This vote will close 72 hours from now on 2018-08-23 10:00 MDT
> >
> > +1 Move to the Attic
> >
> > Todd
> >
>

Re: [VOTE] Moving Usergrid to the Attic

[Michael Russo]

-1 vote

It looks like there are some fresh contributions coming to Usergrid (new
posting to the dev mailing list). I'll also contribute by reviewing some of
the upcoming pull requests.

-Michael

On Mon, Aug 20, 2018 at 5:22 PM Ed Anuff  wrote:

> Sounds like there are some incoming pull requests coming shortly (upgrading
> C* and ES).  Should know more in a day or so.
>
> Ed
>
> On Mon, Aug 20, 2018 at 9:17 AM, Todd Nine  wrote:
>
> > Hey all,
> >
> > Following the process outlined here,
> https://attic.apache.org/process.html
> > ,
> > I'm calling a vote for us to move Usergrid to the Attic.
> >
> > We appealed to the user community for contributions before our last board
> > report, however no contributions have occurred over the last 3 months.
> > Given this is the case, I'm calling a vote to move Usergrid to the Attic.
> >
> > This vote will close 72 hours from now on 2018-08-23 10:00 MDT
> >
> > +1 Move to the Attic
> >
> > Todd
> >
>

[jira] [Closed] (USERGRID-1338) Email addresses or usernames with + character do not appear in search results for users

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-1338.
---

> Email addresses or usernames with + character do not appear in search results 
> for users
> ---
>
> Key: USERGRID-1338
> URL: https://issues.apache.org/jira/browse/USERGRID-1338
> Project: Usergrid
>  Issue Type: Bug
>  Components: Portal, Stack
>Affects Versions: 2.2.0
>Reporter: Brandon Shelley
>Assignee: Michael Russo
> Fix For: 2.2.0
>
>
> Both the new Edge UI, and API calls to email addresses or usernames with + in 
> the string return no results. It appears the character is being stripped out 
> and replaced with a space.
> Tests, where both username and email address are set to 
> 'brandon+...@mydomain.com':
> GET https://apibaas-trial.apigee.net/org/app/users/?ql=select * where 
> username='brandon+...@mydomain.com'
> GET https://apibaas-trial.apigee.net/org/app/users/?ql=select * where 
> email='brandon+...@mydomain.com'
> {code}
> {
>   "action": "get",
>   "params": {
> "ql": [
>   "select * where email='brandon r...@mydomain.com'"
> ]
>   },
>   "path": "/users",
>   "uri": "https://apibaas-trial.apigee.net/org/app/users;,
>   "entities": [],
>   "timestamp": 1488398745552,
>   "duration": 40,
>   "organization": "org",
>   "applicationName": "global",
>   "count": 0
> }
> {code}
> I tried working around this by url-encoding the + character to %2b, but while 
> the response shows the character correctly, there are still no results found:
> {code}
> "params": {
> "ql": [
>   "select * where email = 'brandon+...@mydomain.com'"
> ]
>   },
> {code}
> There are two workarounds so far:
> 1. access the user entity directly through the / notation:
> [baasurl]/users/brandon+...@mydomain.com
> 2. URLencode the '+' char manually in the UI to '%2b'. The ui then encodes 
> this again into '%252b', and can then retrieve the correct entity



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (USERGRID-29) We don't seem to be parsing '++' correctly

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-29.
-

> We don't seem to be parsing '++' correctly
> --
>
> Key: USERGRID-29
> URL: https://issues.apache.org/jira/browse/USERGRID-29
> Project: Usergrid
>  Issue Type: Bug
>  Components: Stack
>Affects Versions: 2.1.0, 1.0.3
>Reporter: Rod Simpson
>    Assignee: Michael Russo
> Fix For: 2.2.0
>
>
> "I have made a simple app to test Usergrid's capabilities and I'm having 
> trouble with updating entities that contain html entities. 
> i.e. I add C++ as an entity in a collection called language and I also have C 
> in the collection too. Whenever I try to update C++, which I grab via a 
> collection query 
> ""select * where owned='testuser' and lang='C++'"" 
> I get back the C entity. 
> I have tried encoding the strings , but C%2B%2B 
> gets double encoded to C%252B%252B 
> This a typical call it makes without me trying to encode anything: 
> https://api.usergrid.com/clydebyrdiii... 
> Although it seems to encode correctly it returns the entity with lang='C' and 
> not 
> lang='C++'; 
> And confirmed by Scott: 
> Nope. If I create an entity with an attribute = 'c++', I can find it by 
> querying for: 'c*' but not for 'c' or 'c+++'. 
> "



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (USERGRID-29) We don't seem to be parsing '++' correctly

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-29:
--
Fix Version/s: 2.2.0

> We don't seem to be parsing '++' correctly
> --
>
> Key: USERGRID-29
> URL: https://issues.apache.org/jira/browse/USERGRID-29
> Project: Usergrid
>  Issue Type: Bug
>  Components: Stack
>Affects Versions: 2.1.0, 1.0.3
>Reporter: Rod Simpson
>    Assignee: Michael Russo
> Fix For: 2.2.0
>
>
> "I have made a simple app to test Usergrid's capabilities and I'm having 
> trouble with updating entities that contain html entities. 
> i.e. I add C++ as an entity in a collection called language and I also have C 
> in the collection too. Whenever I try to update C++, which I grab via a 
> collection query 
> ""select * where owned='testuser' and lang='C++'"" 
> I get back the C entity. 
> I have tried encoding the strings , but C%2B%2B 
> gets double encoded to C%252B%252B 
> This a typical call it makes without me trying to encode anything: 
> https://api.usergrid.com/clydebyrdiii... 
> Although it seems to encode correctly it returns the entity with lang='C' and 
> not 
> lang='C++'; 
> And confirmed by Scott: 
> Nope. If I create an entity with an attribute = 'c++', I can find it by 
> querying for: 'c*' but not for 'c' or 'c+++'. 
> "



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (USERGRID-1041) Implement means of escaping single-quote characters in ql

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo resolved USERGRID-1041.
-
   Resolution: Fixed
Fix Version/s: 2.2.0

> Implement means of escaping single-quote characters in ql
> -
>
> Key: USERGRID-1041
> URL: https://issues.apache.org/jira/browse/USERGRID-1041
> Project: Usergrid
>  Issue Type: Improvement
>Affects Versions: 2.1.0
>Reporter: Brandon Shelley
>    Assignee: Michael Russo
>Priority: Minor
> Fix For: 2.2.0
>
>
> Given the entity:
> {code}{
> "title": "Charlotte's Web"
> }{code}
> These queries do not return any results:
> {code}?ql=select * where title='Charlotte's Web'
> ?ql=select * where title='Charlotte%27s Web'{code}
> We should support a means of escaping ' characters in text. Possible 
> solutions:
> - Using a backslash to denote escaped quotes
> - Support alternative delimiters in the query
> - Decode hex % encoded characters (but then what do we do for string 
> literals?)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (USERGRID-1041) Implement means of escaping single-quote characters in ql

[Michael Russo (JIRA)]

[ 
https://issues.apache.org/jira/browse/USERGRID-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15939893#comment-15939893
 ] 

Michael Russo commented on USERGRID-1041:
-

Fixed by allowing a backslash to escape.  In fact, the query parser handled 
this correctly, but later in the execution the escaping backslash was left in 
the literal string when querying the index.  Fixed that issue as part of this 
commit:

https://github.com/apache/usergrid/commit/89178326debbd82660f9f2691b3b8cf06d847d4a

Queries with single quotes in the value will now look like the following and 
correctly find the value:

{code}?ql=select * where title='Charlotte\'s Web'{code} 


> Implement means of escaping single-quote characters in ql
> -
>
> Key: USERGRID-1041
> URL: https://issues.apache.org/jira/browse/USERGRID-1041
> Project: Usergrid
>  Issue Type: Improvement
>Affects Versions: 2.1.0
>Reporter: Brandon Shelley
>    Assignee: Michael Russo
>Priority: Minor
> Fix For: 2.2.0
>
>
> Given the entity:
> {code}{
> "title": "Charlotte's Web"
> }{code}
> These queries do not return any results:
> {code}?ql=select * where title='Charlotte's Web'
> ?ql=select * where title='Charlotte%27s Web'{code}
> We should support a means of escaping ' characters in text. Possible 
> solutions:
> - Using a backslash to denote escaped quotes
> - Support alternative delimiters in the query
> - Decode hex % encoded characters (but then what do we do for string 
> literals?)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (USERGRID-1041) Implement means of escaping single-quote characters in ql

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-1041.
---

> Implement means of escaping single-quote characters in ql
> -
>
> Key: USERGRID-1041
> URL: https://issues.apache.org/jira/browse/USERGRID-1041
> Project: Usergrid
>  Issue Type: Improvement
>Affects Versions: 2.1.0
>Reporter: Brandon Shelley
>    Assignee: Michael Russo
>Priority: Minor
> Fix For: 2.2.0
>
>
> Given the entity:
> {code}{
> "title": "Charlotte's Web"
> }{code}
> These queries do not return any results:
> {code}?ql=select * where title='Charlotte's Web'
> ?ql=select * where title='Charlotte%27s Web'{code}
> We should support a means of escaping ' characters in text. Possible 
> solutions:
> - Using a backslash to denote escaped quotes
> - Support alternative delimiters in the query
> - Decode hex % encoded characters (but then what do we do for string 
> literals?)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (USERGRID-1041) Implement means of escaping single-quote characters in ql

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo reassigned USERGRID-1041:
---

Assignee: Michael Russo

> Implement means of escaping single-quote characters in ql
> -
>
> Key: USERGRID-1041
> URL: https://issues.apache.org/jira/browse/USERGRID-1041
> Project: Usergrid
>  Issue Type: Improvement
>Affects Versions: 2.1.0
>Reporter: Brandon Shelley
>    Assignee: Michael Russo
>Priority: Minor
>
> Given the entity:
> {code}{
> "title": "Charlotte's Web"
> }{code}
> These queries do not return any results:
> {code}?ql=select * where title='Charlotte's Web'
> ?ql=select * where title='Charlotte%27s Web'{code}
> We should support a means of escaping ' characters in text. Possible 
> solutions:
> - Using a backslash to denote escaped quotes
> - Support alternative delimiters in the query
> - Decode hex % encoded characters (but then what do we do for string 
> literals?)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (USERGRID-1117) Allow apostrophe characters in email addresses

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-1117.
---

> Allow apostrophe characters in email addresses
> --
>
> Key: USERGRID-1117
> URL: https://issues.apache.org/jira/browse/USERGRID-1117
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Reporter: David Johnson
>    Assignee: Michael Russo
>Priority: Trivial
> Fix For: 2.2.0
>
>
> And when you do, un-ignore this test:
> AdminEmailEncodingIT.getTokenQuote()



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (USERGRID-1117) Allow apostrophe characters in email addresses

[Michael Russo (JIRA)]

[ 
https://issues.apache.org/jira/browse/USERGRID-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15939889#comment-15939889
 ] 

Michael Russo commented on USERGRID-1117:
-

https://github.com/apache/usergrid/commit/89178326debbd82660f9f2691b3b8cf06d847d4a

> Allow apostrophe characters in email addresses
> --
>
> Key: USERGRID-1117
> URL: https://issues.apache.org/jira/browse/USERGRID-1117
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Reporter: David Johnson
>    Assignee: Michael Russo
>Priority: Trivial
> Fix For: 2.2.0
>
>
> And when you do, un-ignore this test:
> AdminEmailEncodingIT.getTokenQuote()



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (USERGRID-1117) Allow apostrophe characters in email addresses

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo reassigned USERGRID-1117:
---

Assignee: Michael Russo

> Allow apostrophe characters in email addresses
> --
>
> Key: USERGRID-1117
> URL: https://issues.apache.org/jira/browse/USERGRID-1117
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Reporter: David Johnson
>    Assignee: Michael Russo
>Priority: Trivial
> Fix For: 2.2.0
>
>
> And when you do, un-ignore this test:
> AdminEmailEncodingIT.getTokenQuote()



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (USERGRID-1338) Email addresses or usernames with + character do not appear in search results for users

[Michael Russo (JIRA)]

[ 
https://issues.apache.org/jira/browse/USERGRID-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15939890#comment-15939890
 ] 

Michael Russo commented on USERGRID-1338:
-

https://github.com/apache/usergrid/commit/89178326debbd82660f9f2691b3b8cf06d847d4a

> Email addresses or usernames with + character do not appear in search results 
> for users
> ---
>
> Key: USERGRID-1338
> URL: https://issues.apache.org/jira/browse/USERGRID-1338
> Project: Usergrid
>  Issue Type: Bug
>  Components: Portal, Stack
>Affects Versions: 2.2.0
>Reporter: Brandon Shelley
>Assignee: Michael Russo
> Fix For: 2.2.0
>
>
> Both the new Edge UI, and API calls to email addresses or usernames with + in 
> the string return no results. It appears the character is being stripped out 
> and replaced with a space.
> Tests, where both username and email address are set to 
> 'brandon+...@mydomain.com':
> GET https://apibaas-trial.apigee.net/org/app/users/?ql=select * where 
> username='brandon+...@mydomain.com'
> GET https://apibaas-trial.apigee.net/org/app/users/?ql=select * where 
> email='brandon+...@mydomain.com'
> {code}
> {
>   "action": "get",
>   "params": {
> "ql": [
>   "select * where email='brandon r...@mydomain.com'"
> ]
>   },
>   "path": "/users",
>   "uri": "https://apibaas-trial.apigee.net/org/app/users;,
>   "entities": [],
>   "timestamp": 1488398745552,
>   "duration": 40,
>   "organization": "org",
>   "applicationName": "global",
>   "count": 0
> }
> {code}
> I tried working around this by url-encoding the + character to %2b, but while 
> the response shows the character correctly, there are still no results found:
> {code}
> "params": {
> "ql": [
>   "select * where email = 'brandon+...@mydomain.com'"
> ]
>   },
> {code}
> There are two workarounds so far:
> 1. access the user entity directly through the / notation:
> [baasurl]/users/brandon+...@mydomain.com
> 2. URLencode the '+' char manually in the UI to '%2b'. The ui then encodes 
> this again into '%252b', and can then retrieve the correct entity



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (USERGRID-1338) Email addresses or usernames with + character do not appear in search results for users

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo reassigned USERGRID-1338:
---

Assignee: Michael Russo

> Email addresses or usernames with + character do not appear in search results 
> for users
> ---
>
> Key: USERGRID-1338
> URL: https://issues.apache.org/jira/browse/USERGRID-1338
> Project: Usergrid
>  Issue Type: Bug
>  Components: Portal, Stack
>Affects Versions: 2.2.0
>Reporter: Brandon Shelley
>Assignee: Michael Russo
> Fix For: 2.2.0
>
>
> Both the new Edge UI, and API calls to email addresses or usernames with + in 
> the string return no results. It appears the character is being stripped out 
> and replaced with a space.
> Tests, where both username and email address are set to 
> 'brandon+...@mydomain.com':
> GET https://apibaas-trial.apigee.net/org/app/users/?ql=select * where 
> username='brandon+...@mydomain.com'
> GET https://apibaas-trial.apigee.net/org/app/users/?ql=select * where 
> email='brandon+...@mydomain.com'
> {code}
> {
>   "action": "get",
>   "params": {
> "ql": [
>   "select * where email='brandon r...@mydomain.com'"
> ]
>   },
>   "path": "/users",
>   "uri": "https://apibaas-trial.apigee.net/org/app/users;,
>   "entities": [],
>   "timestamp": 1488398745552,
>   "duration": 40,
>   "organization": "org",
>   "applicationName": "global",
>   "count": 0
> }
> {code}
> I tried working around this by url-encoding the + character to %2b, but while 
> the response shows the character correctly, there are still no results found:
> {code}
> "params": {
> "ql": [
>   "select * where email = 'brandon+...@mydomain.com'"
> ]
>   },
> {code}
> There are two workarounds so far:
> 1. access the user entity directly through the / notation:
> [baasurl]/users/brandon+...@mydomain.com
> 2. URLencode the '+' char manually in the UI to '%2b'. The ui then encodes 
> this again into '%252b', and can then retrieve the correct entity



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (USERGRID-1341) Application Queue Manager for Push using Wrong Cache Type

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-1341.
---

> Application Queue Manager for Push using Wrong Cache Type
> -
>
> Key: USERGRID-1341
> URL: https://issues.apache.org/jira/browse/USERGRID-1341
> Project: Usergrid
>  Issue Type: Bug
>    Reporter: Michael Russo
>    Assignee: Michael Russo
> Fix For: 2.2.0
>
>
> The cache is using expireAfterWrite and it should be expireAfterAccess:
> org/apache/usergrid/services/notifications/ApplicationQueueManagerCache.java:65



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (USERGRID-1341) Application Queue Manager for Push using Wrong Cache Type

[Michael Russo (JIRA)]

Michael Russo created USERGRID-1341:
---

 Summary: Application Queue Manager for Push using Wrong Cache Type
 Key: USERGRID-1341
 URL: https://issues.apache.org/jira/browse/USERGRID-1341
 Project: Usergrid
  Issue Type: Bug
Reporter: Michael Russo
Assignee: Michael Russo
 Fix For: 2.2.0


The cache is using expireAfterWrite and it should be expireAfterAccess:

org/apache/usergrid/services/notifications/ApplicationQueueManagerCache.java:65



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (USERGRID-1170) [IRT] Test location query on non-root attribute

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1170:

Fix Version/s: 2.2.0

> [IRT] Test location query on non-root attribute
> ---
>
> Key: USERGRID-1170
> URL: https://issues.apache.org/jira/browse/USERGRID-1170
> Project: Usergrid
>  Issue Type: Story
>Reporter: Jeffrey 
>  Labels: integration-rest-tests
> Fix For: 2.2.0
>
>
> select * where x.y.z.location within d of x,y
> Load 3 entities
> Test:
> 1) entities within specified distance are included and others are not.  
> ensure correct level of precision or document rounding.
> 2) test 'not' condition
> 3) test paging
> {
>   "x": {
> "y": {
>   "z": {
> "location": {
>   "lat": 1.0,
>   "lon": 2.0
> }
>   }
> }
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (USERGRID-1170) [IRT] Test location query on non-root attribute

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-1170.
---

> [IRT] Test location query on non-root attribute
> ---
>
> Key: USERGRID-1170
> URL: https://issues.apache.org/jira/browse/USERGRID-1170
> Project: Usergrid
>  Issue Type: Story
>Reporter: Jeffrey 
>  Labels: integration-rest-tests
> Fix For: 2.2.0
>
>
> select * where x.y.z.location within d of x,y
> Load 3 entities
> Test:
> 1) entities within specified distance are included and others are not.  
> ensure correct level of precision or document rounding.
> 2) test 'not' condition
> 3) test paging
> {
>   "x": {
> "y": {
>   "z": {
> "location": {
>   "lat": 1.0,
>   "lon": 2.0
> }
>   }
> }
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (USERGRID-1170) [IRT] Test location query on non-root attribute

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo resolved USERGRID-1170.
-
Resolution: Fixed

> [IRT] Test location query on non-root attribute
> ---
>
> Key: USERGRID-1170
> URL: https://issues.apache.org/jira/browse/USERGRID-1170
> Project: Usergrid
>  Issue Type: Story
>Reporter: Jeffrey 
>  Labels: integration-rest-tests
>
> select * where x.y.z.location within d of x,y
> Load 3 entities
> Test:
> 1) entities within specified distance are included and others are not.  
> ensure correct level of precision or document rounding.
> 2) test 'not' condition
> 3) test paging
> {
>   "x": {
> "y": {
>   "z": {
> "location": {
>   "lat": 1.0,
>   "lon": 2.0
> }
>   }
> }
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (USERGRID-1170) [IRT] Test location query on non-root attribute

[Michael Russo (JIRA)]

[ 
https://issues.apache.org/jira/browse/USERGRID-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15883687#comment-15883687
 ] 

Michael Russo commented on USERGRID-1170:
-

org.apache.usergrid.rest.applications.queries.GeoPagingTest
org.apache.usergrid.rest.applications.queries.GeoPagingTest#groupQueriesWithGeoPaging

> [IRT] Test location query on non-root attribute
> ---
>
> Key: USERGRID-1170
> URL: https://issues.apache.org/jira/browse/USERGRID-1170
> Project: Usergrid
>  Issue Type: Story
>Reporter: Jeffrey 
>  Labels: integration-rest-tests
> Fix For: 2.2.0
>
>
> select * where x.y.z.location within d of x,y
> Load 3 entities
> Test:
> 1) entities within specified distance are included and others are not.  
> ensure correct level of precision or document rounding.
> 2) test 'not' condition
> 3) test paging
> {
>   "x": {
> "y": {
>   "z": {
> "location": {
>   "lat": 1.0,
>   "lon": 2.0
> }
>   }
> }
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (USERGRID-1336) Implement a query analyzer

[Michael Russo (JIRA)]

[ 
https://issues.apache.org/jira/browse/USERGRID-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15883679#comment-15883679
 ] 

Michael Russo commented on USERGRID-1336:
-

https://github.com/apache/usergrid/pull/567

> Implement a query analyzer
> --
>
> Key: USERGRID-1336
> URL: https://issues.apache.org/jira/browse/USERGRID-1336
> Project: Usergrid
>  Issue Type: Story
>    Reporter: Michael Russo
>    Assignee: Michael Russo
>
> Implement a query analyzer such that the following things can be taken into 
> consideration based on applicatino set limits:
> size of collection (in count of entities and total bytes)
> size of index (total bytes)
> number of query operands
> number of query sort predicates
> If one exceeds the limit, mark it as a violation.
> The initial approach for this will be log only such that we can alert based 
> on logs if something extremely abnormal is detected.  Also provide the client 
> a new queryparam "analyzeOnly" so that for any existing query, they can run 
> this and get back the warnings without having the query execute against 
> Elasticsearch.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (USERGRID-516) BaaS Queries returning Entities which do not match the input Query

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-516.
--

> BaaS Queries returning Entities which do not match the input Query
> --
>
> Key: USERGRID-516
> URL: https://issues.apache.org/jira/browse/USERGRID-516
> Project: Usergrid
>  Issue Type: Bug
>Reporter: Jeffrey 
>Assignee: Jeffrey 
>
> Error



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (USERGRID-221) Fix query-validator in 2.1

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo resolved USERGRID-221.

Resolution: Fixed

> Fix query-validator in 2.1
> --
>
> Key: USERGRID-221
> URL: https://issues.apache.org/jira/browse/USERGRID-221
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Reporter: David Johnson
>Priority: Minor
>
> Fix query-validator in two-dot-o branch and then add it back to the 
> stack/pom.xml build file.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (USERGRID-221) Fix query-validator in 2.1

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-221.
--

> Fix query-validator in 2.1
> --
>
> Key: USERGRID-221
> URL: https://issues.apache.org/jira/browse/USERGRID-221
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Reporter: David Johnson
>Priority: Minor
>
> Fix query-validator in two-dot-o branch and then add it back to the 
> stack/pom.xml build file.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (USERGRID-1336) Implement a query analyzer

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1336:

Sprint: Usergrid 36

> Implement a query analyzer
> --
>
> Key: USERGRID-1336
> URL: https://issues.apache.org/jira/browse/USERGRID-1336
> Project: Usergrid
>  Issue Type: Story
>    Reporter: Michael Russo
>    Assignee: Michael Russo
>
> Implement a query analyzer such that the following things can be taken into 
> consideration based on applicatino set limits:
> size of collection (in count of entities and total bytes)
> size of index (total bytes)
> number of query operands
> number of query sort predicates
> If one exceeds the limit, mark it as a violation.
> The initial approach for this will be log only such that we can alert based 
> on logs if something extremely abnormal is detected.  Also provide the client 
> a new queryparam "analyzeOnly" so that for any existing query, they can run 
> this and get back the warnings without having the query execute against 
> Elasticsearch.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (USERGRID-1336) Implement a query analyzer

[Michael Russo (JIRA)]

Michael Russo created USERGRID-1336:
---

 Summary: Implement a query analyzer
 Key: USERGRID-1336
 URL: https://issues.apache.org/jira/browse/USERGRID-1336
 Project: Usergrid
  Issue Type: Story
Reporter: Michael Russo
Assignee: Michael Russo


Implement a query analyzer such that the following things can be taken into 
consideration based on applicatino set limits:

size of collection (in count of entities and total bytes)
size of index (total bytes)
number of query operands
number of query sort predicates

If one exceeds the limit, mark it as a violation.

The initial approach for this will be log only such that we can alert based on 
logs if something extremely abnormal is detected.  Also provide the client a 
new queryparam "analyzeOnly" so that for any existing query, they can run this 
and get back the warnings without having the query execute against 
Elasticsearch.





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [DRAFT] Usergrid Report

[Michael Russo]

It's optional and I think the configuration will still default to in memory
queuing in the next release since it's so new.  We built Qakka within the
corepersistence libraries so it can run embedded in Usergrid or as a
standalone service with a http API. Typical Usergrid deployments will use
it embedded to prevent the need for deploying another standalone service.

On Sun, Feb 12, 2017 at 09:58 Todd Nine <todd.n...@gmail.com> wrote:

> Sounds good.  I'll update the report accordingly.  On the Qakka
> implementation, is that something that will remain in beta as an optional
> component on the next release, or is that a separate deployment as a
> service?
>
>
>
> On Sun, Feb 12, 2017 at 9:43 AM Michael Russo <mru...@apache.org> wrote:
>
> > Multi region queueing with Akka hasn't been released yet, it's just
> > available in the master branch. Let's update that if it's not too late.
> >
> > We need to do another release soon as there's a good handful of changes
> > since 2.1.0 that will benefit everyone.
> >
> >
> > On Sun, Feb 12, 2017 at 04:11 John D. Ament <johndam...@apache.org>
> wrote:
> >
> > > Last release is listed as a year ago, but this comment appears:
> > >
> > > The multi-region queueing via Akka (Qakka), has been released (Thanks
> > > Dave for this).
> > >
> > > How was this released?
> > >
> > > On Sat, Feb 11, 2017 at 8:59 PM Todd Nine <todd.n...@gmail.com> wrote:
> > >
> > > > Hey all,
> > > >   Below is the Usergrid report.  Sorry for the short notice, I need
> to
> > > get
> > > > it in tomorrow morning. If you have any questions, corrections, or
> > > > feedback, please let me know.
> > > >
> > > >
> > > > ## Description:
> > > >  -  Usergrid is Backend-as-a-Service (BaaS) composed of an integrated
> > > > database (Cassandra), a query engine (Elastic Search), and
> > > > application layer and client tier with SDKs for developers.
> > > >
> > > > ## Issues:
> > > >  -  There are no issues requiring board attention at this time
> > > >
> > > > ## Activity:
> > > >  - Unique value implementation has been moved to Akka.  This has
> > > increased
> > > > data stability significantly for unique name values.
> > > >  - The multi-region queueing via Akka (Qakka), has been released
> > (Thanks
> > > > Dave for this).
> > > >
> > > > ## Health report:
> > > >  - Usergrid is healthy and the community is growing at a moderate
> pace.
> > > >
> > > >
> > > > ## PMC changes:
> > > >
> > > >  - Currently 25 PMC members.
> > > >  - No new PMC members added in the last 3 months
> > > >  - Last PMC addition was Mike Dunker on Mon Jan 18 2016
> > > >
> > > > ## Committer base changes:
> > > >
> > > >  - Currently 14 committers.
> > > >  - No new committers added in the last 3 months
> > > >  - Last committer addition was George Reyes at Tue Sep 29 2015
> > > >
> > > > ## Releases:
> > > >
> > > >  - Last release was 2.1.0 on Wed Feb 17 2016
> > > >
> > > > ## Mailing list activity:
> > > >
> > > >  - dev@usergrid.apache.org:
> > > > - 105 subscribers (up 6 in the last 3 months):
> > > > - 83 emails sent to list (98 in previous quarter)
> > > >
> > > >  - u...@usergrid.apache.org:
> > > > - 135 subscribers (up 7 in the last 3 months):
> > > > - 12 emails sent to list (25 in previous quarter)
> > > >
> > > >
> > > > ## JIRA activity:
> > > >
> > > >  - 14 JIRA tickets created in the last 3 months
> > > >  - 2 JIRA tickets closed/resolved in the last 3 months
> > > >
> > >
> >
>
-- 
-Russo from Mobile

Re: [DRAFT] Usergrid Report

[Michael Russo]

Multi region queueing with Akka hasn't been released yet, it's just
available in the master branch. Let's update that if it's not too late.

We need to do another release soon as there's a good handful of changes
since 2.1.0 that will benefit everyone.


On Sun, Feb 12, 2017 at 04:11 John D. Ament  wrote:

> Last release is listed as a year ago, but this comment appears:
>
> The multi-region queueing via Akka (Qakka), has been released (Thanks
> Dave for this).
>
> How was this released?
>
> On Sat, Feb 11, 2017 at 8:59 PM Todd Nine  wrote:
>
> > Hey all,
> >   Below is the Usergrid report.  Sorry for the short notice, I need to
> get
> > it in tomorrow morning. If you have any questions, corrections, or
> > feedback, please let me know.
> >
> >
> > ## Description:
> >  -  Usergrid is Backend-as-a-Service (BaaS) composed of an integrated
> > database (Cassandra), a query engine (Elastic Search), and
> > application layer and client tier with SDKs for developers.
> >
> > ## Issues:
> >  -  There are no issues requiring board attention at this time
> >
> > ## Activity:
> >  - Unique value implementation has been moved to Akka.  This has
> increased
> > data stability significantly for unique name values.
> >  - The multi-region queueing via Akka (Qakka), has been released (Thanks
> > Dave for this).
> >
> > ## Health report:
> >  - Usergrid is healthy and the community is growing at a moderate pace.
> >
> >
> > ## PMC changes:
> >
> >  - Currently 25 PMC members.
> >  - No new PMC members added in the last 3 months
> >  - Last PMC addition was Mike Dunker on Mon Jan 18 2016
> >
> > ## Committer base changes:
> >
> >  - Currently 14 committers.
> >  - No new committers added in the last 3 months
> >  - Last committer addition was George Reyes at Tue Sep 29 2015
> >
> > ## Releases:
> >
> >  - Last release was 2.1.0 on Wed Feb 17 2016
> >
> > ## Mailing list activity:
> >
> >  - dev@usergrid.apache.org:
> > - 105 subscribers (up 6 in the last 3 months):
> > - 83 emails sent to list (98 in previous quarter)
> >
> >  - u...@usergrid.apache.org:
> > - 135 subscribers (up 7 in the last 3 months):
> > - 12 emails sent to list (25 in previous quarter)
> >
> >
> > ## JIRA activity:
> >
> >  - 14 JIRA tickets created in the last 3 months
> >  - 2 JIRA tickets closed/resolved in the last 3 months
> >
>

[jira] [Closed] (USERGRID-1320) Configurable Password Policy

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-1320.
---

> Configurable Password Policy
> 
>
> Key: USERGRID-1320
> URL: https://issues.apache.org/jira/browse/USERGRID-1320
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Reporter: David Johnson
>Assignee: David Johnson
> Fix For: 2.2.0
>
>
> Add configuration properties to allow setting two separate Password Policies 
> for App Users and Admin users. These policies should be configurable:
> - Minimum password length
> - Number of uppercase letters required in password
> - Number of digits required
> - Number of special characters required



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (USERGRID-1318) Embeddable Queue implementation

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-1318.
---

> Embeddable Queue implementation
> ---
>
> Key: USERGRID-1318
> URL: https://issues.apache.org/jira/browse/USERGRID-1318
> Project: Usergrid
>  Issue Type: Story
>Reporter: David Johnson
>Assignee: David Johnson
>
> Provide a queue implementation that can be embedded in Usergrid and used as a 
> replacement for the existing AWS and in-memory options.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (USERGRID-27) Limit on connection query not working

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-27.
-

> Limit on connection query not working
> -
>
> Key: USERGRID-27
> URL: https://issues.apache.org/jira/browse/USERGRID-27
> Project: Usergrid
>  Issue Type: Bug
>  Components: Stack
>Reporter: Rod Simpson
>    Assignee: Michael Russo
>Priority: Blocker
> Fix For: 2.1.0
>
>
> Also "limit" doesn't seems to be working for connections for e.g. 
> https://api.usergrid.com/fdsafdsa/test/users/me/connecting/shares?limit=2_token=YWMtSQ92bBCsEeOYAQ1TRlcn_UDuPjgtlh06pENBKFRmoxta8jg1XwRuwVs.
>  Returns all in our case is 3



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (USERGRID-1234) Hierarchical groups

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-1234.
---

> Hierarchical groups
> ---
>
> Key: USERGRID-1234
> URL: https://issues.apache.org/jira/browse/USERGRID-1234
> Project: Usergrid
>  Issue Type: Story
>Affects Versions: 2.1.0, 1.0.0
>Reporter: Ankur Mishra
>Priority: Blocker
>
> According to usergrid documentation -
> "Groups are hierarchical. Every member of the group 
> /groups/california/san-francisco is also a member of the group 
> /groups/california" 
> (https://usergrid.apache.org/docs/user-management/group.html).
> Based on above concept I have created two groups - Group1 
> /california/san-francisco has users - user1, user2 and Group2 /california has 
> users - user3, user4.
> Based on usergrid documentation I am expecting that user1 and user2 should 
> also be members of Group2 but they are not(if I am hitting url - 
> /groups/california/users, it only returns user3 and user4, Should not it also 
> return user1 and user2?)
> Also I have posted an activity in Group2 /california which is appearing in 
> feeds of users of Group2 i.e. - user3, user4, but not appearing in the feed 
> of Group /groups/california/san-francisco users i.e. - user1, user2.
> What am I doing wrong? Please suggest.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (USERGRID-1093) Load test in-memory queue with current consumer and queue implementation

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-1093.
---
Assignee: Michael Russo

> Load test in-memory queue with current consumer and queue implementation
> 
>
> Key: USERGRID-1093
> URL: https://issues.apache.org/jira/browse/USERGRID-1093
> Project: Usergrid
>  Issue Type: Story
>Reporter: Jeffrey 
>    Assignee: Michael Russo
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (USERGRID-1256) Introduce Datastax Java Driver in effort to migration away from Astyanax

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-1256.
---

> Introduce Datastax Java Driver in effort to migration away from Astyanax
> 
>
> Key: USERGRID-1256
> URL: https://issues.apache.org/jira/browse/USERGRID-1256
> Project: Usergrid
>  Issue Type: Story
>    Reporter: Michael Russo
>    Assignee: Michael Russo
> Fix For: 2.2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (USERGRID-1202) Error returned when calling /revoketoken?token=xxx on non-existent user returns 500

[Michael Russo (JIRA)]

[ 
https://issues.apache.org/jira/browse/USERGRID-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15651420#comment-15651420
 ] 

Michael Russo commented on USERGRID-1202:
-

[~lynchlee] I just compiled and tested master from a fresh start without any 
problems.  Can you clear your maven .m2 directory for Usergrid and then do the 
following:

1) Build the latest Java SDK, https://github.com/apache/usergrid-java without 
the tests ( tests need to be updated because they are not stable ) {code}mvn 
clean install -DskipTests{code}
2) Then build usergrid from master branch ( I did this with tests, having 
cassandra dn ES up ).  Everything passed successfully:

{code}
[INFO] 
[INFO] Reactor Summary:
[INFO]
[INFO] Usergrid Parent  SUCCESS [  3.848 s]
[INFO] Usergrid Build Tools ... SUCCESS [  0.269 s]
[INFO] Usergrid Config  SUCCESS [  0.109 s]
[INFO] Usergrid Persistence ... SUCCESS [  0.118 s]
[INFO] Usergrid Model . SUCCESS [  1.840 s]
[INFO] Usergrid Common  SUCCESS [ 11.359 s]
[INFO] Usergrid ActorSystem ... SUCCESS [  3.543 s]
[INFO] Usergrid Collection  SUCCESS [ 50.404 s]
[INFO] Usergrid Map ... SUCCESS [ 18.019 s]
[INFO] Usergrid Queue . SUCCESS [  2.501 s]
[INFO] Usergrid QueryIndex  SUCCESS [  6.768 s]
[INFO] Usergrid Test Utils  SUCCESS [  2.451 s]
[INFO] Usergrid Graph . SUCCESS [02:02 min]
[INFO] Usergrid Cache . SUCCESS [  6.827 s]
[INFO] Usergrid Core .. SUCCESS [01:33 min]
[INFO] Usergrid Services .. SUCCESS [09:02 min]
[INFO] Usergrid REST .. SUCCESS [11:11 min]
[INFO] Usergrid Tools . SUCCESS [ 53.119 s]
[INFO] Usergrid Query Validator ... SUCCESS [ 24.738 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 26:56 min
[INFO] Finished at: 2016-11-09T08:44:18-08:00
[INFO] Final Memory: 75M/466M
[INFO] 
{code}

> Error returned when calling /revoketoken?token=xxx on non-existent user 
> returns 500
> ---
>
> Key: USERGRID-1202
> URL: https://issues.apache.org/jira/browse/USERGRID-1202
> Project: Usergrid
>  Issue Type: Improvement
>  Components: Stack
>Affects Versions: 2.2.0
>Reporter: Brandon Shelley
> Fix For: 2.2.0
>
>
> When calling PUT /revoketoken?token= on a non-existent user, e.g.:
> {code}PUT 
> https://api-connectors-prod.apigee.net/appservices/api-connectors/sdksandbox/users/asdf/revoketoken?token={code}
> This error is returned:
> {code}500 Internal Server Error
> {
>   "error": "uncaught",
>   "timestamp": 1452306713472,
>   "duration": 0,
>   "error_description": "Internal Server Error",
>   "exception": "org.apache.usergrid.rest.exceptions.UncaughtException",
>   "error_id": "251e782b-b679-11e5-abcb-12aee0c06a45"
> }{code}
> This should throw a 400 and the description should be improved somewhat to 
> mirror USERGRID-1201



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (USERGRID-1319) client_id & client_secret Errors (2.2.0)

[Michael Russo (JIRA)]

[ 
https://issues.apache.org/jira/browse/USERGRID-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605627#comment-15605627
 ] 

Michael Russo commented on USERGRID-1319:
-

[~jaskaran] Can you set the following properties and values and observe the 
behavior?  Does it still occur?

{code}
usergrid.auth.cache.time-to-live=0
usergrid.auth.cache.inmemory.time-to-live=0
{code}

> client_id & client_secret Errors (2.2.0)
> 
>
> Key: USERGRID-1319
> URL: https://issues.apache.org/jira/browse/USERGRID-1319
> Project: Usergrid
>  Issue Type: Bug
>  Components: Stack
>Affects Versions: 2.2.0
> Environment: OS: Ubuntu 14.04;
> Cassandra version: 2.2.6 (DataStax);
> Elasticsearch version: 1.4.4;
> Tomcat version: 7;
> JDK version: 1.8.0_65 (Oracle);
> Usergrid version: 2.2.0 (Master branch, 2nd Sep, SHA: 
> 9fae8037a4b881e9c13a5a1f23f71dc34e950c40)
>Reporter: Jaskaran
> Fix For: 2.2.0
>
>
> We are migrating our application from 1.0.2 to 2.2.0 (Master branch, 2nd 
> September, SHA: 9fae8037a4b881e9c13a5a1f23f71dc34e950c40). We have observed a 
> new issue (in 2.2.0, Master branch), while using valid client_id & 
> client_secret. Below is a sample request and response.
> Request:
> http:/users?client_id=_secret=
> Response:
> Http 401 Unauthorized
> {
>   "error": "unauthorized",
>   "timestamp": 1475131455582,
>   "duration": 0,
>   "error_description": "Subject does not have permission to access this 
> resource",
>   "exception": "org.apache.usergrid.rest.exceptions.SecurityException"
> }
> Notes on the Error and Observations:
> (1) The unauthorised error (with client_id and client_secret) is random (but 
> quite frequent) - ‘suddenly’ all Usergrid API calls fail. 
> (2) On its own, after some times (few hours), the same call with same 
> client_id and client_secret will start working again. 
> (3) The problem is NOT related to Loading of the system. It occurs during 
> NO-LOAD conditions as well.
> (4) We have tested and ‘not’ observed this issue (with client_id and 
> client_secret) with 2.1.0 and 1.0.2 releases.
> (5) Interestingly, the user access tokens (access_token) ‘always’ works with 
> 2.2.0 - it is the  current workaround we’re using. 
> Note, since admin token expires in 7 days - we can not continue using this 
> workaround approach (user access_token).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (USERGRID-1319) client_id & client_secret Errors (2.2.0)

[Michael Russo (JIRA)]

[ 
https://issues.apache.org/jira/browse/USERGRID-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569307#comment-15569307
 ] 

Michael Russo commented on USERGRID-1319:
-

[~jaskaran] Is there anything logged when these 401s occurred ?

> client_id & client_secret Errors (2.2.0)
> 
>
> Key: USERGRID-1319
> URL: https://issues.apache.org/jira/browse/USERGRID-1319
> Project: Usergrid
>  Issue Type: Bug
>  Components: Stack
>Affects Versions: 2.2.0
> Environment: OS: Ubuntu 14.04;
> Cassandra version: 2.2.6 (DataStax);
> Elasticsearch version: 1.4.4;
> Tomcat version: 7;
> JDK version: 1.8.0_65 (Oracle);
> Usergrid version: 2.2.0 (Master branch, 2nd Sep, SHA: 
> 9fae8037a4b881e9c13a5a1f23f71dc34e950c40)
>Reporter: Jaskaran
> Fix For: 2.2.0
>
>
> We are migrating our application from 1.0.2 to 2.2.0 (Master branch, 2nd 
> September, SHA: 9fae8037a4b881e9c13a5a1f23f71dc34e950c40). We have observed a 
> new issue (in 2.2.0, Master branch), while using valid client_id & 
> client_secret. Below is a sample request and response.
> Request:
> http:/users?client_id=_secret=
> Response:
> Http 401 Unauthorized
> {
>   "error": "unauthorized",
>   "timestamp": 1475131455582,
>   "duration": 0,
>   "error_description": "Subject does not have permission to access this 
> resource",
>   "exception": "org.apache.usergrid.rest.exceptions.SecurityException"
> }
> Notes on the Error and Observations:
> (1) The unauthorised error (with client_id and client_secret) is random (but 
> quite frequent) - ‘suddenly’ all Usergrid API calls fail. 
> (2) On its own, after some times (few hours), the same call with same 
> client_id and client_secret will start working again. 
> (3) The problem is NOT related to Loading of the system. It occurs during 
> NO-LOAD conditions as well.
> (4) We have tested and ‘not’ observed this issue (with client_id and 
> client_secret) with 2.1.0 and 1.0.2 releases.
> (5) Interestingly, the user access tokens (access_token) ‘always’ works with 
> 2.2.0 - it is the  current workaround we’re using. 
> Note, since admin token expires in 7 days - we can not continue using this 
> workaround approach (user access_token).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (USERGRID-1259) Re-indexing ElasticSearch entity data from Cassandra - Possible Memory Leaks in Usergrid

[Michael Russo (JIRA)]

[ 
https://issues.apache.org/jira/browse/USERGRID-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15552554#comment-15552554
 ] 

Michael Russo edited comment on USERGRID-1259 at 10/6/16 5:17 PM:
--

I also just pushed some commits to master specific to re-index which does 
actually fix the memory problem in re-index.  I had tested pre fix on a cluster 
with 100 million entities and it easily ran out of memory.  Now, it does fine, 
just queues up the index events super fast and then dependent on the # of queue 
consumers running ( elasticsearch.worker_count ).  Also the fix in master adds 
a new 'utility' queue with dedicated consumers ( 
elasticsearch.worker_count_utility ) so that the re-index queue events to do 
not cause disruption to runtime entity creation/update index events.


was (Author: mrusso):
I also just pushed some commits to master specific to re-index which does 
actually fix the memory problem in re-index.  I had tested pre fix on a cluster 
with 100 million entities and it easily ran out of memory.  Now, it does fine, 
just queues up the index events super fast and then dependent on the # of queue 
consumers running ( elasticsearch.worker_count ).  Also the fix in master adds 
a new 'utility' queue with dedicated consumers ( 
elasticsearch.worker_count_utility ) so that the re-index queue events to do 
cause disruption to runtime entity creation/update index events.

> Re-indexing ElasticSearch entity data from Cassandra - Possible Memory Leaks 
> in Usergrid
> 
>
> Key: USERGRID-1259
> URL: https://issues.apache.org/jira/browse/USERGRID-1259
> Project: Usergrid
>  Issue Type: Story
>Affects Versions: 2.1.0
>Reporter: Jaskaran
>    Assignee: Michael Russo
> Fix For: 2.2.0
>
>
> Full system re-index job (http://localhost:8080/system/index/rebuild), seems 
> to stop / hang after 20-30 hours of indexing. Usergrid seems to exhaust the 
> 4.5 GB of RAM. Please see logs below:
> 1. UserGrid logs (out of java heap space)
> Feb 04 17:06:32 Usergrid-2 catalina.out:  06:36:31,961  WARN 
> OioServerSocketPipelineSink:83 - Failed to accept a connection.
> Feb 04 17:06:32 Usergrid-2 catalina.out:  java.lang.OutOfMemoryError: Java 
> heap space
> Feb 04 15:05:03 Usergrid-2 catalina.out:  04:34:25,166  WARN jvm:203 - 
> [default] [gc][old][29454][2683] duration [54.2s], collections [3]/[54.3s], 
> total [54.2s]/[13.2h], memory [4.4gb]->[4.4gb]/[4.4gb], all_pools {[young] 
> [532.5mb]->[532.5mb]/[532.5mb]}{[survivor] [62.5mb]->[65mb]/[66.5mb]}{[old] 
> [3.8gb]->[3.8gb]/[3.8gb]}
> Feb 03 20:38:34 Usergrid-2 catalina.out: 10:08:34,616 ERROR 
> AmazonAsyncEventService:361 - Failed to index message: 
> 886ea9bd-708d-4bea-ab1c-844ff97c947c 
> 2. ES logs (time out, removed non-data node from cluster)
> Feb 04 16:00:33 Elasticsearch elasticsearch.log:  [2016-02-04 
> 05:31:17,243][INFO ][cluster.service  ] [Arlette Truffaut] removed 
> {[default][3GuynlamR6GvdiCAhhTBmw][ip-10-0-0-237][inet[/10.0.0.237:9301]]{client=true,
>  data=false},}, reason: 
> zen-disco-node_failed([default][3GuynlamR6GvdiCAhhTBmw][ip-10-0-0-237][inet[/10.0.0.237:9301]]{client=true,
>  data=false}), reason failed to ping, tried [3] times, each with maximum 
> [30s] timeout
> Feb 04 16:00:33 Elasticsearch elasticsearch.log:  [2016-02-04 
> 05:31:17,256][DEBUG][action.admin.cluster.node.stats] [Arlette Truffaut] 
> failed to execute on node [3GuynlamR6GvdiCAhhTBmw]
> Feb 04 16:00:33 Elasticsearch elasticsearch.log:  
> org.elasticsearch.transport.NodeDisconnectedException: 
> [default][inet[/10.0.0.237:9301]][cluster:monitor/nodes/stats[n]] disconnected
> Is it possible that the re-indexing code in Usergrid could have memory leaks 
> and thus uses up all the java heap memory.
> Please help.
> Thanks
> Jaskaran



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (USERGRID-1259) Re-indexing ElasticSearch entity data from Cassandra - Possible Memory Leaks in Usergrid

[Michael Russo (JIRA)]

[ 
https://issues.apache.org/jira/browse/USERGRID-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15552554#comment-15552554
 ] 

Michael Russo commented on USERGRID-1259:
-

I also just pushed some commits to master specific to re-index which does 
actually fix the memory problem in re-index.  I had tested pre fix on a cluster 
with 100 million entities and it easily ran out of memory.  Now, it does fine, 
just queues up the index events super fast and then dependent on the # of queue 
consumers running ( elasticsearch.worker_count ).  Also the fix in master adds 
a new 'utility' queue with dedicated consumers ( 
elasticsearch.worker_count_utility ) so that the re-index queue events to do 
cause disruption to runtime entity creation/update index events.

> Re-indexing ElasticSearch entity data from Cassandra - Possible Memory Leaks 
> in Usergrid
> 
>
> Key: USERGRID-1259
> URL: https://issues.apache.org/jira/browse/USERGRID-1259
> Project: Usergrid
>  Issue Type: Story
>Affects Versions: 2.1.0
>Reporter: Jaskaran
>    Assignee: Michael Russo
> Fix For: 2.2.0
>
>
> Full system re-index job (http://localhost:8080/system/index/rebuild), seems 
> to stop / hang after 20-30 hours of indexing. Usergrid seems to exhaust the 
> 4.5 GB of RAM. Please see logs below:
> 1. UserGrid logs (out of java heap space)
> Feb 04 17:06:32 Usergrid-2 catalina.out:  06:36:31,961  WARN 
> OioServerSocketPipelineSink:83 - Failed to accept a connection.
> Feb 04 17:06:32 Usergrid-2 catalina.out:  java.lang.OutOfMemoryError: Java 
> heap space
> Feb 04 15:05:03 Usergrid-2 catalina.out:  04:34:25,166  WARN jvm:203 - 
> [default] [gc][old][29454][2683] duration [54.2s], collections [3]/[54.3s], 
> total [54.2s]/[13.2h], memory [4.4gb]->[4.4gb]/[4.4gb], all_pools {[young] 
> [532.5mb]->[532.5mb]/[532.5mb]}{[survivor] [62.5mb]->[65mb]/[66.5mb]}{[old] 
> [3.8gb]->[3.8gb]/[3.8gb]}
> Feb 03 20:38:34 Usergrid-2 catalina.out: 10:08:34,616 ERROR 
> AmazonAsyncEventService:361 - Failed to index message: 
> 886ea9bd-708d-4bea-ab1c-844ff97c947c 
> 2. ES logs (time out, removed non-data node from cluster)
> Feb 04 16:00:33 Elasticsearch elasticsearch.log:  [2016-02-04 
> 05:31:17,243][INFO ][cluster.service  ] [Arlette Truffaut] removed 
> {[default][3GuynlamR6GvdiCAhhTBmw][ip-10-0-0-237][inet[/10.0.0.237:9301]]{client=true,
>  data=false},}, reason: 
> zen-disco-node_failed([default][3GuynlamR6GvdiCAhhTBmw][ip-10-0-0-237][inet[/10.0.0.237:9301]]{client=true,
>  data=false}), reason failed to ping, tried [3] times, each with maximum 
> [30s] timeout
> Feb 04 16:00:33 Elasticsearch elasticsearch.log:  [2016-02-04 
> 05:31:17,256][DEBUG][action.admin.cluster.node.stats] [Arlette Truffaut] 
> failed to execute on node [3GuynlamR6GvdiCAhhTBmw]
> Feb 04 16:00:33 Elasticsearch elasticsearch.log:  
> org.elasticsearch.transport.NodeDisconnectedException: 
> [default][inet[/10.0.0.237:9301]][cluster:monitor/nodes/stats[n]] disconnected
> Is it possible that the re-indexing code in Usergrid could have memory leaks 
> and thus uses up all the java heap memory.
> Please help.
> Thanks
> Jaskaran



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (USERGRID-423) Added rest tests for system/* endpoints

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-423.
--

> Added rest tests for system/* endpoints
> ---
>
> Key: USERGRID-423
> URL: https://issues.apache.org/jira/browse/USERGRID-423
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Affects Versions: 2.1.1, 2.1.0
>Reporter: George Reyes
>Priority: Minor
> Fix For: 2.2.0
>
>
> Currently there are no rest tests that check that the system/database/setup 
> completed correctly. We use test utils that automatically call the service 
> endpoints. We should implement a way to disable/move it so that we can check 
> that the system is being properly initialized using rest tier calls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1250) Create additional push notification tests for the node.js integration tests

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1250:

Assignee: Abhinav Sinha  (was: Michael Russo)

> Create additional push notification tests for the node.js integration tests
> ---
>
> Key: USERGRID-1250
> URL: https://issues.apache.org/jira/browse/USERGRID-1250
> Project: Usergrid
>  Issue Type: Story
>Affects Versions: 2.1.1
>    Reporter: Michael Russo
>Assignee: Abhinav Sinha
>Priority: Minor
> Fix For: 2.2.0
>
>
> Need to test the following example endpoints:
> /users/michael/notifications
> /users/michael/devices/notifications
> /users/michael/devices/*/notifications
> /users;ql=select * where username='michael'/notifications
> /devices/*/notifications
> /devices/device1/notifications
> /devices/af94a111-a927-11e5-8d9c-12c60bce005f/notifications
> /devices;ql=select * where 
> uuid='a4b7dc0b-b4d3-11e5-80bb-12c60bce005f'/notifications
> Also it's important to test creating groups of users and sending 
> notifications to 1 or more groups. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (USERGRID-1250) Create additional push notification tests for the node.js integration tests

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo reassigned USERGRID-1250:
---

Assignee: Michael Russo  (was: Abhinav Sinha)

> Create additional push notification tests for the node.js integration tests
> ---
>
> Key: USERGRID-1250
> URL: https://issues.apache.org/jira/browse/USERGRID-1250
> Project: Usergrid
>  Issue Type: Story
>Affects Versions: 2.1.1
>    Reporter: Michael Russo
>    Assignee: Michael Russo
>Priority: Minor
> Fix For: 2.2.0
>
>
> Need to test the following example endpoints:
> /users/michael/notifications
> /users/michael/devices/notifications
> /users/michael/devices/*/notifications
> /users;ql=select * where username='michael'/notifications
> /devices/*/notifications
> /devices/device1/notifications
> /devices/af94a111-a927-11e5-8d9c-12c60bce005f/notifications
> /devices;ql=select * where 
> uuid='a4b7dc0b-b4d3-11e5-80bb-12c60bce005f'/notifications
> Also it's important to test creating groups of users and sending 
> notifications to 1 or more groups. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1250) Create additional push notification tests for the node.js integration tests

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1250:

Assignee: Abhinav Sinha  (was: Michael Russo)

> Create additional push notification tests for the node.js integration tests
> ---
>
> Key: USERGRID-1250
> URL: https://issues.apache.org/jira/browse/USERGRID-1250
> Project: Usergrid
>  Issue Type: Story
>Affects Versions: 2.1.1
>    Reporter: Michael Russo
>Assignee: Abhinav Sinha
>Priority: Minor
> Fix For: 2.2.0
>
>
> Need to test the following example endpoints:
> /users/michael/notifications
> /users/michael/devices/notifications
> /users/michael/devices/*/notifications
> /users;ql=select * where username='michael'/notifications
> /devices/*/notifications
> /devices/device1/notifications
> /devices/af94a111-a927-11e5-8d9c-12c60bce005f/notifications
> /devices;ql=select * where 
> uuid='a4b7dc0b-b4d3-11e5-80bb-12c60bce005f'/notifications
> Also it's important to test creating groups of users and sending 
> notifications to 1 or more groups. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: New Locations for Usergrid SDKs

[Michael Russo]

It does, but technically only the QueryValidator module uses this ( test
cases only) and not in the actual runtime of the stack.  We have plans to
get the updated java SDK published to maven central so the dependency is
less of an issue to get Usergrid up and running.

Thanks
-Michael R.

On Thu, Sep 8, 2016 at 6:36 AM, Jaskaran Singh <jaskaran1...@gmail.com>
wrote:

> Hi Michael,
>
> Thanks for the update. Does the 'stack' still have a dependency on the Java
> SDK?
>
> Thanks
> Jaskaran
>
>
>
> On 3 September 2016 at 01:04, Michael Russo <michaelaru...@gmail.com>
> wrote:
>
> > Hey Everyone,
> >
> > We've moved the SDKs to their own separate repos.  You can find them at:
> >
> > https://git-wip-us.apache.org/repos/asf/usergrid-swift.git
> > https://git-wip-us.apache.org/repos/asf/usergrid-android.git
> > https://git-wip-us.apache.org/repos/asf/usergrid-python.git
> > https://git-wip-us.apache.org/repos/asf/usergrid-java.git
> > https://git-wip-us.apache.org/repos/asf/usergrid-dotnet.git
> > https://git-wip-us.apache.org/repos/asf/usergrid-javascript.git
> > https://git-wip-us.apache.org/repos/asf/usergrid-nodejs.git
> >
> > and the following mirrors on github:
> >
> > https://github.com/apache/usergrid-swift
> > https://github.com/apache/usergrid-android
> > https://github.com/apache/usergrid-python
> > https://github.com/apache/usergrid-java
> > https://github.com/apache/usergrid-dotnet
> > https://github.com/apache/usergrid-javascript
> > https://github.com/apache/usergrid-nodejs
> >
> > The move happened with the latest code that was in master branch as of
> > today, 9/2/2016, in Apache Usergrid's main repository.  When you navigate
> > to their old location in the Apache Usergrid main repository, you will
> see
> > the readme has a link to the new location.
> >
> > Thanks!
> > -Michael R.
> >
>

[jira] [Assigned] (USERGRID-1259) Re-indexing ElasticSearch entity data from Cassandra - Possible Memory Leaks in Usergrid

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo reassigned USERGRID-1259:
---

Assignee: Michael Russo

> Re-indexing ElasticSearch entity data from Cassandra - Possible Memory Leaks 
> in Usergrid
> 
>
> Key: USERGRID-1259
> URL: https://issues.apache.org/jira/browse/USERGRID-1259
> Project: Usergrid
>  Issue Type: Story
>Affects Versions: 2.1.0
>Reporter: Jaskaran
>    Assignee: Michael Russo
> Fix For: 2.2.0
>
>
> Full system re-index job (http://localhost:8080/system/index/rebuild), seems 
> to stop / hang after 20-30 hours of indexing. Usergrid seems to exhaust the 
> 4.5 GB of RAM. Please see logs below:
> 1. UserGrid logs (out of java heap space)
> Feb 04 17:06:32 Usergrid-2 catalina.out:  06:36:31,961  WARN 
> OioServerSocketPipelineSink:83 - Failed to accept a connection.
> Feb 04 17:06:32 Usergrid-2 catalina.out:  java.lang.OutOfMemoryError: Java 
> heap space
> Feb 04 15:05:03 Usergrid-2 catalina.out:  04:34:25,166  WARN jvm:203 - 
> [default] [gc][old][29454][2683] duration [54.2s], collections [3]/[54.3s], 
> total [54.2s]/[13.2h], memory [4.4gb]->[4.4gb]/[4.4gb], all_pools {[young] 
> [532.5mb]->[532.5mb]/[532.5mb]}{[survivor] [62.5mb]->[65mb]/[66.5mb]}{[old] 
> [3.8gb]->[3.8gb]/[3.8gb]}
> Feb 03 20:38:34 Usergrid-2 catalina.out: 10:08:34,616 ERROR 
> AmazonAsyncEventService:361 - Failed to index message: 
> 886ea9bd-708d-4bea-ab1c-844ff97c947c 
> 2. ES logs (time out, removed non-data node from cluster)
> Feb 04 16:00:33 Elasticsearch elasticsearch.log:  [2016-02-04 
> 05:31:17,243][INFO ][cluster.service  ] [Arlette Truffaut] removed 
> {[default][3GuynlamR6GvdiCAhhTBmw][ip-10-0-0-237][inet[/10.0.0.237:9301]]{client=true,
>  data=false},}, reason: 
> zen-disco-node_failed([default][3GuynlamR6GvdiCAhhTBmw][ip-10-0-0-237][inet[/10.0.0.237:9301]]{client=true,
>  data=false}), reason failed to ping, tried [3] times, each with maximum 
> [30s] timeout
> Feb 04 16:00:33 Elasticsearch elasticsearch.log:  [2016-02-04 
> 05:31:17,256][DEBUG][action.admin.cluster.node.stats] [Arlette Truffaut] 
> failed to execute on node [3GuynlamR6GvdiCAhhTBmw]
> Feb 04 16:00:33 Elasticsearch elasticsearch.log:  
> org.elasticsearch.transport.NodeDisconnectedException: 
> [default][inet[/10.0.0.237:9301]][cluster:monitor/nodes/stats[n]] disconnected
> Is it possible that the re-indexing code in Usergrid could have memory leaks 
> and thus uses up all the java heap memory.
> Please help.
> Thanks
> Jaskaran



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (USERGRID-1259) Re-indexing ElasticSearch entity data from Cassandra - Possible Memory Leaks in Usergrid

[Michael Russo (JIRA)]

[ 
https://issues.apache.org/jira/browse/USERGRID-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470977#comment-15470977
 ] 

Michael Russo commented on USERGRID-1259:
-

In the latest of master branch ( which will eventually become a 2.2.0 release, 
we've made many memory improvements).  We never found any problems specific to 
re-index and had tested with ~10 million + entities.  Regular Usergrid running 
was having memory pressure in time, and I think re-index in your case 
accelerated the problem. 

> Re-indexing ElasticSearch entity data from Cassandra - Possible Memory Leaks 
> in Usergrid
> 
>
> Key: USERGRID-1259
> URL: https://issues.apache.org/jira/browse/USERGRID-1259
> Project: Usergrid
>  Issue Type: Story
>Affects Versions: 2.1.0
>Reporter: Jaskaran
> Fix For: 2.2.0
>
>
> Full system re-index job (http://localhost:8080/system/index/rebuild), seems 
> to stop / hang after 20-30 hours of indexing. Usergrid seems to exhaust the 
> 4.5 GB of RAM. Please see logs below:
> 1. UserGrid logs (out of java heap space)
> Feb 04 17:06:32 Usergrid-2 catalina.out:  06:36:31,961  WARN 
> OioServerSocketPipelineSink:83 - Failed to accept a connection.
> Feb 04 17:06:32 Usergrid-2 catalina.out:  java.lang.OutOfMemoryError: Java 
> heap space
> Feb 04 15:05:03 Usergrid-2 catalina.out:  04:34:25,166  WARN jvm:203 - 
> [default] [gc][old][29454][2683] duration [54.2s], collections [3]/[54.3s], 
> total [54.2s]/[13.2h], memory [4.4gb]->[4.4gb]/[4.4gb], all_pools {[young] 
> [532.5mb]->[532.5mb]/[532.5mb]}{[survivor] [62.5mb]->[65mb]/[66.5mb]}{[old] 
> [3.8gb]->[3.8gb]/[3.8gb]}
> Feb 03 20:38:34 Usergrid-2 catalina.out: 10:08:34,616 ERROR 
> AmazonAsyncEventService:361 - Failed to index message: 
> 886ea9bd-708d-4bea-ab1c-844ff97c947c 
> 2. ES logs (time out, removed non-data node from cluster)
> Feb 04 16:00:33 Elasticsearch elasticsearch.log:  [2016-02-04 
> 05:31:17,243][INFO ][cluster.service  ] [Arlette Truffaut] removed 
> {[default][3GuynlamR6GvdiCAhhTBmw][ip-10-0-0-237][inet[/10.0.0.237:9301]]{client=true,
>  data=false},}, reason: 
> zen-disco-node_failed([default][3GuynlamR6GvdiCAhhTBmw][ip-10-0-0-237][inet[/10.0.0.237:9301]]{client=true,
>  data=false}), reason failed to ping, tried [3] times, each with maximum 
> [30s] timeout
> Feb 04 16:00:33 Elasticsearch elasticsearch.log:  [2016-02-04 
> 05:31:17,256][DEBUG][action.admin.cluster.node.stats] [Arlette Truffaut] 
> failed to execute on node [3GuynlamR6GvdiCAhhTBmw]
> Feb 04 16:00:33 Elasticsearch elasticsearch.log:  
> org.elasticsearch.transport.NodeDisconnectedException: 
> [default][inet[/10.0.0.237:9301]][cluster:monitor/nodes/stats[n]] disconnected
> Is it possible that the re-indexing code in Usergrid could have memory leaks 
> and thus uses up all the java heap memory.
> Please help.
> Thanks
> Jaskaran



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1259) Re-indexing ElasticSearch entity data from Cassandra - Possible Memory Leaks in Usergrid

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1259:

Fix Version/s: 2.2.0

> Re-indexing ElasticSearch entity data from Cassandra - Possible Memory Leaks 
> in Usergrid
> 
>
> Key: USERGRID-1259
> URL: https://issues.apache.org/jira/browse/USERGRID-1259
> Project: Usergrid
>  Issue Type: Story
>Affects Versions: 2.1.0
>Reporter: Jaskaran
> Fix For: 2.2.0
>
>
> Full system re-index job (http://localhost:8080/system/index/rebuild), seems 
> to stop / hang after 20-30 hours of indexing. Usergrid seems to exhaust the 
> 4.5 GB of RAM. Please see logs below:
> 1. UserGrid logs (out of java heap space)
> Feb 04 17:06:32 Usergrid-2 catalina.out:  06:36:31,961  WARN 
> OioServerSocketPipelineSink:83 - Failed to accept a connection.
> Feb 04 17:06:32 Usergrid-2 catalina.out:  java.lang.OutOfMemoryError: Java 
> heap space
> Feb 04 15:05:03 Usergrid-2 catalina.out:  04:34:25,166  WARN jvm:203 - 
> [default] [gc][old][29454][2683] duration [54.2s], collections [3]/[54.3s], 
> total [54.2s]/[13.2h], memory [4.4gb]->[4.4gb]/[4.4gb], all_pools {[young] 
> [532.5mb]->[532.5mb]/[532.5mb]}{[survivor] [62.5mb]->[65mb]/[66.5mb]}{[old] 
> [3.8gb]->[3.8gb]/[3.8gb]}
> Feb 03 20:38:34 Usergrid-2 catalina.out: 10:08:34,616 ERROR 
> AmazonAsyncEventService:361 - Failed to index message: 
> 886ea9bd-708d-4bea-ab1c-844ff97c947c 
> 2. ES logs (time out, removed non-data node from cluster)
> Feb 04 16:00:33 Elasticsearch elasticsearch.log:  [2016-02-04 
> 05:31:17,243][INFO ][cluster.service  ] [Arlette Truffaut] removed 
> {[default][3GuynlamR6GvdiCAhhTBmw][ip-10-0-0-237][inet[/10.0.0.237:9301]]{client=true,
>  data=false},}, reason: 
> zen-disco-node_failed([default][3GuynlamR6GvdiCAhhTBmw][ip-10-0-0-237][inet[/10.0.0.237:9301]]{client=true,
>  data=false}), reason failed to ping, tried [3] times, each with maximum 
> [30s] timeout
> Feb 04 16:00:33 Elasticsearch elasticsearch.log:  [2016-02-04 
> 05:31:17,256][DEBUG][action.admin.cluster.node.stats] [Arlette Truffaut] 
> failed to execute on node [3GuynlamR6GvdiCAhhTBmw]
> Feb 04 16:00:33 Elasticsearch elasticsearch.log:  
> org.elasticsearch.transport.NodeDisconnectedException: 
> [default][inet[/10.0.0.237:9301]][cluster:monitor/nodes/stats[n]] disconnected
> Is it possible that the re-indexing code in Usergrid could have memory leaks 
> and thus uses up all the java heap memory.
> Please help.
> Thanks
> Jaskaran



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (USERGRID-1272) Set a property to turn off usergrid's dependency on elasticsearch

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo reassigned USERGRID-1272:
---

Assignee: Michael Russo  (was: George Reyes)

> Set a property to turn off usergrid's dependency on elasticsearch
> -
>
> Key: USERGRID-1272
> URL: https://issues.apache.org/jira/browse/USERGRID-1272
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Reporter: George Reyes
>    Assignee: Michael Russo
> Fix For: 2.2.0
>
>
> Have a property that can tell Usergrid whether we want to use elasticsearch 
> or not. If we don't we shouldn't have any errors, should just work as is with 
> only graph searches . 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1272) Set a property to turn off usergrid's dependency on elasticsearch

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1272:

Sprint: Usergrid 36

> Set a property to turn off usergrid's dependency on elasticsearch
> -
>
> Key: USERGRID-1272
> URL: https://issues.apache.org/jira/browse/USERGRID-1272
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Reporter: George Reyes
>Assignee: George Reyes
> Fix For: 2.2.0
>
>
> Have a property that can tell Usergrid whether we want to use elasticsearch 
> or not. If we don't we shouldn't have any errors, should just work as is with 
> only graph searches . 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

New Repos for Usergrid SDKs

[Michael Russo]

Hey Everyone,

I've requested for new repositories for the more popular and actively
developed Usergrid SDKs:

usergrid-swift
usergrid-android
usergrid-java
usergrid-python
usergrid-dotnet
usergrid-javascript
usergrid-nodejs

https://issues.apache.org/jira/browse/INFRA-12542
https://issues.apache.org/jira/browse/INFRA-12543
https://issues.apache.org/jira/browse/INFRA-12544
https://issues.apache.org/jira/browse/INFRA-12545
https://issues.apache.org/jira/browse/INFRA-12546
https://issues.apache.org/jira/browse/INFRA-12547
https://issues.apache.org/jira/browse/INFRA-12548

Ideally this should make it easier to contribute SDK fixes/enhancements
without having to clone all of Usergrid code.  At the time code is moved
into these repos, documentation will be updated and another email
notification will be sent.

Let me know if there are any questions/concerns.


Thanks!
Michael R.

[jira] [Closed] (USERGRID-647) Issue with Unique Values - NPE

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-647.
--

> Issue with Unique Values - NPE
> --
>
> Key: USERGRID-647
> URL: https://issues.apache.org/jira/browse/USERGRID-647
> Project: Usergrid
>  Issue Type: Bug
>Reporter: Jeffrey 
> Fix For: 2.2.0
>
>
> Please ensure appropriate null checks and behavior happen here:
> 2015-05-12 17:05:37,811 [http-bio-8080-exec-14] ERROR 
> org.apache.usergrid.rest.exceptions.AbstractExceptionMapper- 
> java.lang.NullPointerException Server Error (500)
> java.lang.NullPointerException
>   at 
> org.apache.usergrid.services.AbstractConnectionsService.getItemByName(AbstractConnectionsService.java:238)
>   at 
> org.apache.usergrid.services.AbstractService.invokeItemWithName(AbstractService.java:671)
>   at 
> org.apache.usergrid.services.AbstractService.invoke(AbstractService.java:628)
>   at 
> org.apache.usergrid.services.AbstractService.invoke(AbstractService.java:544)
>   at 
> org.apache.usergrid.services.ServiceRequest.execute(ServiceRequest.java:226)
>   at 
> org.apache.usergrid.services.ServiceRequest.invokeMultiple(ServiceRequest.java:262)
>   at 
> org.apache.usergrid.services.ServiceRequest.execute(ServiceRequest.java:229)
>   at 
> org.apache.usergrid.services.ServiceRequest.execute(ServiceRequest.java:193)
>   at 
> org.apache.usergrid.rest.applications.ServiceResource.executeServiceRequest(ServiceResource.java:251)
>   at 
> org.apache.usergrid.rest.applications.ServiceResource.executeGet(ServiceResource.java:297)
>   at sun.reflect.GeneratedMethodAccessor142.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>   at 
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>   at 
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>   at 
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>   at 
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
>   at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>   at 
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
>   at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>   at 
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
>   at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>   at 
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
>   at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>   at 
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
>   at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>   at 
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
>   at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>   at 
> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
>   at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>   at 
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>   at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)
>   at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)
>   at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)
>   at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409)
>   at 
> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409)
>   at 
> com.sun.jersey.spi.contai

[jira] [Closed] (USERGRID-1310) No cursor returned when paging incoming connections

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-1310.
---

> No cursor returned when paging incoming connections
> ---
>
> Key: USERGRID-1310
> URL: https://issues.apache.org/jira/browse/USERGRID-1310
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Reporter: David Johnson
>Assignee: David Johnson
> Fix For: 2.2.0
>
>
> Investigate and fix: no cursor returned when getting incoming connections?
> ---
> From Andrew Lane on the user mailing list:
> Let's say I have some collection called someentity that has connections to 
> other entities via a verb subscribedto. For a particular entity with id 
> some_id, I'd like to pull all the entities that are connected to this entity 
> via the subscribedto verb. I can do that via this GET request:
> /org/app/someentity/some_id/subscribedto
> However, I'm not sure how I stream or page through this data if there are 
> thousands or more results. I'm not getting back a cursor or anything. Is 
> having a huge number of connections to a particular entity something that's 
> just not a smart thing to do with Usergrid?
> From Dave Johnson:
> ---
> Usergrid is designed to support a huge number of connections, and we 
> implemented "edge sharding" to ensure that we are not thwarted by Cassandra's 
> 2-billion column limitation. 
> The normal way to page through results is to have a cursor, so the fact that 
> you did not get a cursor is a problem, and most likely a bug -- can you share 
> the exact API call you are making as a curl (or HTTPie) command?  Do you see 
> any errors in the logs?
>  
> From Andrew Lane:
> ---
> I have a collection of events, and users can subscribe to those events via a 
> connection called "subscribedto".  For a particular event (some_event_id), 
> I'm trying to stream all the users that are subscribed to that event.  In my 
> scenario, there are over 1000 subscribers.  I'm issuing something like this 
> (note the "connecting" part of the URL, which I accidentally ommitted 
> previously):
> curl -X GET 
> "http://myserver:8080/myorg/sandbox/events/some_event_id/connecting/subscribedto?limit=5;
> It's correctly limiting to 5 users, but I'm not getting any cursor where I 
> can continue streaming.  If I remove the limit clause, I only get the first 
> 1000 results, which I expect.  But again, no cursor to continue to pull data.
> From Andrew Lane:
> ---
> I should be clear that I DO get a cursor when querying the relationship in 
> the opposite direction.  That is, if a single user is subscribed to more than 
> 1 event, I can stream those successfully and I get a cursor.  It's the 
> inverse direction that's not giving me a cursor.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1271) Enforce a TTL For Entities

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1271:

Labels: groomed  (was: )

> Enforce a TTL For Entities
> --
>
> Key: USERGRID-1271
> URL: https://issues.apache.org/jira/browse/USERGRID-1271
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Affects Versions: 2.1.1
>Reporter: Jeffrey 
>Assignee: Ayesha Amrin Dastagiri
>  Labels: groomed
>
> Usergrid should support the ability to set a TTL for an entity:
> 1) When it is created, using either the qparam TTL (in seconds) 
> 2) After it is created by calling PUT /{org}/{app}/{collection}/{entity}/_ttl 
> (value in seconds)
> A TTL of -1 should indicate that there is no expiry.
> Also the ttl should be returned in the 'metadata' section of an entity if 
> there is a TTL.
> When setting a TTL, ensure all column families and related data are updated:
> 1) MVCC_Entity_Data_
> 2) Unique_Values_
> 3) Directed edges in all of Graph_
> 4) The edge reference in appropriate Edge_Shards row
> 5) The indexed document in ElasticSearch



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1281) Download page must link to ASF mirrors for KEYS, sigs hashes

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1281:

Labels: groomed  (was: )

> Download page must link to ASF mirrors for KEYS, sigs hashes
> 
>
> Key: USERGRID-1281
> URL: https://issues.apache.org/jira/browse/USERGRID-1281
> Project: Usergrid
>  Issue Type: Bug
> Environment: http://usergrid.apache.org/releases/
>Reporter: Sebb
>Assignee: David Johnson
>  Labels: groomed
>
> The download page currently links to  https://dist.apache.org/repos/dist/ for 
> KEYS, sigs and hashes.
> Such links must use the ASF mirrors, eg
> https://www.apache.org/dist/usergrid/KEYS



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1281) Download page must link to ASF mirrors for KEYS, sigs hashes

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1281:

Sprint: Usergrid 36

> Download page must link to ASF mirrors for KEYS, sigs hashes
> 
>
> Key: USERGRID-1281
> URL: https://issues.apache.org/jira/browse/USERGRID-1281
> Project: Usergrid
>  Issue Type: Bug
> Environment: http://usergrid.apache.org/releases/
>Reporter: Sebb
>Assignee: David Johnson
>  Labels: groomed
>
> The download page currently links to  https://dist.apache.org/repos/dist/ for 
> KEYS, sigs and hashes.
> Such links must use the ASF mirrors, eg
> https://www.apache.org/dist/usergrid/KEYS



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (USERGRID-1276) NPE when doing POST to App token with form data and client_credentials grant

[Michael Russo (JIRA)]

[ 
https://issues.apache.org/jira/browse/USERGRID-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410123#comment-15410123
 ] 

Michael Russo commented on USERGRID-1276:
-

Do you have an example request?

> NPE when doing POST to App token with form data and client_credentials grant
> 
>
> Key: USERGRID-1276
> URL: https://issues.apache.org/jira/browse/USERGRID-1276
> Project: Usergrid
>  Issue Type: Story
>Reporter: Jeffrey 
>
> 2016-04-07 22:09:06,694 [http-bio-8080-exec-26] ERROR 
> org.apache.usergrid.rest.exceptions.ThrowableMapper- An uncaught exception 
> occurred during HTTP invocation
> java.lang.NullPointerException
>   at 
> org.apache.usergrid.rest.applications.ApplicationResource.getAccessTokenPostJson(ApplicationResource.java:331)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
>   at 
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
>   at 
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
>   at 
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
>   at 
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1281) Download page must link to ASF mirrors for KEYS, sigs hashes

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1281:

Assignee: David Johnson

> Download page must link to ASF mirrors for KEYS, sigs hashes
> 
>
> Key: USERGRID-1281
> URL: https://issues.apache.org/jira/browse/USERGRID-1281
> Project: Usergrid
>  Issue Type: Bug
> Environment: http://usergrid.apache.org/releases/
>Reporter: Sebb
>Assignee: David Johnson
>
> The download page currently links to  https://dist.apache.org/repos/dist/ for 
> KEYS, sigs and hashes.
> Such links must use the ASF mirrors, eg
> https://www.apache.org/dist/usergrid/KEYS



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1282) /users/me permissions work differently in 2.1

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1282:

Labels: groomed  (was: )

> /users/me permissions work differently in 2.1
> -
>
> Key: USERGRID-1282
> URL: https://issues.apache.org/jira/browse/USERGRID-1282
> Project: Usergrid
>  Issue Type: Story
>Reporter: Jeffrey 
>  Labels: groomed
>
> apologies for the short ticket description.
> they need explicit permissions whereas in 1.0 they were implicit - at least 
> /users/me.
> I would think that  /users/me is default
>  /users/me/** should not necessarily be default.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1284) Unhandled NPE

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1284:

Labels: groomed  (was: )

> Unhandled NPE
> -
>
> Key: USERGRID-1284
> URL: https://issues.apache.org/jira/browse/USERGRID-1284
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Affects Versions: 2.1.1
>Reporter: Jeffrey 
>  Labels: groomed
>
> Please add appropriate null checks on this line of code to ensure that null 
> is appropriately handled.
> 2016-05-09 22:57:03,967 [http-bio-8080-exec-55] ERROR 
> org.apache.usergrid.rest.exceptions.ThrowableMapper- An uncaught exception 
> occurred during HTTP invocation
> java.lang.NullPointerException
>   at 
> org.apache.usergrid.persistence.Query.containsUuidIdentifiersOnly(Query.java:417)
>   at 
> org.apache.usergrid.persistence.Query.containsSingleUuidIdentifier(Query.java:404)
>   at 
> org.apache.usergrid.services.ServiceContext.isByUuid(ServiceContext.java:308)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (USERGRID-1284) Unhandled NPE

[Michael Russo (JIRA)]

[ 
https://issues.apache.org/jira/browse/USERGRID-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410114#comment-15410114
 ] 

Michael Russo commented on USERGRID-1284:
-

Do you have a curl call to reproduce?

> Unhandled NPE
> -
>
> Key: USERGRID-1284
> URL: https://issues.apache.org/jira/browse/USERGRID-1284
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Affects Versions: 2.1.1
>Reporter: Jeffrey 
>  Labels: groomed
>
> Please add appropriate null checks on this line of code to ensure that null 
> is appropriately handled.
> 2016-05-09 22:57:03,967 [http-bio-8080-exec-55] ERROR 
> org.apache.usergrid.rest.exceptions.ThrowableMapper- An uncaught exception 
> occurred during HTTP invocation
> java.lang.NullPointerException
>   at 
> org.apache.usergrid.persistence.Query.containsUuidIdentifiersOnly(Query.java:417)
>   at 
> org.apache.usergrid.persistence.Query.containsSingleUuidIdentifier(Query.java:404)
>   at 
> org.apache.usergrid.services.ServiceContext.isByUuid(ServiceContext.java:308)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1294) Lightweight token validation for users and admins

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1294:

Labels: groomed  (was: )

> Lightweight token validation for users and admins
> -
>
> Key: USERGRID-1294
> URL: https://issues.apache.org/jira/browse/USERGRID-1294
> Project: Usergrid
>  Issue Type: Story
>Reporter: Marsh Gardiner
>  Labels: groomed
>
> For both app and admin users, an endpoint should exist that allows a bearer 
> token to be validated. It should include email address, username, and UUID of 
> the user so that identity can be validated as well as the token. For extra 
> credit, if the username/uuid/email were passed in as part of the validation 
> claim, then Usergrid would check the user's record and only return a 200 if 
> the supplied info matched (ignoring case).
> While it is possible to call `…/management/token` and `…/management/me`, both 
> return a complex user object and are not appropriate for token validation 
> given that they generate a new token every time, effectively decreasing the 
> entropy with each validation call. (Also, this suggests that this GET request 
> is non-idempotent as it changes the system state, even if that change is 
> subtle.)
> Alternatively, if Usergrid tokens were self-signed in a way that could be 
> independently validated (such as a JWT), that would provide some 
> architectural benefits when using Usergrid as an identity service beyond pure 
> BaaS.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (USERGRID-1294) Lightweight token validation for users and admins

[Michael Russo (JIRA)]

[ 
https://issues.apache.org/jira/browse/USERGRID-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410110#comment-15410110
 ] 

Michael Russo commented on USERGRID-1294:
-

We can look to add a /tokenvalidate endpoint which will do the 200 OK if the 
token is valid and validate against supplied parameters of one or combination 
of all username, UUID, email.  Any mismatch would return an error status.

No plans for generating JWT tokens.

> Lightweight token validation for users and admins
> -
>
> Key: USERGRID-1294
> URL: https://issues.apache.org/jira/browse/USERGRID-1294
> Project: Usergrid
>  Issue Type: Story
>Reporter: Marsh Gardiner
>  Labels: groomed
>
> For both app and admin users, an endpoint should exist that allows a bearer 
> token to be validated. It should include email address, username, and UUID of 
> the user so that identity can be validated as well as the token. For extra 
> credit, if the username/uuid/email were passed in as part of the validation 
> claim, then Usergrid would check the user's record and only return a 200 if 
> the supplied info matched (ignoring case).
> While it is possible to call `…/management/token` and `…/management/me`, both 
> return a complex user object and are not appropriate for token validation 
> given that they generate a new token every time, effectively decreasing the 
> entropy with each validation call. (Also, this suggests that this GET request 
> is non-idempotent as it changes the system state, even if that change is 
> subtle.)
> Alternatively, if Usergrid tokens were self-signed in a way that could be 
> independently validated (such as a JWT), that would provide some 
> architectural benefits when using Usergrid as an identity service beyond pure 
> BaaS.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1299) Fix limitations of App Delete

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1299:

Labels: groomed  (was: )

> Fix limitations of App Delete
> -
>
> Key: USERGRID-1299
> URL: https://issues.apache.org/jira/browse/USERGRID-1299
> Project: Usergrid
>  Issue Type: Improvement
>  Components: Stack
>Affects Versions: 2.1.1
>Reporter: David Johnson
>  Labels: groomed
>
> At the time of this writing there are a couple of limitations regarding 
> Application Delete and Restore:
> * Within an Organization, you cannot delete an Application with the same name 
> as an Application that you have deleted before.
> * Within an Organization, you cannot restore an Application is an application 
> with the very same name has been added since the orginal one was deleted.
> These should be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (USERGRID-1299) Fix limitations of App Delete

[Michael Russo (JIRA)]

[ 
https://issues.apache.org/jira/browse/USERGRID-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15410104#comment-15410104
 ] 

Michael Russo commented on USERGRID-1299:
-

Maybe prefix the deleted app name when it's moved to deleted app infos 
collection. 
Allow the ability to specify a new app name during the restore application API 
request.

> Fix limitations of App Delete
> -
>
> Key: USERGRID-1299
> URL: https://issues.apache.org/jira/browse/USERGRID-1299
> Project: Usergrid
>  Issue Type: Improvement
>  Components: Stack
>Affects Versions: 2.1.1
>Reporter: David Johnson
>  Labels: groomed
>
> At the time of this writing there are a couple of limitations regarding 
> Application Delete and Restore:
> * Within an Organization, you cannot delete an Application with the same name 
> as an Application that you have deleted before.
> * Within an Organization, you cannot restore an Application is an application 
> with the very same name has been added since the orginal one was deleted.
> These should be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1301) Fix SubjectUtils.isServiceAdmin to work in all currently used cases

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1301:

Issue Type: Improvement  (was: Story)

> Fix SubjectUtils.isServiceAdmin to work in all currently used cases
> ---
>
> Key: USERGRID-1301
> URL: https://issues.apache.org/jira/browse/USERGRID-1301
> Project: Usergrid
>  Issue Type: Improvement
>Affects Versions: 2.1.1, 2.1.0
>    Reporter: Michael Russo
>  Labels: groomed
> Fix For: 2.2.0
>
>
> Either fix the use of this ( sometimes the isServiceAdmin call does a check 
> for wrong type of Principal). 
>  Otherwise match usage of sysadmin checking in 
> org.apache.usergrid.rest.security.SecuredResourceFilterFactory



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1302) Error during username token verification

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1302:

Issue Type: Bug  (was: Story)

> Error during username token verification
> 
>
> Key: USERGRID-1302
> URL: https://issues.apache.org/jira/browse/USERGRID-1302
> Project: Usergrid
>  Issue Type: Bug
>Affects Versions: 2.1.1
>    Reporter: Michael Russo
>  Labels: groomed
> Fix For: 2.2.0
>
>
> Need to figure out/fix the below exception - 
> WARN  org.apache.usergrid.rest.applications.ApplicationResource- Unexpected 
> exception during token username/password verification
> java.lang.RuntimeException: Entity is null
>   at 
> org.apache.usergrid.corepersistence.CpEntityManager.getDictionaryElementValue(CpEntityManager.java:1320)
>   at 
> org.apache.usergrid.management.cassandra.ManagementServiceImpl.readCreds(ManagementServiceImpl.java:3260)
>   at 
> org.apache.usergrid.management.cassandra.ManagementServiceImpl.readUserPasswordCredentials(ManagementServiceImpl.java:3211)
>   at 
> org.apache.usergrid.management.cassandra.ManagementServiceImpl.verify(ManagementServiceImpl.java:3311)
>   at 
> org.apache.usergrid.management.cassandra.ManagementServiceImpl.verifyAppUserPasswordCredentials(ManagementServiceImpl.java:3080)
>   at 
> org.apache.usergrid.rest.applications.ApplicationResource.getAccessToken(ApplicationResource.java:236)
>   at 
> org.apache.usergrid.rest.applications.ApplicationResource.getAccessTokenPost(ApplicationResource.java:318)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
>   at 
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
>   at 
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
>   at 
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
>   at 
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
>   at 
> org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
>   at 
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
>   at 
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
>   at 
> org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:309)
>   at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
>   at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
>   at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
>   at org.glassfish.jersey.internal.Errors.process(Errors.java:297)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1302) Error during username token verification

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1302:

Labels: groomed  (was: )

> Error during username token verification
> 
>
> Key: USERGRID-1302
> URL: https://issues.apache.org/jira/browse/USERGRID-1302
> Project: Usergrid
>  Issue Type: Story
>Affects Versions: 2.1.1
>    Reporter: Michael Russo
>  Labels: groomed
> Fix For: 2.2.0
>
>
> Need to figure out/fix the below exception - 
> WARN  org.apache.usergrid.rest.applications.ApplicationResource- Unexpected 
> exception during token username/password verification
> java.lang.RuntimeException: Entity is null
>   at 
> org.apache.usergrid.corepersistence.CpEntityManager.getDictionaryElementValue(CpEntityManager.java:1320)
>   at 
> org.apache.usergrid.management.cassandra.ManagementServiceImpl.readCreds(ManagementServiceImpl.java:3260)
>   at 
> org.apache.usergrid.management.cassandra.ManagementServiceImpl.readUserPasswordCredentials(ManagementServiceImpl.java:3211)
>   at 
> org.apache.usergrid.management.cassandra.ManagementServiceImpl.verify(ManagementServiceImpl.java:3311)
>   at 
> org.apache.usergrid.management.cassandra.ManagementServiceImpl.verifyAppUserPasswordCredentials(ManagementServiceImpl.java:3080)
>   at 
> org.apache.usergrid.rest.applications.ApplicationResource.getAccessToken(ApplicationResource.java:236)
>   at 
> org.apache.usergrid.rest.applications.ApplicationResource.getAccessTokenPost(ApplicationResource.java:318)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
>   at 
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
>   at 
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
>   at 
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
>   at 
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
>   at 
> org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
>   at 
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
>   at 
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
>   at 
> org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:309)
>   at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
>   at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
>   at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
>   at org.glassfish.jersey.internal.Errors.process(Errors.java:297)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1311) .NET SDK - Allow for querying of incoming connections

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1311:

Labels: groomed  (was: )

> .NET SDK - Allow for querying of incoming connections
> -
>
> Key: USERGRID-1311
> URL: https://issues.apache.org/jira/browse/USERGRID-1311
> Project: Usergrid
>  Issue Type: Improvement
>  Components: SDK-DotNet
>Reporter: Andrew Lane
>  Labels: groomed
>
> The .NET SDK for Usergrid currently allows you to pull outbound connections, 
> but not incoming connections (i.e. a request that would use the "connecting" 
> keyword).  This is a necessary feature, in my opinion.  I can submit a pull 
> request if necessary.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1313) Add ability to specify metadata for individual connections

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1313:

Labels: connection groomed suggestion  (was: connection suggestion)

> Add ability to specify metadata for individual connections
> --
>
> Key: USERGRID-1313
> URL: https://issues.apache.org/jira/browse/USERGRID-1313
> Project: Usergrid
>  Issue Type: Improvement
>Reporter: Andrew Lane
>  Labels: connection, groomed, suggestion
>
> I'm proposing adding the ability to specify metadata for a connection when 
> creating that connection.  These could be simple name value pairs or 
> something more complex.  It would be nice to be able to filter on this 
> metadata when querying connections.  As an example, say we have a connection 
> between entity A and entity B with verb V.  I would like to say that there is 
> some metadata M on this connection, and M.foo = "bar" and M.biz = "bat".  
> When querying connections between A and B, I would then later like to specify 
> that I only want to pull connections that have metadata such that 
> metadata.foo = "bar".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (USERGRID-1315) Improve Duplicate Unique Value Message

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo resolved USERGRID-1315.
-
Resolution: Won't Fix

You can do GET by name and fetch the UUID based on the exceptions logged. 

> Improve Duplicate Unique Value Message
> --
>
> Key: USERGRID-1315
> URL: https://issues.apache.org/jira/browse/USERGRID-1315
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Reporter: Jeffrey 
>
> At the moment, the log message when there is a duplicate unique value (name) 
> only says there is a collision and does not indicate the UUID of the entity 
> which currently holds the unique value for that type+field.  An improvement 
> would be to include the UUID of the existing entity in the log message.
> For an individual operation this may not seem like a worthwhile thing to 
> have.  However, in the case of a mass import of data, it would be useful to 
> have the UUIDs in a log for troubleshooting purposes.  Also, there have 
> beenUsergrid bugs in the past which have resulted in duplicate entities with 
> the same name, so the user may not be able to take action without the UUID of 
> the existing entity in Usergrid.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (USERGRID-1315) Improve Duplicate Unique Value Message

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-1315.
---

> Improve Duplicate Unique Value Message
> --
>
> Key: USERGRID-1315
> URL: https://issues.apache.org/jira/browse/USERGRID-1315
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Reporter: Jeffrey 
>
> At the moment, the log message when there is a duplicate unique value (name) 
> only says there is a collision and does not indicate the UUID of the entity 
> which currently holds the unique value for that type+field.  An improvement 
> would be to include the UUID of the existing entity in the log message.
> For an individual operation this may not seem like a worthwhile thing to 
> have.  However, in the case of a mass import of data, it would be useful to 
> have the UUIDs in a log for troubleshooting purposes.  Also, there have 
> beenUsergrid bugs in the past which have resulted in duplicate entities with 
> the same name, so the user may not be able to take action without the UUID of 
> the existing entity in Usergrid.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (USERGRID-1120) Fix CounterIT.testIncrementAndDecrement() test

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-1120.
---

> Fix CounterIT.testIncrementAndDecrement() test
> --
>
> Key: USERGRID-1120
> URL: https://issues.apache.org/jira/browse/USERGRID-1120
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Affects Versions: 2.1.1, 2.1.0
>Reporter: David Johnson
>Assignee: George Reyes
> Fix For: 2.2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (USERGRID-1116) Fix MessagesIT tests

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo closed USERGRID-1116.
---

> Fix MessagesIT tests
> 
>
> Key: USERGRID-1116
> URL: https://issues.apache.org/jira/browse/USERGRID-1116
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Affects Versions: 2.1.1, 2.1.0
>Reporter: David Johnson
>Assignee: George Reyes
> Fix For: 2.2.0
>
>
> Four of the MessagesIT tests are ignored. Fix these tests and un-ignore them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-647) Issue with Unique Values - NPE

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-647:
---
Sprint: Usergrid 36

> Issue with Unique Values - NPE
> --
>
> Key: USERGRID-647
> URL: https://issues.apache.org/jira/browse/USERGRID-647
> Project: Usergrid
>  Issue Type: Bug
>Reporter: Jeffrey 
>
> Please ensure appropriate null checks and behavior happen here:
> 2015-05-12 17:05:37,811 [http-bio-8080-exec-14] ERROR 
> org.apache.usergrid.rest.exceptions.AbstractExceptionMapper- 
> java.lang.NullPointerException Server Error (500)
> java.lang.NullPointerException
>   at 
> org.apache.usergrid.services.AbstractConnectionsService.getItemByName(AbstractConnectionsService.java:238)
>   at 
> org.apache.usergrid.services.AbstractService.invokeItemWithName(AbstractService.java:671)
>   at 
> org.apache.usergrid.services.AbstractService.invoke(AbstractService.java:628)
>   at 
> org.apache.usergrid.services.AbstractService.invoke(AbstractService.java:544)
>   at 
> org.apache.usergrid.services.ServiceRequest.execute(ServiceRequest.java:226)
>   at 
> org.apache.usergrid.services.ServiceRequest.invokeMultiple(ServiceRequest.java:262)
>   at 
> org.apache.usergrid.services.ServiceRequest.execute(ServiceRequest.java:229)
>   at 
> org.apache.usergrid.services.ServiceRequest.execute(ServiceRequest.java:193)
>   at 
> org.apache.usergrid.rest.applications.ServiceResource.executeServiceRequest(ServiceResource.java:251)
>   at 
> org.apache.usergrid.rest.applications.ServiceResource.executeGet(ServiceResource.java:297)
>   at sun.reflect.GeneratedMethodAccessor142.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>   at 
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>   at 
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>   at 
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>   at 
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
>   at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>   at 
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
>   at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>   at 
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
>   at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>   at 
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
>   at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>   at 
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
>   at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>   at 
> com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137)
>   at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>   at 
> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
>   at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>   at 
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>   at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)
>   at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)
>   at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)
>   at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409)
>   at 
> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409)
>   at 
> com.sun.jersey.spi.container.se

[jira] [Updated] (USERGRID-1314) Or queries fail when field "name" is included

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1314:

Sprint: Usergrid 36

> Or queries fail when field "name" is included
> -
>
> Key: USERGRID-1314
> URL: https://issues.apache.org/jira/browse/USERGRID-1314
> Project: Usergrid
>  Issue Type: Bug
>Reporter: David Johnson
>
> When I fixed the Query Validator module, I found that about 5 of the tests 
> fail to return correct results.
> All of the failing queries use an OR operator with a field named "name" for 
> example, these queries (from EntityIndexTest in the query index module) work 
> fine:
> testQuery( scope, searchTypes, "age > 35", 29 );
> testQuery( scope, searchTypes, "age <= 35", 73 );
> testQuery( scope, searchTypes, "age <= 35 or age > 35", 102 );
> But this query returns 0 results because the presence of the "name" field 
> seems to turn the OR query into an AND query.
> testQuery( scope, searchTypes, "name = 'astro*' or age > 35", 29 );
> Until this is fixed, I have marked the five failing tests in UserQueryIT (in 
> the query-validator module) with the @Ignore annotations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (USERGRID-1279) Push Notification Counters

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo reassigned USERGRID-1279:
---

Assignee: Michael Russo  (was: George Reyes)

> Push Notification Counters
> --
>
> Key: USERGRID-1279
> URL: https://issues.apache.org/jira/browse/USERGRID-1279
> Project: Usergrid
>  Issue Type: Story
>Reporter: Jeffrey 
>    Assignee: Michael Russo
>
> We should have the ability to expose counters for push notifications in the 
> same hierarchical fashion that we have for events.
> We need two counters for notifications:
> - Individual notification counters: {code} 
> counters.notifications.f86bbfbb-fd2b-11e5-8bf1-02ae99987fc5.{processed | sent 
> | failed | opened} {code}
> - Aggregate Notification counters:   
> {code}counters.notifications.aggregate.{processed | sent | failed | 
> opened}.{year}.{month}.{day}.{HH24} possibly minute. {code}
> Counters should be able to be retrieved using the counters API:
> {code} curl -X GET 
> https://api.usergrid.com/your-org/your-app/counters?counter=counters.notifications.f86bbfbb-fd2b-11e5-8bf1-02ae99987fc5.sent
>  {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1279) Push Notification Counters

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1279:

Sprint:   (was: Usergrid 37)

> Push Notification Counters
> --
>
> Key: USERGRID-1279
> URL: https://issues.apache.org/jira/browse/USERGRID-1279
> Project: Usergrid
>  Issue Type: Story
>Reporter: Jeffrey 
>    Assignee: Michael Russo
>
> We should have the ability to expose counters for push notifications in the 
> same hierarchical fashion that we have for events.
> We need two counters for notifications:
> - Individual notification counters: {code} 
> counters.notifications.f86bbfbb-fd2b-11e5-8bf1-02ae99987fc5.{processed | sent 
> | failed | opened} {code}
> - Aggregate Notification counters:   
> {code}counters.notifications.aggregate.{processed | sent | failed | 
> opened}.{year}.{month}.{day}.{HH24} possibly minute. {code}
> Counters should be able to be retrieved using the counters API:
> {code} curl -X GET 
> https://api.usergrid.com/your-org/your-app/counters?counter=counters.notifications.f86bbfbb-fd2b-11e5-8bf1-02ae99987fc5.sent
>  {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1248) Please delete old releases from mirroring system

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1248:

Assignee: David Johnson

> Please delete old releases from mirroring system
> 
>
> Key: USERGRID-1248
> URL: https://issues.apache.org/jira/browse/USERGRID-1248
> Project: Usergrid
>  Issue Type: Bug
>Affects Versions: 1.0.1
> Environment: 
> https://dist.apache.org/repos/dist/release/usergrid/usergrid-1/
>Reporter: Sebb
>Assignee: David Johnson
>
> To reduce the load on the ASF mirrors, projects are required to delete old 
> releases [1]
> Please can you remove all non-current releases?
> i.e. the ones listed as affected.
> Thanks!
> [1] http://www.apache.org/dev/release.html#when-to-archive



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1248) Please delete old releases from mirroring system

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1248:

Sprint: Usergrid 36  (was: Usergrid 37)

> Please delete old releases from mirroring system
> 
>
> Key: USERGRID-1248
> URL: https://issues.apache.org/jira/browse/USERGRID-1248
> Project: Usergrid
>  Issue Type: Bug
>Affects Versions: 1.0.1
> Environment: 
> https://dist.apache.org/repos/dist/release/usergrid/usergrid-1/
>Reporter: Sebb
>
> To reduce the load on the ASF mirrors, projects are required to delete old 
> releases [1]
> Please can you remove all non-current releases?
> i.e. the ones listed as affected.
> Thanks!
> [1] http://www.apache.org/dev/release.html#when-to-archive



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1024) Fix EntityMapSerialization in EntityToMapConverter to remove type serialization

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1024:

Sprint:   (was: Usergrid 37)

> Fix EntityMapSerialization in EntityToMapConverter to remove type 
> serialization
> ---
>
> Key: USERGRID-1024
> URL: https://issues.apache.org/jira/browse/USERGRID-1024
> Project: Usergrid
>  Issue Type: Story
>Affects Versions: 2.1.1, 2.1.0
>Reporter: Shawn Feldman
>    Assignee: Michael Russo
>Priority: Minor
>   Original Estimate: 0.05h
>  Remaining Estimate: 0.05h
>
> EntityToMapConverter line 143 injects binary objects into our serialized 
> maps.  Probably a good idea to change this to just map structures instead.  
> we want to remove the type info. see attached



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-881) Remove Fields and Map to Entity Conversions from Core

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-881:
---
Sprint:   (was: Usergrid 37)

> Remove Fields and Map to Entity Conversions from Core
> -
>
> Key: USERGRID-881
> URL: https://issues.apache.org/jira/browse/USERGRID-881
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Affects Versions: 2.1.0
>Reporter: Shawn Feldman
>    Assignee: Michael Russo
> Fix For: 2.2.0
>
>
> we convert from a map to entity and back 2 - 3 times for every read and 
> write.  We should remove these type conversions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (USERGRID-284) [SPIKE] Research a distributed cache

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo resolved USERGRID-284.

Resolution: Won't Fix

We'll re-visit any generic interface for distributed caching when the need 
arises.

> [SPIKE] Research a distributed cache
> 
>
> Key: USERGRID-284
> URL: https://issues.apache.org/jira/browse/USERGRID-284
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Reporter: Rod Simpson
>Priority: Minor
>
> In an effort to implement "delete collection", we need to research 
> distributed cache.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-286) Build Application and Collection Delete Async Distributed Workflow

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-286:
---
Sprint: Usergrid 34  (was: Usergrid 34, Usergrid 37)

> Build Application and Collection Delete Async Distributed Workflow
> --
>
> Key: USERGRID-286
> URL: https://issues.apache.org/jira/browse/USERGRID-286
> Project: Usergrid
>  Issue Type: Bug
>Reporter: Rod Simpson
>    Assignee: Michael Russo
>Priority: Minor
>
> Akka and the Usergrid ActorSystem module is now used in Usergrid from 2.1.1 
> onwards.  We need to develop an asynch distributed workflow leveraging this 
> ActorSystem for things like data cleanup after app/collection deletion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-286) Build Application and Collection Delete Async Distributed Workflow

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-286:
---
Summary: Build Application and Collection Delete Async Distributed Workflow 
 (was: [SPIKE] Research asynch distributed workflow)

> Build Application and Collection Delete Async Distributed Workflow
> --
>
> Key: USERGRID-286
> URL: https://issues.apache.org/jira/browse/USERGRID-286
> Project: Usergrid
>  Issue Type: Bug
>Reporter: Rod Simpson
>Assignee: George Reyes
>Priority: Minor
>
> We need to develop an asynch distributed workflow for things like data 
> cleanup after app/collection deletion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (USERGRID-1272) Set a property to turn off usergrid's dependency on elasticsearch

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo updated USERGRID-1272:

Sprint:   (was: Usergrid 36)

> Set a property to turn off usergrid's dependency on elasticsearch
> -
>
> Key: USERGRID-1272
> URL: https://issues.apache.org/jira/browse/USERGRID-1272
> Project: Usergrid
>  Issue Type: Story
>  Components: Stack
>Reporter: George Reyes
>Assignee: George Reyes
> Fix For: 2.2.0
>
>
> Have a property that can tell Usergrid whether we want to use elasticsearch 
> or not. If we don't we shouldn't have any errors, should just work as is with 
> only graph searches . 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (USERGRID-1093) Load test in-memory queue with current consumer and queue implementation

[Michael Russo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/USERGRID-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Russo resolved USERGRID-1093.
-
   Resolution: Won't Fix
Fix Version/s: (was: 2.2.0)

> Load test in-memory queue with current consumer and queue implementation
> 
>
> Key: USERGRID-1093
> URL: https://issues.apache.org/jira/browse/USERGRID-1093
> Project: Usergrid
>  Issue Type: Story
>Reporter: Jeffrey 
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)