I don't see any relation in this error being thrown and upgrade - not able to reproduce when ugprading from 3.2 to 3.3.

I also don't see any relation to Predefined DynaGroup Expressions installed by plugin because 1) we don't provide dynaGroup with this name 2) it's handled in code, that it does not overwrite user defined dynagroups with same name if existing.

The error is likely, because there is a resource group called "DynaGroup - Read Only All Resources ( server.example.com(JBoss Main Server) )" but this group had to be manualy created and this error might have been thrown.

Code which generates groups based on DynaGroup definition queries ResourceGroups by it's definitionId (ie. looks if a group previously generated by this definition exists) and if not found, it attempts to create it. It does not handle situation, when there is a group with a name that it is going to generate. If it did, it would have to overwrite it's members.

I recommend closing this as NOTABUG, customer may safely delete resource group called "DynaGroup - Read Only All Resources ( server.example.com(JBoss Main Server) )" as it will be populated on next dynagroup recalculation.

If you are saying that this error is from someone attempting to create a DynaGroup using a name that already exists, wouldn't the client side or UI error be sufficient?

Perhaps the log message should only appear at DEBUG. 

I think what you describe here is a bug in the sense that I can fill up the server logs with meaningless messages by simply running the same CLI command over and over and over.

No, it's comming from an existing dynagroup definition which tries to create resource group, which already exists. It tries to do so, because the existing group is not related to definition being recalculated.

I can fix the code so it also tries to look for an existing group by name and in case match is found, just output warning without stacktrace.

Libor, it is not clear how an existing dynagroup could be attempting to create a resource group that already exists. 

> No, it's comming from an existing dynagroup definition which tries to create
> resource group, which already exists. It tries to do so, because the
> existing group is not related to definition being recalculated.

This should be impossible. When an attempt is made to create a static group with the name of an existing group or a dynamic group that will result in using the same name as an existing dynamic group or a dynamic group that could conflict with a static group which used "DyanGroup - " at the begging of its name, an error would be generated to the user either via the UI or remote API. The respective group definition or group would not be created.

Even if I were to manually create a group and made its name "DynaGroup - Read Only All Resources ( server.example.com(JBoss Main Server) )" then attempted to create a dynamic group definition named "Read Only All Resources ( server.example.com(JBoss Main Server) )", my expectation would be a UI (or CLI/API) error that said a group with that name already exists.

The same goes the other way around -- if an attempt is made to create a static group with the name "DynaGroup - Read Only All Resources ( server.example.com(JBoss Main Server) )" after a dynamic group definition by the same name already exists, again, I expect a UI or remote API error.

I can not see how an existing dynamic group definition would ever recalculate a group member list and happen to generate a group with the same name as an unrelated resource group considering that for the definition to exist, the name had to be unique in the first place.

We have a bug in either the creation of groups allowing the new groups name to use the same name as an existing group or, what I fear here, is that something with the upgrade process or dynamic group changes made in a 3.2 or 3.3 commit is has cause the group that is associated with this dynamic group definition to become "disconnected."

> I can fix the code so it also tries to look for an existing group by name
> and in case match is found, just output warning without stacktrace.

Again, the error or warning should be presented to the user either via the UI or via the remoate API at the time the static group or dynamic group definition is created. No ERROR or WARNING should be logged in the server log. Instead, when this situation occurs, a DEBUG message/stack would be sufficient.

If this issue is not happening on group creation time then again, we have a bug here and a error message is appropriate and we need to fix the bug so the error/stack does not get displayed at all.

(In reply to Larry O'Leary from comment #4)
> Libor, it is not clear how an existing dynagroup could be attempting to
> create a resource group that already exists. 
> 
> > No, it's comming from an existing dynagroup definition which tries to create
> > resource group, which already exists. It tries to do so, because the
> > existing group is not related to definition being recalculated.
> 
> This should be impossible. When an attempt is made to create a static group
> with the name of an existing group or a dynamic group that will result in
> using the same name as an existing dynamic group or a dynamic group that
> could conflict with a static group which used "DyanGroup - " at the begging
> of its name, an error would be generated to the user either via the UI or
> remote API. The respective group definition or group would not be created.
> 
> Even if I were to manually create a group and made its name "DynaGroup -
> Read Only All Resources ( server.example.com(JBoss Main Server) )" then
> attempted to create a dynamic group definition named "Read Only All
> Resources ( server.example.com(JBoss Main Server) )", my expectation would
> be a UI (or CLI/API) error that said a group with that name already exists.
This is how it is possible to reproduce the issue. I've easily reproduced it this way on predefined expression called "Groups by platform"

1. delete group "DynaGroup - Groups by platform ( Linux )" if exists
2. manually create "DynaGroup - Groups by platform ( Linux )" - since this point you'll get errors in server log on each recalculate attempt of "Groups by platform" dynagroup
3. go to "Groups by platform" and hit recalculate

At create dynagroup time we don't know yet which and how many groups is it going generate (especially when there is groupby expression) - in fact generated groups can change over time based on what you have in inventory, thatswhy we cannot show UI error. That UI/CLI error could happen only if you hit recalculate in UI. 

> The same goes the other way around -- if an attempt is made to create a
> static group with the name "DynaGroup - Read Only All Resources (
> server.example.com(JBoss Main Server) )" after a dynamic group definition by
> the same name already exists, again, I expect a UI or remote API error.

Yes, this is how it works now - but again .. that dynagroup must have been recalculated at least once.

> I can not see how an existing dynamic group definition would ever
> recalculate a group member list and happen to generate a group with the same
> name as an unrelated resource group considering that for the definition to
> exist, the name had to be unique in the first place.
> 
> We have a bug in either the creation of groups allowing the new groups name
> to use the same name as an existing group or, what I fear here, is that
> something with the upgrade process or dynamic group changes made in a 3.2 or
> 3.3 commit is has cause the group that is associated with this dynamic group
> definition to become "disconnected."
> 
I went through all schema changes we did since 3.2 and we did not touch the relation between dynaGroup definition and generated group. dynaGroup definition is affected only by adding a reference to predefined expression provided by plugins (JON3-5) - which added 1 column.

What we can do 'though .. we can handle the situation, when we recalculate dynaGroup definition, and we find out there's an existing group matching with it's name the one we're going to create, but it's not connected to our group definition, we can log a warning and delete the original group and create new one from our definition or just adopt the group and update it's members instead of failure right now, which prevents finishing recalculation. 

I'd be for adopt the "disconnected" group (assumming user knows he should not create groups matching "DynaGroup -*"). In other case (when we don't know how this disconnection happens) - we're going to "repair" the data. Adoption is better than deletion, because it does not generate new ID (as the group could be referenced on dashboards, etc)

After discussing this with Libor, the issue here is name conflicts that can occur when the user names a group (non-dynamic) using the same string that JBoss ON is using for the prefix of a dynamic group name. This causes an unintentional conflict in where groups or child/auto groups could end up being named the same as a static group the user has created.

Although this is a very bad design, it is how it was implemented and changing it would be too disruptive. Users should avoid naming groups anything similar or using a string at the beginning that will conflict with the poorly chosen internal naming prefix of 'DynaGroup - '.

Actually I was able to reproduce this BZ.

It's enough if dynaGroup expression looks like this:

groupby resource.name

and you have at least one EAP6 standalone and one EAP6 domain in inventory.

The issue happens, because (if you have those 2 servers) there are resources called "Threading" and "threading"

Code which creates resourceGroup first tries to query DB for an existing name using this JPA query:

SELECT rg FROM ResourceGroup AS rg WHERE LOWER(rg.name) = LOWER(:name) AND rg.visible = true"

this means, resource groups called "*threading" and "*Threading" cannot coexist.

So, as Libor discovered, the issue is that group names (for visible groups) are case insensitive.  This is basically a good thing but it breaks down here, because the dynagroup name uses the 'pivot' values resulting from the group definition. And certain expressions could be a problem, like 'groupby resource.name' because resource names are flexible.  In this case the group name we wanted was:

DynaGroup - Read Only All Resources ( server.example.com(JBoss Main Server) )

But the 'Read Only All Resource' group definition must have generated results with the groupBy clause resulting in both 'server.example.com(JBoss Main Server)' another one that differed only by case.

After looking at this further I think the right thing to do is to "merge" the members of dynagroups with caseInsensitive-equal names. In this way all of the resulting resources end up in a generated dynagroup.  It may be the case that a user could be slightly surprised at the result but it is a logical result given the data. And of course at the moment the buggy behvior is severe.

Master commit 08075f8f5693853183b6f00a937c20bcb3575cfb
Author: Jay Shaughnessy <jshaughn>
Date:   Wed Dec 2 13:55:37 2015 -0500

 In a rare case a groupBy expression can generates multiple groupByClause
 strings differing only in case. Group names are [correctly] case
 insensitive and groupBy [correctly] is not. For example 'groupby
 resource.name' can cause this issue with two resources with the same name,
 ignoring case, like 'CPU' and 'cpu'.  In this situation we need to
 consolidate results into one dyna-group, otherwise we'll get naming
 conflicts in the generated groups. So, merge results where the
 groupByClause is equal, ignoring case.

branch: release/jon3.3.x
commit: c99d2ddbee245b59d0d52c60f903662e1be480ca
Author:     Jay Shaughnessy <jshaughn>
AuthorDate: Wed Dec 2 13:55:37 2015 -0500
Commit:     Simeon Pinder <spinder>
CommitDate: Fri Dec 4 09:46:52 2015 -0500

    BZ 1187680 : Error recalculating DynaGroups due to ResourceGroupAlreadyExistsException
...

Moving to ON_QA as available to test with the following brew build:

JON Cumulative patch build: https://brewweb.devel.redhat.com/buildinfo?buildID=469635
  *Note: jon-server-patch-3.3.0.GA.zip maps to DR01 build of jon-server-3.3.0.GA-update-05.zip.

Tested on Version :3.3.0.GA Update 05 Build Number :bb9d2ba:95ae59f

Imported couple of EAP servers and created a dynagroup definition with expression - groupby resource.name
Tried clicking on Recalculate button few times. There is no error and the selected group definition is recalculated successfully.

However, referring to the steps in comment#5, following steps still show the ResourceGroupAlreadyExistsException.

-Navigate to Administration->All Groups
-Delete the platform group - DynaGroup - Groups by platform ( Linux )
-Click on New
-Enter the same name "DynaGroup - Groups by platform ( Linux )" and click Next
-Select and move the platform resource to the Assigned resource table in 'Select Members' screen.
-Click Finish
-Go to Administration->Dynagroup Definitions and select 'Groups by platform'.
-Click on Recalculate button.
-It displays error in UI - 'Failed to recalculate the selected group definitions

The server log shows below exception:

10:24:43,192 WARN  [org.rhq.coregui.server.gwt.ResourceGroupGWTServiceImpl] (http-/0.0.0.0:7080-8) Sending exception to client: [1450365883192] : org.rhq.enterprise.server.resource.group.ResourceGroupAlreadyExistsException: ResourceGroup with name DynaGroup - Groups by platform ( Linux ) already exists

Please refer the attached screenshot and server.log

Created attachment 1106761 [details]
Screenshot-UI-Message

Created attachment 1106762 [details]
Server Log

If the only failure scenario is due to manually created groups named exactly like generated dynagroups then I think the solution is to just have them rename those groups as a workaround.  I can't really imagine this is a real-world scenario and so I'm not sure it's worth any risk trying to handle it.

Sunil, if you can confirm that this is the only failure scenario I think we should discuss whether GSS is satisfied with the current fix.

I still think that we should properly handle the scenario described in comment 5 but I do agree with Jay that this is not a normal scenario. It is not even the one the customer was facing. Instead, it was invented as a theory of what the user was most likely doing to get into the situation. 

As indicated in comment 9, the forced duplicate naming issue was not the cause of this bug.

@Sunil, as Jay indicated, if you can confirm that your test failure was due to the forced duplicate naming described in comment 5, then I think we can mark this verified. For completeness, your verification comment should clearly indicate that the issue described in comment 5 is still not fixed but it was determined that what was described in comment 5 was out-of-scope for this BZ and was not the underlying issue.

Yes Jay and Larry,

I tried to reproduce with adding couple of agents, EAP servers - standalone and domain mode and created a dynagroup definition with expression - groupby resource.name
The issue is not reproducible by clicking recalculate button for dynagroups created with above expression.

The test failure was only due to the forced duplicate naming described in comment#5. 
The scenario in comment#5 is still shows the ResourceGroupAlreadyExistsException, but as this scenario is out-of-scope for this bug, marking the bug as verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-0118.html