[jira] [Created] (GEODE-10397) Meyhomes Capital Phú Quốc Landup
Meyhomes Capital Phú Quốc Landup created GEODE-10397:
Summary: Meyhomes Capital Phú Quốc Landup
Key: GEODE-10397
URL: https://issues.apache.org/jira/browse/GEODE-10397
Project: Geode
Issue Type: Bug
Reporter: Meyhomes Capital Phú Quốc Landup
Thông tin mới về dự án Meyhomes Capital Phú Quốc LandUp
[https://landup.net/du-an/meyhomes-capital-phu-quoc/], vị trí, thanh toán,
chiết khấu, giá bán...dự án Meyhomes Capital Phú Quốc của chủ đầu tư Tân Á Đại
Thành. Dự án có vị trí đắc địa ngay gần bờ biển Bãi Trường, được nhiều nhà đầu
tư quan tâm tìm mua.
*Website:* ++ [https://landup.net/du-an/meyhomes-capital-phu-quoc/]
{*}Youtube{*}: [https://www.youtube.com/channel/UCkXw7NGUetiWxAkET5Vc1WA/]
*Blog:*
[https://sites.google.com/view/meyhomescapitalpq-landup/|https://sites.google.com/view/meyhomescapitalpq-landup/trang-ch%E1%BB%A7]
*Email:* meyhomescapitalphuq...@gmail.com
*Địa chỉ:* 20 Nguyễn Văn Đậu, Phường 5, Quận Phú Nhuận, Thành phố Hồ Chí Minh
*Số điện thoại:* 0928.0168.69
*Tags:* Dự án Meyhomes Capital Phú Quốc, Meyhomes Capital Phú Quốc, BĐS Tân Á
Đại Thành, Bất động sản Phú Quốc, LandUp, Bất động sản
*Hashtag:* #meyhomescapital #meyhomescapitalphuquoc #batdongsanphuquoc
#tanadaithanh #batdongsan #landup
*Xã hội của tôi:*
[https://www.facebook.com/Meyhomes-Capital-Ph%C3%BA-Qu%E1%BB%91c-112117104876503]
[https://www.pinterest.com/meyhomescapitalpqlandup|https://www.pinterest.com/meyhomescapitalpqlandup/]
[https://twitter.com/MeyhomesCapitaI]
[https://about.me/meyhomescapitalpqlandup]
[https://www.behance.net/meyhomescapitalpq]
[https://meyhomescapitalpqlandup.tumblr.com|https://meyhomescapitalpqlandup.tumblr.com/]
[https://www.tumblr.com/blog/view/meyhomescapitalpqlandup]
[https://soundcloud.com/meyhomescapitalpq-landup]
[https://www.instagram.com/meyhomescapitalpglandup|https://www.instagram.com/meyhomescapitalpglandup/]
[https://myhomescapitalphuquoclandup.wordpress.com/]
[https://meyhomescapitalpqlandup.weebly.com/]
[https://github.com/meyhomescapitalpq-landup]
[https://meyhomescapitalpq-landup.blogspot.com/2022/07/meyhomes-capital-phu-quoc-landup.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GEODE-5220) DistributedRegion Should Validate AsyncEventQueue/GatewaySender Attributes Earlier
Juan José Ramos Cassella created GEODE-5220:
---
Summary: DistributedRegion Should Validate
AsyncEventQueue/GatewaySender Attributes Earlier
Key: GEODE-5220
URL: https://issues.apache.org/jira/browse/GEODE-5220
Project: Geode
Issue Type: Bug
Components: gfsh, regions, wan
Reporter: Juan José Ramos Cassella
The method {{DistributedRegion.postCreateRegion()}} currently validates that
the {{gateway-sender}} or {{async-event-queue}} associated with the region upon
creation (if any) is not of type {{parallel}} as that is not supported by
regions of type {{REPLICATED}}:
{code:title=DistributedRegion.java|borderStyle=solid}
@Override
public void postCreateRegion() {
super.postCreateRegion();
...
Set allGatewaySenderIds = getAllGatewaySenderIds();
if (!allGatewaySenderIds.isEmpty()) {
for (GatewaySender sender : this.cache.getAllGatewaySenders()) {
if (sender.isParallel() &&
allGatewaySenderIds.contains(sender.getId())) {
// Fix for Bug#51491. Once decided to support this configuration we
have call
// addShadowPartitionedRegionForUserRR
if
(sender.getId().contains(AsyncEventQueueImpl.ASYNC_EVENT_QUEUE_PREFIX)) {
throw new AsyncEventQueueConfigurationException(
LocalizedStrings.ParallelAsyncEventQueue_0_CAN_NOT_BE_USED_WITH_REPLICATED_REGION_1
.toLocalizedString(new Object[] {
AsyncEventQueueImpl.getAsyncEventQueueIdFromSenderId(sender.getId()),
this.getFullPath()}));
}
throw new GatewaySenderConfigurationException(
LocalizedStrings.ParallelGatewaySender_0_CAN_NOT_BE_USED_WITH_REPLICATED_REGION_1
.toLocalizedString(new Object[] {sender.getId(),
this.getFullPath()}));
}
}
}
...
{code}
However, the {{gateway-sender}}/{{async-event-queue}} has been associated to
the region before this last check and the code doesn't catch the
{{GatewaySenderConfigurationException}} /
{{AsyncEventQueueConfigurationException}} within that block:
{code:title=GemFireCacheImpl.java|borderStyle=solid}
public Region createVMRegion(String name, RegionAttributes
p_attrs, InternalRegionArguments internalRegionArgs) throws
RegionExistsException, TimeoutException, IOException, ClassNotFoundException {
...
region.postCreateRegion();
} catch (RegionExistsException ex) {
// outside of sync make sure region is initialized to fix bug 37563
InternalRegion internalRegion = (InternalRegion) ex.getRegion();
internalRegion.waitOnInitialization(); // don't give out ref until
initialized
throw ex;
}
...
{code}
This ends up leaving the region unusable but already added to the
{{GemFireCacheImpl.rootRegions}} field, so the cache itself is left
inconsistent (could be even worse when the region is also configured as
persistent).
No big deal when the user is configuring everything using a {{cache.xml}} file
as the exception will be propagated and the server startup will fail. When
using {{gfsh}}, on the other hand, the command {{create region}} reports a
failure but leaves the region partially created on every single member.
According to [~dschneider]
{quote}
The intent of postCreateRegion is to do things after the region was created.
This is the wrong place to be doing validation.
If you look at the super.postCreateRegion that DistributionRegion calls first
you will see it incs stats and delivers events to others telling them the
region was created. You really can't undo that well if postCreateRegion fails.
So I do not think it is a good idea to have postCreateRegion destroy the region
it created.
I think the bug here is that gateway validation is in postCreateRegion. This
validation should be done earlier so that the region creation it self fails and
postCreateRegion is never called.
{quote}
The attached script reproduces the issue both using {{gfsh}} and a
{{cache.xml}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5220) DistributedRegion Should Validate AsyncEventQueue/GatewaySender Attributes Earlier
[
https://issues.apache.org/jira/browse/GEODE-5220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-5220:
---
Assignee: Juan José Ramos Cassella
> DistributedRegion Should Validate AsyncEventQueue/GatewaySender Attributes
> Earlier
> --
>
> Key: GEODE-5220
> URL: https://issues.apache.org/jira/browse/GEODE-5220
> Project: Geode
> Issue Type: Bug
> Components: gfsh, regions, wan
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Attachments: reproducer.zip
>
>
> The method {{DistributedRegion.postCreateRegion()}} currently validates that
> the {{gateway-sender}} or {{async-event-queue}} associated with the region
> upon creation (if any) is not of type {{parallel}} as that is not supported
> by regions of type {{REPLICATED}}:
> {code:title=DistributedRegion.java|borderStyle=solid}
> @Override
> public void postCreateRegion() {
> super.postCreateRegion();
> ...
> Set allGatewaySenderIds = getAllGatewaySenderIds();
> if (!allGatewaySenderIds.isEmpty()) {
> for (GatewaySender sender : this.cache.getAllGatewaySenders()) {
> if (sender.isParallel() &&
> allGatewaySenderIds.contains(sender.getId())) {
> // Fix for Bug#51491. Once decided to support this configuration
> we have call
> // addShadowPartitionedRegionForUserRR
> if
> (sender.getId().contains(AsyncEventQueueImpl.ASYNC_EVENT_QUEUE_PREFIX)) {
> throw new AsyncEventQueueConfigurationException(
>
> LocalizedStrings.ParallelAsyncEventQueue_0_CAN_NOT_BE_USED_WITH_REPLICATED_REGION_1
> .toLocalizedString(new Object[] {
>
> AsyncEventQueueImpl.getAsyncEventQueueIdFromSenderId(sender.getId()),
> this.getFullPath()}));
> }
> throw new GatewaySenderConfigurationException(
>
> LocalizedStrings.ParallelGatewaySender_0_CAN_NOT_BE_USED_WITH_REPLICATED_REGION_1
> .toLocalizedString(new Object[] {sender.getId(),
> this.getFullPath()}));
> }
> }
> }
> ...
> {code}
> However, the {{gateway-sender}}/{{async-event-queue}} has been associated to
> the region before this last check and the code doesn't catch the
> {{GatewaySenderConfigurationException}} /
> {{AsyncEventQueueConfigurationException}} within that block:
> {code:title=GemFireCacheImpl.java|borderStyle=solid}
> public Region createVMRegion(String name, RegionAttributes
> p_attrs, InternalRegionArguments internalRegionArgs) throws
> RegionExistsException, TimeoutException, IOException, ClassNotFoundException {
> ...
> region.postCreateRegion();
> } catch (RegionExistsException ex) {
> // outside of sync make sure region is initialized to fix bug 37563
> InternalRegion internalRegion = (InternalRegion) ex.getRegion();
> internalRegion.waitOnInitialization(); // don't give out ref until
> initialized
> throw ex;
> }
> ...
> {code}
> This ends up leaving the region unusable but already added to the
> {{GemFireCacheImpl.rootRegions}} field, so the cache itself is left
> inconsistent (could be even worse when the region is also configured as
> persistent).
> No big deal when the user is configuring everything using a {{cache.xml}}
> file as the exception will be propagated and the server startup will fail.
> When using {{gfsh}}, on the other hand, the command {{create region}} reports
> a failure but leaves the region partially created on every single member.
> According to [~dschneider]
> {quote}
> The intent of postCreateRegion is to do things after the region was created.
> This is the wrong place to be doing validation.
> If you look at the super.postCreateRegion that DistributionRegion calls first
> you will see it incs stats and delivers events to others telling them the
> region was created. You really can't undo that well if postCreateRegion
> fails. So I do not think it is a good idea to have postCreateRegion destroy
> the region it created.
> I think the bug here is that gateway validation is in postCreateRegion. This
> validation should be done earlier so that the region creation it self fails
> and postCreateRegion is never called.
> {quote}
> The attached script reproduces the issue both using {{gfsh}} and a
> {{cache.xml}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5220) DistributedRegion Should Validate AsyncEventQueue/GatewaySender Attributes Earlier
[
https://issues.apache.org/jira/browse/GEODE-5220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-5220:
Attachment: reproducer.zip
> DistributedRegion Should Validate AsyncEventQueue/GatewaySender Attributes
> Earlier
> --
>
> Key: GEODE-5220
> URL: https://issues.apache.org/jira/browse/GEODE-5220
> Project: Geode
> Issue Type: Bug
> Components: gfsh, regions, wan
>Reporter: Juan José Ramos Cassella
>Priority: Major
> Attachments: reproducer.zip
>
>
> The method {{DistributedRegion.postCreateRegion()}} currently validates that
> the {{gateway-sender}} or {{async-event-queue}} associated with the region
> upon creation (if any) is not of type {{parallel}} as that is not supported
> by regions of type {{REPLICATED}}:
> {code:title=DistributedRegion.java|borderStyle=solid}
> @Override
> public void postCreateRegion() {
> super.postCreateRegion();
> ...
> Set allGatewaySenderIds = getAllGatewaySenderIds();
> if (!allGatewaySenderIds.isEmpty()) {
> for (GatewaySender sender : this.cache.getAllGatewaySenders()) {
> if (sender.isParallel() &&
> allGatewaySenderIds.contains(sender.getId())) {
> // Fix for Bug#51491. Once decided to support this configuration
> we have call
> // addShadowPartitionedRegionForUserRR
> if
> (sender.getId().contains(AsyncEventQueueImpl.ASYNC_EVENT_QUEUE_PREFIX)) {
> throw new AsyncEventQueueConfigurationException(
>
> LocalizedStrings.ParallelAsyncEventQueue_0_CAN_NOT_BE_USED_WITH_REPLICATED_REGION_1
> .toLocalizedString(new Object[] {
>
> AsyncEventQueueImpl.getAsyncEventQueueIdFromSenderId(sender.getId()),
> this.getFullPath()}));
> }
> throw new GatewaySenderConfigurationException(
>
> LocalizedStrings.ParallelGatewaySender_0_CAN_NOT_BE_USED_WITH_REPLICATED_REGION_1
> .toLocalizedString(new Object[] {sender.getId(),
> this.getFullPath()}));
> }
> }
> }
> ...
> {code}
> However, the {{gateway-sender}}/{{async-event-queue}} has been associated to
> the region before this last check and the code doesn't catch the
> {{GatewaySenderConfigurationException}} /
> {{AsyncEventQueueConfigurationException}} within that block:
> {code:title=GemFireCacheImpl.java|borderStyle=solid}
> public Region createVMRegion(String name, RegionAttributes
> p_attrs, InternalRegionArguments internalRegionArgs) throws
> RegionExistsException, TimeoutException, IOException, ClassNotFoundException {
> ...
> region.postCreateRegion();
> } catch (RegionExistsException ex) {
> // outside of sync make sure region is initialized to fix bug 37563
> InternalRegion internalRegion = (InternalRegion) ex.getRegion();
> internalRegion.waitOnInitialization(); // don't give out ref until
> initialized
> throw ex;
> }
> ...
> {code}
> This ends up leaving the region unusable but already added to the
> {{GemFireCacheImpl.rootRegions}} field, so the cache itself is left
> inconsistent (could be even worse when the region is also configured as
> persistent).
> No big deal when the user is configuring everything using a {{cache.xml}}
> file as the exception will be propagated and the server startup will fail.
> When using {{gfsh}}, on the other hand, the command {{create region}} reports
> a failure but leaves the region partially created on every single member.
> According to [~dschneider]
> {quote}
> The intent of postCreateRegion is to do things after the region was created.
> This is the wrong place to be doing validation.
> If you look at the super.postCreateRegion that DistributionRegion calls first
> you will see it incs stats and delivers events to others telling them the
> region was created. You really can't undo that well if postCreateRegion
> fails. So I do not think it is a good idea to have postCreateRegion destroy
> the region it created.
> I think the bug here is that gateway validation is in postCreateRegion. This
> validation should be done earlier so that the region creation it self fails
> and postCreateRegion is never called.
> {quote}
> The attached script reproduces the issue both using {{gfsh}} and a
> {{cache.xml}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5246) QueryService.getIndexes should not return null when there are no indexes
[
https://issues.apache.org/jira/browse/GEODE-5246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-5246:
---
Assignee: Juan José Ramos Cassella
> QueryService.getIndexes should not return null when there are no indexes
>
>
> Key: GEODE-5246
> URL: https://issues.apache.org/jira/browse/GEODE-5246
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Reporter: Jens Deppe
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> I was surprised to discover that {{QueryService.getIndexes(region)}} returned
> null when no indexes were defined. It seems like it would be cleaner (and
> less surprising) to return an empty collection. The doc says nothing about
> returning {{null}}. (Please fix the API and not the doc :) )
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5220) DistributedRegion Should Validate AsyncEventQueue/GatewaySender Attributes Earlier
[
https://issues.apache.org/jira/browse/GEODE-5220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-5220.
-
Resolution: Fixed
Fix Version/s: 1.7.0
Changes merged into develop by through
[9e8dfb21d661d225fd579a6bccbfed9b4a1ea536|https://github.com/apache/geode/commit/9e8dfb21d661d225fd579a6bccbfed9b4a1ea536].
Setting the Fix Version to 1.7.0, as stated in the [Developer
Workflow|https://cwiki.apache.org/confluence/display/GEODE/Developer+Workflow].
> DistributedRegion Should Validate AsyncEventQueue/GatewaySender Attributes
> Earlier
> --
>
> Key: GEODE-5220
> URL: https://issues.apache.org/jira/browse/GEODE-5220
> Project: Geode
> Issue Type: Bug
> Components: gfsh, regions, wan
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Attachments: reproducer.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The method {{DistributedRegion.postCreateRegion()}} currently validates that
> the {{gateway-sender}} or {{async-event-queue}} associated with the region
> upon creation (if any) is not of type {{parallel}} as that is not supported
> by regions of type {{REPLICATED}}:
> {code:title=DistributedRegion.java|borderStyle=solid}
> @Override
> public void postCreateRegion() {
> super.postCreateRegion();
> ...
> Set allGatewaySenderIds = getAllGatewaySenderIds();
> if (!allGatewaySenderIds.isEmpty()) {
> for (GatewaySender sender : this.cache.getAllGatewaySenders()) {
> if (sender.isParallel() &&
> allGatewaySenderIds.contains(sender.getId())) {
> // Fix for Bug#51491. Once decided to support this configuration
> we have call
> // addShadowPartitionedRegionForUserRR
> if
> (sender.getId().contains(AsyncEventQueueImpl.ASYNC_EVENT_QUEUE_PREFIX)) {
> throw new AsyncEventQueueConfigurationException(
>
> LocalizedStrings.ParallelAsyncEventQueue_0_CAN_NOT_BE_USED_WITH_REPLICATED_REGION_1
> .toLocalizedString(new Object[] {
>
> AsyncEventQueueImpl.getAsyncEventQueueIdFromSenderId(sender.getId()),
> this.getFullPath()}));
> }
> throw new GatewaySenderConfigurationException(
>
> LocalizedStrings.ParallelGatewaySender_0_CAN_NOT_BE_USED_WITH_REPLICATED_REGION_1
> .toLocalizedString(new Object[] {sender.getId(),
> this.getFullPath()}));
> }
> }
> }
> ...
> {code}
> However, the {{gateway-sender}}/{{async-event-queue}} has been associated to
> the region before this last check and the code doesn't catch the
> {{GatewaySenderConfigurationException}} /
> {{AsyncEventQueueConfigurationException}} within that block:
> {code:title=GemFireCacheImpl.java|borderStyle=solid}
> public Region createVMRegion(String name, RegionAttributes
> p_attrs, InternalRegionArguments internalRegionArgs) throws
> RegionExistsException, TimeoutException, IOException, ClassNotFoundException {
> ...
> region.postCreateRegion();
> } catch (RegionExistsException ex) {
> // outside of sync make sure region is initialized to fix bug 37563
> InternalRegion internalRegion = (InternalRegion) ex.getRegion();
> internalRegion.waitOnInitialization(); // don't give out ref until
> initialized
> throw ex;
> }
> ...
> {code}
> This ends up leaving the region unusable but already added to the
> {{GemFireCacheImpl.rootRegions}} field, so the cache itself is left
> inconsistent (could be even worse when the region is also configured as
> persistent).
> No big deal when the user is configuring everything using a {{cache.xml}}
> file as the exception will be propagated and the server startup will fail.
> When using {{gfsh}}, on the other hand, the command {{create region}} reports
> a failure but leaves the region partially created on every single member.
> According to [~dschneider]
> {quote}
> The intent of postCreateRegion is to do things after the region was created.
> This is the wrong place to be doing validation.
> If you look at the super.postCreateRegion that DistributionRegion calls first
> you will see it incs stats and delivers events to others telling them the
> region was created. You really can't undo tha
[jira] [Updated] (GEODE-5220) DistributedRegion Should Validate AsyncEventQueue/GatewaySender Attributes Earlier
[
https://issues.apache.org/jira/browse/GEODE-5220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-5220:
Fix Version/s: (was: 1.7.0)
1.8.0
> DistributedRegion Should Validate AsyncEventQueue/GatewaySender Attributes
> Earlier
> --
>
> Key: GEODE-5220
> URL: https://issues.apache.org/jira/browse/GEODE-5220
> Project: Geode
> Issue Type: Bug
> Components: gfsh, regions, wan
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Attachments: reproducer.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The method {{DistributedRegion.postCreateRegion()}} currently validates that
> the {{gateway-sender}} or {{async-event-queue}} associated with the region
> upon creation (if any) is not of type {{parallel}} as that is not supported
> by regions of type {{REPLICATED}}:
> {code:title=DistributedRegion.java|borderStyle=solid}
> @Override
> public void postCreateRegion() {
> super.postCreateRegion();
> ...
> Set allGatewaySenderIds = getAllGatewaySenderIds();
> if (!allGatewaySenderIds.isEmpty()) {
> for (GatewaySender sender : this.cache.getAllGatewaySenders()) {
> if (sender.isParallel() &&
> allGatewaySenderIds.contains(sender.getId())) {
> // Fix for Bug#51491. Once decided to support this configuration
> we have call
> // addShadowPartitionedRegionForUserRR
> if
> (sender.getId().contains(AsyncEventQueueImpl.ASYNC_EVENT_QUEUE_PREFIX)) {
> throw new AsyncEventQueueConfigurationException(
>
> LocalizedStrings.ParallelAsyncEventQueue_0_CAN_NOT_BE_USED_WITH_REPLICATED_REGION_1
> .toLocalizedString(new Object[] {
>
> AsyncEventQueueImpl.getAsyncEventQueueIdFromSenderId(sender.getId()),
> this.getFullPath()}));
> }
> throw new GatewaySenderConfigurationException(
>
> LocalizedStrings.ParallelGatewaySender_0_CAN_NOT_BE_USED_WITH_REPLICATED_REGION_1
> .toLocalizedString(new Object[] {sender.getId(),
> this.getFullPath()}));
> }
> }
> }
> ...
> {code}
> However, the {{gateway-sender}}/{{async-event-queue}} has been associated to
> the region before this last check and the code doesn't catch the
> {{GatewaySenderConfigurationException}} /
> {{AsyncEventQueueConfigurationException}} within that block:
> {code:title=GemFireCacheImpl.java|borderStyle=solid}
> public Region createVMRegion(String name, RegionAttributes
> p_attrs, InternalRegionArguments internalRegionArgs) throws
> RegionExistsException, TimeoutException, IOException, ClassNotFoundException {
> ...
> region.postCreateRegion();
> } catch (RegionExistsException ex) {
> // outside of sync make sure region is initialized to fix bug 37563
> InternalRegion internalRegion = (InternalRegion) ex.getRegion();
> internalRegion.waitOnInitialization(); // don't give out ref until
> initialized
> throw ex;
> }
> ...
> {code}
> This ends up leaving the region unusable but already added to the
> {{GemFireCacheImpl.rootRegions}} field, so the cache itself is left
> inconsistent (could be even worse when the region is also configured as
> persistent).
> No big deal when the user is configuring everything using a {{cache.xml}}
> file as the exception will be propagated and the server startup will fail.
> When using {{gfsh}}, on the other hand, the command {{create region}} reports
> a failure but leaves the region partially created on every single member.
> According to [~dschneider]
> {quote}
> The intent of postCreateRegion is to do things after the region was created.
> This is the wrong place to be doing validation.
> If you look at the super.postCreateRegion that DistributionRegion calls first
> you will see it incs stats and delivers events to others telling them the
> region was created. You really can't undo that well if postCreateRegion
> fails. So I do not think it is a good idea to have postCreateRegion destroy
> the region it created.
> I think the bug here is that gateway validation is in postCreateRegion. This
> validation should be done earlier so that the region creation it self fails
> and postCreateRegion is never called.
> {quote}
> The attached script reproduces the issue both using {{gfsh}} and a
> {{cache.xml}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5256) Default Values Override GFSH StartUp Parameters
Juan José Ramos Cassella created GEODE-5256:
---
Summary: Default Values Override GFSH StartUp Parameters
Key: GEODE-5256
URL: https://issues.apache.org/jira/browse/GEODE-5256
Project: Geode
Issue Type: Bug
Components: gfsh
Reporter: Juan José Ramos Cassella
Hello team,
The order on which we apply the cache configuration vs the startup parameters
when starting servers through {{gfs}} seems to be wrong.
No matter whether the cache is configured through a local {{cache.xml}} or the
cluster configuration service, internally we end up parsing the configuration
using {{CacheXmlParser}} and {{CacheCreation}} classes. The class
{{CacheCreation}} creates a server through {{CacheServerCreation}} and this one
extends {{AbstractCacheServer}}, which has some default values configured,
overriding the values set by the startup parameters.
I've been able to reproduce this for the {{max-connections}} configuration
property specifically, but my guess is that the bug exists for *all* cache
properties that can be configured both through {{gfsh}} startup parameters and
{{cache.xml}} / {{cluster.xml}} files.
As an example, after adding some extra logging on the {{setMaxConnections()}}
method, below is the output shown when starting the server:
{noformat}
gfsh start server --name=server1 --server-port=40401
--locators=localhost[10101] --max-connections=1033
[info 2018/05/25 13:55:20.752 IST server1 tid=0x1] Initialization of
region PdxTypes completed
[X]: CacheServerImpl.setMaxConnections() is changing maxConnections from
800 to 1033.
java.lang.Throwable
at
org.apache.geode.internal.cache.CacheServerImpl.setMaxConnections(CacheServerImpl.java:209)
at
org.apache.geode.distributed.ServerLauncher.startCacheServer(ServerLauncher.java:956)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:781)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:692)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:225)
[info 2018/05/25 13:55:20.825 IST server1 tid=0x1] CacheServer
Configuration: port=40401 max-connections=1033 max-threads=0
notify-by-subscription=true socket-buffer-size=32768
maximum-time-between-pings=6 maximum-message-count=23
message-time-to-live=180 eviction-policy=none capacity=1 overflow directory=.
groups=[] loadProbe=ConnectionCountProbe loadPollInterval=5000 tcpNoDelay=true
gfsh -e start server --name=server1 --server-port=40401
--locators=localhost[10101] --max-connections=1033
--cache-xml-file=$CURRENT_DIRECTORY/server-cache.xml
[info 2018/05/25 13:56:19.593 IST server1 tid=0x1] Initialization of
region PdxTypes completed
[X]: CacheServerImpl.setMaxConnections() is changing maxConnections from
800 to 800.
java.lang.Throwable
at
org.apache.geode.internal.cache.CacheServerImpl.setMaxConnections(CacheServerImpl.java:209)
at
org.apache.geode.internal.cache.CacheServerImpl.configureFrom(CacheServerImpl.java:304)
at
org.apache.geode.internal.cache.xmlcache.CacheCreation.startCacheServers(CacheCreation.java:688)
at
org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:581)
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:337)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4307)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1434)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1226)
at
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:792)
at
org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:778)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:177)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:224)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:844)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:762)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:692)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:225)
[info 2018/05/25 13:56:19.929 IST server1 tid=0x1] CacheServer
Configuration: port=40401 max-connections=800 max-threads=0
notify-by-subscription=true socket-buffer-size=32768
maximum-time-between-pings=6 maximum-message-count=23
message-time-to-live=180 eviction-policy=none capacity=1 overflow directory=.
groups=[] load
[jira] [Updated] (GEODE-5256) Default Values Override GFSH StartUp Parameters
[
https://issues.apache.org/jira/browse/GEODE-5256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-5256:
Attachment: workspace.zip
> Default Values Override GFSH StartUp Parameters
> ---
>
> Key: GEODE-5256
> URL: https://issues.apache.org/jira/browse/GEODE-5256
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Juan José Ramos Cassella
>Priority: Major
> Attachments: workspace.zip
>
>
> Hello team,
> The order on which we apply the cache configuration vs the startup parameters
> when starting servers through {{gfs}} seems to be wrong.
> No matter whether the cache is configured through a local {{cache.xml}} or
> the cluster configuration service, internally we end up parsing the
> configuration using {{CacheXmlParser}} and {{CacheCreation}} classes. The
> class {{CacheCreation}} creates a server through {{CacheServerCreation}} and
> this one extends {{AbstractCacheServer}}, which has some default values
> configured, overriding the values set by the startup parameters.
> I've been able to reproduce this for the {{max-connections}} configuration
> property specifically, but my guess is that the bug exists for *all* cache
> properties that can be configured both through {{gfsh}} startup parameters
> and {{cache.xml}} / {{cluster.xml}} files.
> As an example, after adding some extra logging on the {{setMaxConnections()}}
> method, below is the output shown when starting the server:
> {noformat}
> gfsh start server --name=server1 --server-port=40401
> --locators=localhost[10101] --max-connections=1033
> [info 2018/05/25 13:55:20.752 IST server1 tid=0x1] Initialization of
> region PdxTypes completed
> [X]: CacheServerImpl.setMaxConnections() is changing maxConnections from
> 800 to 1033.
> java.lang.Throwable
> at
> org.apache.geode.internal.cache.CacheServerImpl.setMaxConnections(CacheServerImpl.java:209)
> at
> org.apache.geode.distributed.ServerLauncher.startCacheServer(ServerLauncher.java:956)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:781)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:692)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:225)
> [info 2018/05/25 13:55:20.825 IST server1 tid=0x1] CacheServer
> Configuration: port=40401 max-connections=1033 max-threads=0
> notify-by-subscription=true socket-buffer-size=32768
> maximum-time-between-pings=6 maximum-message-count=23
> message-time-to-live=180 eviction-policy=none capacity=1 overflow directory=.
> groups=[] loadProbe=ConnectionCountProbe loadPollInterval=5000 tcpNoDelay=true
> gfsh -e start server --name=server1 --server-port=40401
> --locators=localhost[10101] --max-connections=1033
> --cache-xml-file=$CURRENT_DIRECTORY/server-cache.xml
> [info 2018/05/25 13:56:19.593 IST server1 tid=0x1] Initialization of
> region PdxTypes completed
> [X]: CacheServerImpl.setMaxConnections() is changing maxConnections from
> 800 to 800.
> java.lang.Throwable
> at
> org.apache.geode.internal.cache.CacheServerImpl.setMaxConnections(CacheServerImpl.java:209)
> at
> org.apache.geode.internal.cache.CacheServerImpl.configureFrom(CacheServerImpl.java:304)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.startCacheServers(CacheCreation.java:688)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:581)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:337)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4307)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1434)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1226)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:792)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:778)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:177)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:224)
> at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at
> org.apache.geode.distributed.ServerLauncher.createCache(
[jira] [Assigned] (GEODE-5256) Default Values Override GFSH StartUp Parameters
[
https://issues.apache.org/jira/browse/GEODE-5256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-5256:
---
Assignee: Juan José Ramos Cassella
> Default Values Override GFSH StartUp Parameters
> ---
>
> Key: GEODE-5256
> URL: https://issues.apache.org/jira/browse/GEODE-5256
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Attachments: workspace.zip
>
>
> Hello team,
> The order on which we apply the cache configuration vs the startup parameters
> when starting servers through {{gfs}} seems to be wrong.
> No matter whether the cache is configured through a local {{cache.xml}} or
> the cluster configuration service, internally we end up parsing the
> configuration using {{CacheXmlParser}} and {{CacheCreation}} classes. The
> class {{CacheCreation}} creates a server through {{CacheServerCreation}} and
> this one extends {{AbstractCacheServer}}, which has some default values
> configured, overriding the values set by the startup parameters.
> I've been able to reproduce this for the {{max-connections}} configuration
> property specifically, but my guess is that the bug exists for *all* cache
> properties that can be configured both through {{gfsh}} startup parameters
> and {{cache.xml}} / {{cluster.xml}} files.
> As an example, after adding some extra logging on the {{setMaxConnections()}}
> method, below is the output shown when starting the server:
> {noformat}
> gfsh start server --name=server1 --server-port=40401
> --locators=localhost[10101] --max-connections=1033
> [info 2018/05/25 13:55:20.752 IST server1 tid=0x1] Initialization of
> region PdxTypes completed
> [X]: CacheServerImpl.setMaxConnections() is changing maxConnections from
> 800 to 1033.
> java.lang.Throwable
> at
> org.apache.geode.internal.cache.CacheServerImpl.setMaxConnections(CacheServerImpl.java:209)
> at
> org.apache.geode.distributed.ServerLauncher.startCacheServer(ServerLauncher.java:956)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:781)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:692)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:225)
> [info 2018/05/25 13:55:20.825 IST server1 tid=0x1] CacheServer
> Configuration: port=40401 max-connections=1033 max-threads=0
> notify-by-subscription=true socket-buffer-size=32768
> maximum-time-between-pings=6 maximum-message-count=23
> message-time-to-live=180 eviction-policy=none capacity=1 overflow directory=.
> groups=[] loadProbe=ConnectionCountProbe loadPollInterval=5000 tcpNoDelay=true
> gfsh -e start server --name=server1 --server-port=40401
> --locators=localhost[10101] --max-connections=1033
> --cache-xml-file=$CURRENT_DIRECTORY/server-cache.xml
> [info 2018/05/25 13:56:19.593 IST server1 tid=0x1] Initialization of
> region PdxTypes completed
> [X]: CacheServerImpl.setMaxConnections() is changing maxConnections from
> 800 to 800.
> java.lang.Throwable
> at
> org.apache.geode.internal.cache.CacheServerImpl.setMaxConnections(CacheServerImpl.java:209)
> at
> org.apache.geode.internal.cache.CacheServerImpl.configureFrom(CacheServerImpl.java:304)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.startCacheServers(CacheCreation.java:688)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:581)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:337)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4307)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1434)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1226)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:792)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:778)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:177)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:224)
> at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at
> o
[jira] [Updated] (GEODE-5256) GFSH Start Server Command Parameters Overridden by Default Values
[
https://issues.apache.org/jira/browse/GEODE-5256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-5256:
Summary: GFSH Start Server Command Parameters Overridden by Default Values
(was: Default Values Override GFSH StartUp Parameters)
> GFSH Start Server Command Parameters Overridden by Default Values
> -
>
> Key: GEODE-5256
> URL: https://issues.apache.org/jira/browse/GEODE-5256
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Attachments: workspace.zip
>
>
> Hello team,
> The order on which we apply the cache configuration vs the startup parameters
> when starting servers through {{gfs}} seems to be wrong.
> No matter whether the cache is configured through a local {{cache.xml}} or
> the cluster configuration service, internally we end up parsing the
> configuration using {{CacheXmlParser}} and {{CacheCreation}} classes. The
> class {{CacheCreation}} creates a server through {{CacheServerCreation}} and
> this one extends {{AbstractCacheServer}}, which has some default values
> configured, overriding the values set by the startup parameters.
> I've been able to reproduce this for the {{max-connections}} configuration
> property specifically, but my guess is that the bug exists for *all* cache
> properties that can be configured both through {{gfsh}} startup parameters
> and {{cache.xml}} / {{cluster.xml}} files.
> As an example, after adding some extra logging on the {{setMaxConnections()}}
> method, below is the output shown when starting the server:
> {noformat}
> gfsh start server --name=server1 --server-port=40401
> --locators=localhost[10101] --max-connections=1033
> [info 2018/05/25 13:55:20.752 IST server1 tid=0x1] Initialization of
> region PdxTypes completed
> [X]: CacheServerImpl.setMaxConnections() is changing maxConnections from
> 800 to 1033.
> java.lang.Throwable
> at
> org.apache.geode.internal.cache.CacheServerImpl.setMaxConnections(CacheServerImpl.java:209)
> at
> org.apache.geode.distributed.ServerLauncher.startCacheServer(ServerLauncher.java:956)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:781)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:692)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:225)
> [info 2018/05/25 13:55:20.825 IST server1 tid=0x1] CacheServer
> Configuration: port=40401 max-connections=1033 max-threads=0
> notify-by-subscription=true socket-buffer-size=32768
> maximum-time-between-pings=6 maximum-message-count=23
> message-time-to-live=180 eviction-policy=none capacity=1 overflow directory=.
> groups=[] loadProbe=ConnectionCountProbe loadPollInterval=5000 tcpNoDelay=true
> gfsh -e start server --name=server1 --server-port=40401
> --locators=localhost[10101] --max-connections=1033
> --cache-xml-file=$CURRENT_DIRECTORY/server-cache.xml
> [info 2018/05/25 13:56:19.593 IST server1 tid=0x1] Initialization of
> region PdxTypes completed
> [X]: CacheServerImpl.setMaxConnections() is changing maxConnections from
> 800 to 800.
> java.lang.Throwable
> at
> org.apache.geode.internal.cache.CacheServerImpl.setMaxConnections(CacheServerImpl.java:209)
> at
> org.apache.geode.internal.cache.CacheServerImpl.configureFrom(CacheServerImpl.java:304)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.startCacheServers(CacheCreation.java:688)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:581)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:337)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4307)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1434)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1226)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:792)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:778)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:177)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java
[jira] [Updated] (GEODE-5256) GFSH Start Server Command Parameters Overridden by Default Values
[
https://issues.apache.org/jira/browse/GEODE-5256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-5256:
Description:
Hello team,
The order on which we apply the cache configuration vs the startup parameters
when starting servers through {{gfs}} seems to be wrong.
No matter whether the cache is configured through a local {{cache.xml}} or the
cluster configuration service, internally we end up parsing the configuration
using {{CacheXmlParser}} and {{CacheCreation}} classes. The class
{{CacheCreation}} creates a server through {{CacheServerCreation}} and this one
extends {{AbstractCacheServer}}, which has some default values configured,
overriding the values set by the startup parameters.
I've been able to reproduce this for the {{max-connections}} configuration
property specifically but right now a bunch of parameters are completely
ignored if a {{cache.xml}} file is specified or if the
{{cluster-configuration-service }}is enabled, no matter if the actual parameter
is specifically configured or not, the default values are always used. In fact,
the only parameters that seem to override the {{cache.xml}} /
{{cluster-configuration}} are {{serverPort}}, {{serverBindAddress}} and
{{disableDefaultServer}}, they are communicated between the {{ServerLauncher}}
and {{CacheCreation}} classes through public static fields in the
{{CacheServerLauncher}} class.
As an example, after adding some extra logging on the {{setMaxConnections()}}
method, below is the output shown when starting the server:
{noformat}
gfsh start server --name=server1 --server-port=40401
--locators=localhost[10101] --max-connections=1033
[info 2018/05/25 13:55:20.752 IST server1 tid=0x1] Initialization of
region PdxTypes completed
[X]: CacheServerImpl.setMaxConnections() is changing maxConnections from
800 to 1033.
java.lang.Throwable
at
org.apache.geode.internal.cache.CacheServerImpl.setMaxConnections(CacheServerImpl.java:209)
at
org.apache.geode.distributed.ServerLauncher.startCacheServer(ServerLauncher.java:956)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:781)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:692)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:225)
[info 2018/05/25 13:55:20.825 IST server1 tid=0x1] CacheServer
Configuration: port=40401 max-connections=1033 max-threads=0
notify-by-subscription=true socket-buffer-size=32768
maximum-time-between-pings=6 maximum-message-count=23
message-time-to-live=180 eviction-policy=none capacity=1 overflow directory=.
groups=[] loadProbe=ConnectionCountProbe loadPollInterval=5000 tcpNoDelay=true
gfsh -e start server --name=server1 --server-port=40401
--locators=localhost[10101] --max-connections=1033
--cache-xml-file=$CURRENT_DIRECTORY/server-cache.xml
[info 2018/05/25 13:56:19.593 IST server1 tid=0x1] Initialization of
region PdxTypes completed
[X]: CacheServerImpl.setMaxConnections() is changing maxConnections from
800 to 800.
java.lang.Throwable
at
org.apache.geode.internal.cache.CacheServerImpl.setMaxConnections(CacheServerImpl.java:209)
at
org.apache.geode.internal.cache.CacheServerImpl.configureFrom(CacheServerImpl.java:304)
at
org.apache.geode.internal.cache.xmlcache.CacheCreation.startCacheServers(CacheCreation.java:688)
at
org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:581)
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:337)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4307)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1434)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1226)
at
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:792)
at
org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:778)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:177)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:224)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:844)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:762)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:692)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:225)
[info 2018/05/25 13:56:19.929 IST server1 tid=0x1] CacheServer
Configuration: port=4040
[jira] [Updated] (GEODE-5256) GFSH Start Server Command Parameters Overridden by Default Values
[
https://issues.apache.org/jira/browse/GEODE-5256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-5256:
Description:
Hello team,
The order on which we apply the cache configuration vs the startup parameters
when starting servers through {{gfs}} seems to be wrong.
No matter whether the cache is configured through a local {{cache.xml}} or the
cluster configuration service, internally we end up parsing the configuration
using {{CacheXmlParser}} and {{CacheCreation}} classes. The class
{{CacheCreation}} creates a server through {{CacheServerCreation}} and this one
extends {{AbstractCacheServer}}, which has some default values configured,
overriding the values set by the startup parameters.
I've been able to reproduce this for the {{max-connections}} configuration
property specifically but right now a bunch of parameters are completely
ignored if a {{cache.xml}} file is specified or if the
{{cluster-configuration-service}} is enabled, no matter if the actual parameter
is specifically configured or not, the default values are always used. In fact,
the only parameters that seem to override the {{cache.xml}} /
{{cluster-configuration}} are {{serverPort}}, {{serverBindAddress}} and
{{disableDefaultServer}}, they are communicated between the {{ServerLauncher}}
and {{CacheCreation}} classes through public static fields in the
{{CacheServerLauncher}} class.
As an example, after adding some extra logging on the {{setMaxConnections()}}
method, below is the output shown when starting the server:
{noformat}
gfsh start server --name=server1 --server-port=40401
--locators=localhost[10101] --max-connections=1033
[info 2018/05/25 13:55:20.752 IST server1 tid=0x1] Initialization of
region PdxTypes completed
[X]: CacheServerImpl.setMaxConnections() is changing maxConnections from
800 to 1033.
java.lang.Throwable
at
org.apache.geode.internal.cache.CacheServerImpl.setMaxConnections(CacheServerImpl.java:209)
at
org.apache.geode.distributed.ServerLauncher.startCacheServer(ServerLauncher.java:956)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:781)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:692)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:225)
[info 2018/05/25 13:55:20.825 IST server1 tid=0x1] CacheServer
Configuration: port=40401 max-connections=1033 max-threads=0
notify-by-subscription=true socket-buffer-size=32768
maximum-time-between-pings=6 maximum-message-count=23
message-time-to-live=180 eviction-policy=none capacity=1 overflow directory=.
groups=[] loadProbe=ConnectionCountProbe loadPollInterval=5000 tcpNoDelay=true
gfsh -e start server --name=server1 --server-port=40401
--locators=localhost[10101] --max-connections=1033
--cache-xml-file=$CURRENT_DIRECTORY/server-cache.xml
[info 2018/05/25 13:56:19.593 IST server1 tid=0x1] Initialization of
region PdxTypes completed
[X]: CacheServerImpl.setMaxConnections() is changing maxConnections from
800 to 800.
java.lang.Throwable
at
org.apache.geode.internal.cache.CacheServerImpl.setMaxConnections(CacheServerImpl.java:209)
at
org.apache.geode.internal.cache.CacheServerImpl.configureFrom(CacheServerImpl.java:304)
at
org.apache.geode.internal.cache.xmlcache.CacheCreation.startCacheServers(CacheCreation.java:688)
at
org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:581)
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:337)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4307)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1434)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1226)
at
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:792)
at
org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:778)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:177)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:224)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:844)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:762)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:692)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:225)
[info 2018/05/25 13:56:19.929 IST server1 tid=0x1] CacheServer
Configuration: port=4040
[jira] [Commented] (GEODE-5337) Geode1.5 end-port is not exclusive when creating a gateway-receiver
[
https://issues.apache.org/jira/browse/GEODE-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520201#comment-16520201
]
Juan José Ramos Cassella commented on GEODE-5337:
-
This certainly seems to be a bug within the documentation.
The source code explicitly includes the {{endPort}} value as part of the
possible options, and this algorithm hasn't changed since the very beginning:
{code:java}
public static int getRandomAvailablePortInRange(int rangeBase, int rangeTop,
int protocol) {
int numberOfPorts = rangeTop - rangeBase;
// do "5 times the numberOfPorts" iterations to select a port number. This
will ensure that
// each of the ports from given port range get a chance at least once
int numberOfRetrys = numberOfPorts * 5;
for (int i = 0; i < numberOfRetrys; i++) {
int port = rand.nextInt(numberOfPorts + 1) + rangeBase;// add 1 to
numberOfPorts so that
// rangeTop also
gets included
if (isPortAvailable(port, protocol, getAddress(protocol))) {
return port;
}
}
return -1;
}
{code}
> Geode1.5 end-port is not exclusive when creating a gateway-receiver
>
>
> Key: GEODE-5337
> URL: https://issues.apache.org/jira/browse/GEODE-5337
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Cui Chenxiao
>Priority: Major
> Fix For: 1.5.0
>
>
> When created, a gateway-receiver shall be assign a range of port to use.
> In document
> [http://geode.apache.org/docs/guide/16/tools_modules/gfsh/command-pages/create.html#topic_a4x_pb1_dk],
> the description for --end-port says "The {{ENDPORT}} value is exclusive
> while the {{STARTPORT}} value is inclusive. ".
>
> However, sometimes, the port number of endport is also assigned to receiver
> anyway. Beside, in code for gatewayreceiver, the endport will be randomly
> assigned to receiver.
>
> I supposed this shall be a document bug.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5347) create a gfsh command to print specified statistics
[
https://issues.apache.org/jira/browse/GEODE-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16523543#comment-16523543
]
Juan José Ramos Cassella commented on GEODE-5347:
-
I've recently developed a project that uses {{spring-boot}} and
{{spring-shell}} which does, between other things, exactly this: show the most
common statistical values (min, max, average, standard deviation and last
sample value) for a given statistic. The project can be found in
[https://github.com/jujoramos/geode-support-shell|https://github.com/jujoramos/geode-support-shell.]
and the command is {{show statistics summary}}. We can use it as the starting
point, or integrate some of the functionality into {{gfsh}}.
Cheers.
> create a gfsh command to print specified statistics
> ---
>
> Key: GEODE-5347
> URL: https://issues.apache.org/jira/browse/GEODE-5347
> Project: Geode
> Issue Type: New Feature
> Components: docs, gfsh
>Reporter: Karen Smoler Miller
>Priority: Major
>
> I would find it useful for interactive monitoring and debugging to be able to
> issue a gfsh command that prints the current value of a statistic.
> Currently, some statistics are available with the gfsh show metrics command,
> but not all. And I don't want to have to use the API to capture a value that
> I need while I'm trying to interactively debug a cluster.
> The particular case/statistic I want to see is GatewayStatistics
> eventQueueSize, which doesn't appear to be accessible by using gfsh show
> metrics command. My use case has to do with migrating data from one cluster
> to another. I want to enable a gateway sender that will "push" my region
> entries to the other cluster as entries are touched. But, once I've
> completed touching each entry to be migrated, I need to know that sender's
> queue has emptied to be able to call my migration complete.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5256) GFSH Start Server Command Parameters Overridden by Default Values
[
https://issues.apache.org/jira/browse/GEODE-5256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-5256.
-
Resolution: Fixed
Fix Version/s: 1.7.0
> GFSH Start Server Command Parameters Overridden by Default Values
> -
>
> Key: GEODE-5256
> URL: https://issues.apache.org/jira/browse/GEODE-5256
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Attachments: workspace.zip
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Hello team,
> The order on which we apply the cache configuration vs the startup parameters
> when starting servers through {{gfs}} seems to be wrong.
> No matter whether the cache is configured through a local {{cache.xml}} or
> the cluster configuration service, internally we end up parsing the
> configuration using {{CacheXmlParser}} and {{CacheCreation}} classes. The
> class {{CacheCreation}} creates a server through {{CacheServerCreation}} and
> this one extends {{AbstractCacheServer}}, which has some default values
> configured, overriding the values set by the startup parameters.
> I've been able to reproduce this for the {{max-connections}} configuration
> property specifically but right now a bunch of parameters are completely
> ignored if a {{cache.xml}} file is specified or if the
> {{cluster-configuration-service}} is enabled, no matter if the actual
> parameter is specifically configured or not, the default values are always
> used. In fact, the only parameters that seem to override the {{cache.xml}} /
> {{cluster-configuration}} are {{serverPort}}, {{serverBindAddress}} and
> {{disableDefaultServer}}, they are communicated between the
> {{ServerLauncher}} and {{CacheCreation}} classes through public static fields
> in the {{CacheServerLauncher}} class.
> As an example, after adding some extra logging on the
> {{setMaxConnections()}} method, below is the output shown when starting the
> server:
> {noformat}
> gfsh start server --name=server1 --server-port=40401
> --locators=localhost[10101] --max-connections=1033
> [info 2018/05/25 13:55:20.752 IST server1 tid=0x1] Initialization of
> region PdxTypes completed
> [X]: CacheServerImpl.setMaxConnections() is changing maxConnections from
> 800 to 1033.
> java.lang.Throwable
> at
> org.apache.geode.internal.cache.CacheServerImpl.setMaxConnections(CacheServerImpl.java:209)
> at
> org.apache.geode.distributed.ServerLauncher.startCacheServer(ServerLauncher.java:956)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:781)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:692)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:225)
> [info 2018/05/25 13:55:20.825 IST server1 tid=0x1] CacheServer
> Configuration: port=40401 max-connections=1033 max-threads=0
> notify-by-subscription=true socket-buffer-size=32768
> maximum-time-between-pings=6 maximum-message-count=23
> message-time-to-live=180 eviction-policy=none capacity=1 overflow directory=.
> groups=[] loadProbe=ConnectionCountProbe loadPollInterval=5000 tcpNoDelay=true
> gfsh -e start server --name=server1 --server-port=40401
> --locators=localhost[10101] --max-connections=1033
> --cache-xml-file=$CURRENT_DIRECTORY/server-cache.xml
> [info 2018/05/25 13:56:19.593 IST server1 tid=0x1] Initialization of
> region PdxTypes completed
> [X]: CacheServerImpl.setMaxConnections() is changing maxConnections from
> 800 to 800.
> java.lang.Throwable
> at
> org.apache.geode.internal.cache.CacheServerImpl.setMaxConnections(CacheServerImpl.java:209)
> at
> org.apache.geode.internal.cache.CacheServerImpl.configureFrom(CacheServerImpl.java:304)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.startCacheServers(CacheCreation.java:688)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:581)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:337)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4307)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1434)
>
[jira] [Assigned] (GEODE-5248) The gfsh list gateways command can show non-0 Sender Count when there are no senders connected
[
https://issues.apache.org/jira/browse/GEODE-5248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-5248:
---
Assignee: Juan José Ramos Cassella
> The gfsh list gateways command can show non-0 Sender Count when there are no
> senders connected
> --
>
> Key: GEODE-5248
> URL: https://issues.apache.org/jira/browse/GEODE-5248
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barry Oglesby
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> With three members in each site, the gfsh list gateways command shows
> something like this for the receiving site members:
> {noformat}
> Member | Port | Sender Count | Senders Connected
> - | | |
> ---
> 192.168.2.13(ny-1:90963):1026 | 5317 | 8 |
> 192.168.2.13(ln-1:91017):1029, 192.168.2.13(ln-2:91027):1030,
> 192.168.2.13(ln-3:91037):1031
> 192.168.2.13(ny-2:90979):1027 | 5232 | 8 |
> 192.168.2.13(ln-1:91017):1029, 192.168.2.13(ln-3:91037):1031,
> 192.168.2.13(ln-2:91027):1030
> 192.168.2.13(ny-3:90996):1028 | 5403 | 8 |
> 192.168.2.13(ln-1:91017):1029, 192.168.2.13(ln-2:91027):1030,
> 192.168.2.13(ln-3:91037):1031
> {noformat}
> If two of the receivers are stopped like this then the senders will connect
> to the remaining receiver:
> {noformat}
> stop gateway-receiver --member=ny-1
> Member | Result | Message
> - | -- |
> --
> 192.168.2.13(ny-1:90963):1026 | OK | GatewayReceiver is stopped on member
> 192.168.2.13(ny-1:90963):1026
> stop gateway-receiver --member=ny-2
> Member | Result | Message
> - | -- |
> --
> 192.168.2.13(ny-2:90979):1027 | OK | GatewayReceiver is stopped on member
> 192.168.2.13(ny-2:90979):1027
> {noformat}
> The list gateways command for the receiving site will show all the senders
> connected to the one remaining receiver like:
> {noformat}
> Member | Port | Sender Count | Senders Connected
> - | | |
> ---
> 192.168.2.13(ny-1:90963):1026 | 5317 | 8 |
> 192.168.2.13(ny-2:90979):1027 | 5232 | 8 |
> 192.168.2.13(ny-3:90996):1028 | 5403 | 18 |
> 192.168.2.13(ln-1:91017):1029, 192.168.2.13(ln-2:91027):1030,
> 192.168.2.13(ln-3:91037):1031
> {noformat}
> But it doesn't 0 out the Sender Count for the two members whose receiver was
> stopped. It still shows 8 even though senders are no longer connected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5314) MBeanStatsMonitor child classes should use atomics instead of volatiles to avoid data race
[
https://issues.apache.org/jira/browse/GEODE-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-5314:
---
Assignee: Juan José Ramos Cassella
> MBeanStatsMonitor child classes should use atomics instead of volatiles to
> avoid data race
> --
>
> Key: GEODE-5314
> URL: https://issues.apache.org/jira/browse/GEODE-5314
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Galen O'Sullivan
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> {{GcStatsMonitor}} has the following:
> {code}
> private volatile long collections = 0;
> private volatile long collectionTime = 0;
> {code}
>
> {code}
> collections -=
> statsMap.getOrDefault(StatsKey.VM_GC_STATS_COLLECTIONS,0).intValue();
> collectionTime -=
> statsMap.getOrDefault(StatsKey.VM_GC_STATS_COLLECTION_TIME,0).intValue();
> {code}
> Because these are volatile and not atomic fields, there will be a race
> condition. Other subclasses of {{MBeanStatsMonitor}} also use volatiles:
> AggregateRegionStatsMonitor, GatewaySenderOverflowMonitor,
> MemberLevelDiskMonitor, VMStatsMonitor.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5523) Remove DefaultHashMap
Juan José Ramos Cassella created GEODE-5523:
---
Summary: Remove DefaultHashMap
Key: GEODE-5523
URL: https://issues.apache.org/jira/browse/GEODE-5523
Project: Geode
Issue Type: Improvement
Components: general, jmx, statistics
Reporter: Juan José Ramos Cassella
The class {{MBeanStatsMonitor}} exposes the static class {{DefaultHashMap}},
which is basically a wrapper of a simple {{java.util.Map}} that returns a
default value ({{0}}) when the requested key doesn't exist.
{code}
public static class DefaultHashMap { // TODO: delete this class
private Map internalMap = new HashMap<>();
public DefaultHashMap() {}
public Number get(final String key) {
return internalMap.get(key) != null ? internalMap.get(key) : 0;
}
public void put(final String key, final Number value) {
internalMap.put(key, value);
}
public void clear() {
internalMap.clear();
}
/**
* For testing only
*/
Map getInternalMap() {
return this.internalMap;
}
}
{code}
The containing class, {{MBeanStatsMonitor}}, also has a method that prevents
{{null}} values from being returned when accessing the {{Map}}, which is
redundant:
{code}
public Number getStatistic(final String statName) {
Number value = statsMap.get(statName);
return value != null ? value : 0;
}
{code}
The class {{DefaultHashMap}} should be eliminated, and the method
{{getStatistic}} should be refactored to use {{Map.getOrDefault(Object key, V
defaultValue)}} instead of executing the logic manually.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5523) Remove DefaultHashMap
[
https://issues.apache.org/jira/browse/GEODE-5523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-5523:
---
Assignee: Juan José Ramos Cassella
> Remove DefaultHashMap
> -
>
> Key: GEODE-5523
> URL: https://issues.apache.org/jira/browse/GEODE-5523
> Project: Geode
> Issue Type: Improvement
> Components: general, jmx, statistics
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> The class {{MBeanStatsMonitor}} exposes the static class {{DefaultHashMap}},
> which is basically a wrapper of a simple {{java.util.Map}} that returns a
> default value ({{0}}) when the requested key doesn't exist.
> {code}
> public static class DefaultHashMap { // TODO: delete this class
> private Map internalMap = new HashMap<>();
> public DefaultHashMap() {}
> public Number get(final String key) {
> return internalMap.get(key) != null ? internalMap.get(key) : 0;
> }
> public void put(final String key, final Number value) {
> internalMap.put(key, value);
> }
> public void clear() {
> internalMap.clear();
> }
> /**
> * For testing only
> */
> Map getInternalMap() {
> return this.internalMap;
> }
> }
> {code}
> The containing class, {{MBeanStatsMonitor}}, also has a method that prevents
> {{null}} values from being returned when accessing the {{Map}}, which is
> redundant:
> {code}
> public Number getStatistic(final String statName) {
> Number value = statsMap.get(statName);
> return value != null ? value : 0;
> }
> {code}
> The class {{DefaultHashMap}} should be eliminated, and the method
> {{getStatistic}} should be refactored to use {{Map.getOrDefault(Object key, V
> defaultValue)}} instead of executing the logic manually.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5523) Remove DefaultHashMap
[
https://issues.apache.org/jira/browse/GEODE-5523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16568083#comment-16568083
]
Juan José Ramos Cassella commented on GEODE-5523:
-
Some of the classes that need to be modified are also affected by [pull request
2250|https://github.com/apache/geode/pull/2250], so I'll wait for that to be
{{merged}} before fixing this one (primarily to avoid conflicts during the
subsequent {{merge}}).
> Remove DefaultHashMap
> -
>
> Key: GEODE-5523
> URL: https://issues.apache.org/jira/browse/GEODE-5523
> Project: Geode
> Issue Type: Improvement
> Components: general, jmx, statistics
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> The class {{MBeanStatsMonitor}} exposes the static class {{DefaultHashMap}},
> which is basically a wrapper of a simple {{java.util.Map}} that returns a
> default value ({{0}}) when the requested key doesn't exist.
> {code}
> public static class DefaultHashMap { // TODO: delete this class
> private Map internalMap = new HashMap<>();
> public DefaultHashMap() {}
> public Number get(final String key) {
> return internalMap.get(key) != null ? internalMap.get(key) : 0;
> }
> public void put(final String key, final Number value) {
> internalMap.put(key, value);
> }
> public void clear() {
> internalMap.clear();
> }
> /**
> * For testing only
> */
> Map getInternalMap() {
> return this.internalMap;
> }
> }
> {code}
> The containing class, {{MBeanStatsMonitor}}, also has a method that prevents
> {{null}} values from being returned when accessing the {{Map}}, which is
> redundant:
> {code}
> public Number getStatistic(final String statName) {
> Number value = statsMap.get(statName);
> return value != null ? value : 0;
> }
> {code}
> The class {{DefaultHashMap}} should be eliminated, and the method
> {{getStatistic}} should be refactored to use {{Map.getOrDefault(Object key, V
> defaultValue)}} instead of executing the logic manually.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5246) QueryService.getIndexes should not return null when there are no indexes
[
https://issues.apache.org/jira/browse/GEODE-5246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-5246.
-
Resolution: Fixed
Fix Version/s: 1.7.0
Changes merged into {{develop}}.
> QueryService.getIndexes should not return null when there are no indexes
>
>
> Key: GEODE-5246
> URL: https://issues.apache.org/jira/browse/GEODE-5246
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Reporter: Jens Deppe
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> I was surprised to discover that {{QueryService.getIndexes(region)}} returned
> null when no indexes were defined. It seems like it would be cleaner (and
> less surprising) to return an empty collection. The doc says nothing about
> returning {{null}}. (Please fix the API and not the doc :) )
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5531) gfsh echo variable does not work as documented
[
https://issues.apache.org/jira/browse/GEODE-5531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-5531:
---
Assignee: Juan José Ramos Cassella
> gfsh echo variable does not work as documented
> --
>
> Key: GEODE-5531
> URL: https://issues.apache.org/jira/browse/GEODE-5531
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Derek Williams
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Fix For: 1.6.0
>
>
> Variables are [documented
> here|http://geode.apache.org/docs/guide/16/tools_modules/gfsh/useful_gfsh_shell_variables.html]
> to work with gfsh echo, but do not. This applies to both pre-defined shell
> variables and user-defined variables (set variable...).
> For example,
> {code}
> echo --string=$*
> {code}
> will show all shell variables and values, but
> {code}
> echo --string=${SYS_USER}
> {code}
> simply displays ${SYS_USER}
> Indeed,
> [EchoCommand.java|https://github.com/apache/geode/blob/78dcf4b8fa86543e882365e78f1c8e2a623bffde/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/EchoCommand.java]
> has a special case for `$*`, but does not include the other documented cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5531) gfsh echo variable does not work as documented
[
https://issues.apache.org/jira/browse/GEODE-5531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-5531:
Fix Version/s: (was: 1.6.0)
> gfsh echo variable does not work as documented
> --
>
> Key: GEODE-5531
> URL: https://issues.apache.org/jira/browse/GEODE-5531
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Derek Williams
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> Variables are [documented
> here|http://geode.apache.org/docs/guide/16/tools_modules/gfsh/useful_gfsh_shell_variables.html]
> to work with gfsh echo, but do not. This applies to both pre-defined shell
> variables and user-defined variables (set variable...).
> For example,
> {code}
> echo --string=$*
> {code}
> will show all shell variables and values, but
> {code}
> echo --string=${SYS_USER}
> {code}
> simply displays ${SYS_USER}
> Indeed,
> [EchoCommand.java|https://github.com/apache/geode/blob/78dcf4b8fa86543e882365e78f1c8e2a623bffde/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/EchoCommand.java]
> has a special case for `$*`, but does not include the other documented cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5531) gfsh echo variable does not work as documented
[
https://issues.apache.org/jira/browse/GEODE-5531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573327#comment-16573327
]
Juan José Ramos Cassella commented on GEODE-5531:
-
This is only reproducible when {{gfsh}} is not running in {{HeadlessMode}}, the
variables are correctly substituted otherwise ({{gfsh run --file}} and
{{EchoCommandIntegrationTest}} work just fine).
> gfsh echo variable does not work as documented
> --
>
> Key: GEODE-5531
> URL: https://issues.apache.org/jira/browse/GEODE-5531
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Derek Williams
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> Variables are [documented
> here|http://geode.apache.org/docs/guide/16/tools_modules/gfsh/useful_gfsh_shell_variables.html]
> to work with gfsh echo, but do not. This applies to both pre-defined shell
> variables and user-defined variables (set variable...).
> For example,
> {code}
> echo --string=$*
> {code}
> will show all shell variables and values, but
> {code}
> echo --string=${SYS_USER}
> {code}
> simply displays ${SYS_USER}
> Indeed,
> [EchoCommand.java|https://github.com/apache/geode/blob/78dcf4b8fa86543e882365e78f1c8e2a623bffde/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/EchoCommand.java]
> has a special case for `$*`, but does not include the other documented cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GEODE-5531) gfsh echo variable does not work as documented
[
https://issues.apache.org/jira/browse/GEODE-5531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573327#comment-16573327
]
Juan José Ramos Cassella edited comment on GEODE-5531 at 8/8/18 3:05 PM:
-
This is only reproducible when {{gfsh}} is not running in {{headlessMode}}, the
variables are correctly substituted otherwise ({{gfsh run --file}} and
{{EchoCommandIntegrationTest}} work just fine).
was (Author: jujoramos):
This is only reproducible when {{gfsh}} is not running in {{HeadlessMode}}, the
variables are correctly substituted otherwise ({{gfsh run --file}} and
{{EchoCommandIntegrationTest}} work just fine).
> gfsh echo variable does not work as documented
> --
>
> Key: GEODE-5531
> URL: https://issues.apache.org/jira/browse/GEODE-5531
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Derek Williams
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> Variables are [documented
> here|http://geode.apache.org/docs/guide/16/tools_modules/gfsh/useful_gfsh_shell_variables.html]
> to work with gfsh echo, but do not. This applies to both pre-defined shell
> variables and user-defined variables (set variable...).
> For example,
> {code}
> echo --string=$*
> {code}
> will show all shell variables and values, but
> {code}
> echo --string=${SYS_USER}
> {code}
> simply displays ${SYS_USER}
> Indeed,
> [EchoCommand.java|https://github.com/apache/geode/blob/78dcf4b8fa86543e882365e78f1c8e2a623bffde/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/EchoCommand.java]
> has a special case for `$*`, but does not include the other documented cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-1507) gfsh variable substitution does not work
[
https://issues.apache.org/jira/browse/GEODE-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-1507:
---
Assignee: Juan José Ramos Cassella
> gfsh variable substitution does not work
>
>
> Key: GEODE-1507
> URL: https://issues.apache.org/jira/browse/GEODE-1507
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> {noformat}
> gfsh>set variable --name=foo --value=bar
> Value for variable foo is now: bar.
> gfsh>echo --string="Hello ${foo}"
> Hello ${foo}
> {noformat}
> The problem has come in with spring-shell and jline replacement.
> {{Gfsh.executeCommand}} was replaced with {{Gfsh.executeScriptLine}} which
> ends up never being called unless a script is executed with {{run --file}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-3635) Echo command does not behave as documented
[
https://issues.apache.org/jira/browse/GEODE-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-3635:
---
Assignee: (was: Juan José Ramos Cassella)
> Echo command does not behave as documented
> --
>
> Key: GEODE-3635
> URL: https://issues.apache.org/jira/browse/GEODE-3635
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Patrick Rhomberg
>Priority: Major
>
> The Set Variable command does appear to set gfsh environment properties, but
> these values are only accessible by Java methods that use them. They do not
> parse in the bash style. For instance:
> {noformat}
> gfsh> set variable --name=FOO --value=bar
> Value for variable FOO is now: bar.
> gfsh> echo --string=${FOO}
> ${FOO}
> {noformat}
> Examining the implementation, there is an explicit special case of
> {noformat}
> gfsh> echo --string=$*
> {noformat}
> which will describe the current gfsh environment. Rather than this special
> case, this may be better suited to a Describe Environment command.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-3635) Echo command does not behave as documented
[
https://issues.apache.org/jira/browse/GEODE-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-3635:
---
Assignee: Juan José Ramos Cassella
> Echo command does not behave as documented
> --
>
> Key: GEODE-3635
> URL: https://issues.apache.org/jira/browse/GEODE-3635
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Patrick Rhomberg
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> The Set Variable command does appear to set gfsh environment properties, but
> these values are only accessible by Java methods that use them. They do not
> parse in the bash style. For instance:
> {noformat}
> gfsh> set variable --name=FOO --value=bar
> Value for variable FOO is now: bar.
> gfsh> echo --string=${FOO}
> ${FOO}
> {noformat}
> Examining the implementation, there is an explicit special case of
> {noformat}
> gfsh> echo --string=$*
> {noformat}
> which will describe the current gfsh environment. Rather than this special
> case, this may be better suited to a Describe Environment command.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-1507) gfsh variable substitution does not work
[
https://issues.apache.org/jira/browse/GEODE-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella closed GEODE-1507.
---
The work is done on GEODE-5531.
> gfsh variable substitution does not work
>
>
> Key: GEODE-1507
> URL: https://issues.apache.org/jira/browse/GEODE-1507
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> {noformat}
> gfsh>set variable --name=foo --value=bar
> Value for variable foo is now: bar.
> gfsh>echo --string="Hello ${foo}"
> Hello ${foo}
> {noformat}
> The problem has come in with spring-shell and jline replacement.
> {{Gfsh.executeCommand}} was replaced with {{Gfsh.executeScriptLine}} which
> ends up never being called unless a script is executed with {{run --file}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-1507) gfsh variable substitution does not work
[
https://issues.apache.org/jira/browse/GEODE-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-1507.
-
Resolution: Duplicate
Duplicate.
> gfsh variable substitution does not work
>
>
> Key: GEODE-1507
> URL: https://issues.apache.org/jira/browse/GEODE-1507
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> {noformat}
> gfsh>set variable --name=foo --value=bar
> Value for variable foo is now: bar.
> gfsh>echo --string="Hello ${foo}"
> Hello ${foo}
> {noformat}
> The problem has come in with spring-shell and jline replacement.
> {{Gfsh.executeCommand}} was replaced with {{Gfsh.executeScriptLine}} which
> ends up never being called unless a script is executed with {{run --file}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5248) The gfsh list gateways command can show non-0 Sender Count when there are no senders connected
[
https://issues.apache.org/jira/browse/GEODE-5248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-5248.
-
Resolution: Fixed
Fix Version/s: 1.7.0
Changes merged into develop.
> The gfsh list gateways command can show non-0 Sender Count when there are no
> senders connected
> --
>
> Key: GEODE-5248
> URL: https://issues.apache.org/jira/browse/GEODE-5248
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barry Oglesby
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> With three members in each site, the gfsh list gateways command shows
> something like this for the receiving site members:
> {noformat}
> Member | Port | Sender Count | Senders Connected
> - | | |
> ---
> 192.168.2.13(ny-1:90963):1026 | 5317 | 8 |
> 192.168.2.13(ln-1:91017):1029, 192.168.2.13(ln-2:91027):1030,
> 192.168.2.13(ln-3:91037):1031
> 192.168.2.13(ny-2:90979):1027 | 5232 | 8 |
> 192.168.2.13(ln-1:91017):1029, 192.168.2.13(ln-3:91037):1031,
> 192.168.2.13(ln-2:91027):1030
> 192.168.2.13(ny-3:90996):1028 | 5403 | 8 |
> 192.168.2.13(ln-1:91017):1029, 192.168.2.13(ln-2:91027):1030,
> 192.168.2.13(ln-3:91037):1031
> {noformat}
> If two of the receivers are stopped like this then the senders will connect
> to the remaining receiver:
> {noformat}
> stop gateway-receiver --member=ny-1
> Member | Result | Message
> - | -- |
> --
> 192.168.2.13(ny-1:90963):1026 | OK | GatewayReceiver is stopped on member
> 192.168.2.13(ny-1:90963):1026
> stop gateway-receiver --member=ny-2
> Member | Result | Message
> - | -- |
> --
> 192.168.2.13(ny-2:90979):1027 | OK | GatewayReceiver is stopped on member
> 192.168.2.13(ny-2:90979):1027
> {noformat}
> The list gateways command for the receiving site will show all the senders
> connected to the one remaining receiver like:
> {noformat}
> Member | Port | Sender Count | Senders Connected
> - | | |
> ---
> 192.168.2.13(ny-1:90963):1026 | 5317 | 8 |
> 192.168.2.13(ny-2:90979):1027 | 5232 | 8 |
> 192.168.2.13(ny-3:90996):1028 | 5403 | 18 |
> 192.168.2.13(ln-1:91017):1029, 192.168.2.13(ln-2:91027):1030,
> 192.168.2.13(ln-3:91037):1031
> {noformat}
> But it doesn't 0 out the Sender Count for the two members whose receiver was
> stopped. It still shows 8 even though senders are no longer connected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-1507) gfsh variable substitution does not work
[
https://issues.apache.org/jira/browse/GEODE-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella closed GEODE-1507.
---
Changes merged into develop.
> gfsh variable substitution does not work
>
>
> Key: GEODE-1507
> URL: https://issues.apache.org/jira/browse/GEODE-1507
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> {noformat}
> gfsh>set variable --name=foo --value=bar
> Value for variable foo is now: bar.
> gfsh>echo --string="Hello ${foo}"
> Hello ${foo}
> {noformat}
> The problem has come in with spring-shell and jline replacement.
> {{Gfsh.executeCommand}} was replaced with {{Gfsh.executeScriptLine}} which
> ends up never being called unless a script is executed with {{run --file}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-1507) gfsh variable substitution does not work
[
https://issues.apache.org/jira/browse/GEODE-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-1507:
Fix Version/s: 1.7.0
> gfsh variable substitution does not work
>
>
> Key: GEODE-1507
> URL: https://issues.apache.org/jira/browse/GEODE-1507
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Fix For: 1.7.0
>
>
> {noformat}
> gfsh>set variable --name=foo --value=bar
> Value for variable foo is now: bar.
> gfsh>echo --string="Hello ${foo}"
> Hello ${foo}
> {noformat}
> The problem has come in with spring-shell and jline replacement.
> {{Gfsh.executeCommand}} was replaced with {{Gfsh.executeScriptLine}} which
> ends up never being called unless a script is executed with {{run --file}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5531) gfsh echo variable does not work as documented
[
https://issues.apache.org/jira/browse/GEODE-5531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-5531.
-
Resolution: Fixed
Fix Version/s: 1.7.0
> gfsh echo variable does not work as documented
> --
>
> Key: GEODE-5531
> URL: https://issues.apache.org/jira/browse/GEODE-5531
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Derek Williams
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Variables are [documented
> here|http://geode.apache.org/docs/guide/16/tools_modules/gfsh/useful_gfsh_shell_variables.html]
> to work with gfsh echo, but do not. This applies to both pre-defined shell
> variables and user-defined variables (set variable...).
> For example,
> {code}
> echo --string=$*
> {code}
> will show all shell variables and values, but
> {code}
> echo --string=${SYS_USER}
> {code}
> simply displays ${SYS_USER}
> Indeed,
> [EchoCommand.java|https://github.com/apache/geode/blob/78dcf4b8fa86543e882365e78f1c8e2a623bffde/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/EchoCommand.java]
> has a special case for `$*`, but does not include the other documented cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-5531) gfsh echo variable does not work as documented
[
https://issues.apache.org/jira/browse/GEODE-5531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella closed GEODE-5531.
---
Fix already merged into {{develop}}.
> gfsh echo variable does not work as documented
> --
>
> Key: GEODE-5531
> URL: https://issues.apache.org/jira/browse/GEODE-5531
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Derek Williams
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Variables are [documented
> here|http://geode.apache.org/docs/guide/16/tools_modules/gfsh/useful_gfsh_shell_variables.html]
> to work with gfsh echo, but do not. This applies to both pre-defined shell
> variables and user-defined variables (set variable...).
> For example,
> {code}
> echo --string=$*
> {code}
> will show all shell variables and values, but
> {code}
> echo --string=${SYS_USER}
> {code}
> simply displays ${SYS_USER}
> Indeed,
> [EchoCommand.java|https://github.com/apache/geode/blob/78dcf4b8fa86543e882365e78f1c8e2a623bffde/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/EchoCommand.java]
> has a special case for `$*`, but does not include the other documented cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5618) FunctionService.onServer() and FunctionService.onRegion() fail when multiuser-authentication=true
[
https://issues.apache.org/jira/browse/GEODE-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-5618:
---
Assignee: Juan José Ramos Cassella
> FunctionService.onServer() and FunctionService.onRegion() fail when
> multiuser-authentication=true
> -
>
> Key: GEODE-5618
> URL: https://issues.apache.org/jira/browse/GEODE-5618
> Project: Geode
> Issue Type: Bug
> Components: functions, security
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> The problem resides within the {{ServerFunctionExecutor}} class, specifically
> in the following section of code:
> {code:title=ServerFunctionExecutor.java|borderStyle=solid}
> public ResultCollector execute(final String functionName) {
> (...)
> byte[] functionAttributes = getFunctionAttributes(functionName);
> if (functionAttributes == null) {
> Object obj = GetFunctionAttributeOp.execute(this.pool, functionName);
> functionAttributes = (byte[]) obj;
> addFunctionAttributes(functionName, functionAttributes);
> }
> (..)
> }
> {code}
> We are specifically executing an internal function (namely
> {{GetFunctionAttributeOp}}) to retrieve the metadata for the function
> executed by the client *without setting the user attributes* required by the
> authentication mechanism and, as such, the execution fails for this
> particular function instead of the one executed by the client (it's not even
> part of the stack trace):
> {noformat}
> Exception in thread "main" java.lang.UnsupportedOperationException: Use Pool
> APIs for doing operations when multiuser-secure-mode-enabled is set to true.
> at
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1549)
> at
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1531)
> at org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:781)
> at
> org.apache.geode.cache.client.internal.GetFunctionAttributeOp.execute(GetFunctionAttributeOp.java:24)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:310)
> {noformat}
> The other top-level methods from {{ServerFunctionExecutor}} and
> {{ServerRegionFunctionExecutor}} configure the user attributes before
> actually executing the function, that's why (as a workaround), the user can
> use {{FunctionService.onServer(regionService).execute(new MyFunction())}},
> works as expected:
> {code}
> if (proxyCache != null) {
> if (this.proxyCache.isClosed()) {
> throw proxyCache.getCacheClosedException("Cache is closed for this user.");
> }
> UserAttributes.userAttributes.set(this.proxyCache.getUserAttributes());
> }
> {code}
> The solution would be to add the same _pre-operation logic_ to the buggy
> method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5618) FunctionService.onServer() and FunctionService.onRegion() fail when multiuser-authentication=true
Juan José Ramos Cassella created GEODE-5618:
---
Summary: FunctionService.onServer() and FunctionService.onRegion()
fail when multiuser-authentication=true
Key: GEODE-5618
URL: https://issues.apache.org/jira/browse/GEODE-5618
Project: Geode
Issue Type: Bug
Components: functions, security
Reporter: Juan José Ramos Cassella
The problem resides within the {{ServerFunctionExecutor}} class, specifically
in the following section of code:
{code:title=ServerFunctionExecutor.java|borderStyle=solid}
public ResultCollector execute(final String functionName) {
(...)
byte[] functionAttributes = getFunctionAttributes(functionName);
if (functionAttributes == null) {
Object obj = GetFunctionAttributeOp.execute(this.pool, functionName);
functionAttributes = (byte[]) obj;
addFunctionAttributes(functionName, functionAttributes);
}
(..)
}
{code}
We are specifically executing an internal function (namely
{{GetFunctionAttributeOp}}) to retrieve the metadata for the function executed
by the client *without setting the user attributes* required by the
authentication mechanism and, as such, the execution fails for this particular
function instead of the one executed by the client (it's not even part of the
stack trace):
{noformat}
Exception in thread "main" java.lang.UnsupportedOperationException: Use Pool
APIs for doing operations when multiuser-secure-mode-enabled is set to true.
at
org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1549)
at
org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1531)
at org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:781)
at
org.apache.geode.cache.client.internal.GetFunctionAttributeOp.execute(GetFunctionAttributeOp.java:24)
at
org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:310)
{noformat}
The other top-level methods from {{ServerFunctionExecutor}} and
{{ServerRegionFunctionExecutor}} configure the user attributes before actually
executing the function, that's why (as a workaround), the user can use
{{FunctionService.onServer(regionService).execute(new MyFunction())}}, works as
expected:
{code}
if (proxyCache != null) {
if (this.proxyCache.isClosed()) {
throw proxyCache.getCacheClosedException("Cache is closed for this user.");
}
UserAttributes.userAttributes.set(this.proxyCache.getUserAttributes());
}
{code}
The solution would be to add the same _pre-operation logic_ to the buggy method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5353) gfsh hint should be case independent
[
https://issues.apache.org/jira/browse/GEODE-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-5353:
---
Assignee: Juan José Ramos Cassella
> gfsh hint should be case independent
>
>
> Key: GEODE-5353
> URL: https://issues.apache.org/jira/browse/GEODE-5353
> Project: Geode
> Issue Type: Improvement
> Components: docs, gfsh
>Reporter: Karen Smoler Miller
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: starter
>
> The gfsh hint command does not accept topic arguments that start with lower
> case letters. It should. Here is an example:
> {{gfsh>hint help}}
> {{Unknown topic: help. Use hint; to view the list of available topics.}}{{ }}
> {{gfsh>hint Help}}
> {{Provides usage information for gfsh & its commands.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5607) Replace org.jmock with mockito
[ https://issues.apache.org/jira/browse/GEODE-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan José Ramos Cassella reassigned GEODE-5607: --- Assignee: Juan José Ramos Cassella > Replace org.jmock with mockito > -- > > Key: GEODE-5607 > URL: https://issues.apache.org/jira/browse/GEODE-5607 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Jens Deppe >Assignee: Juan José Ramos Cassella >Priority: Major > > We should consolidate on a single mocking framework. Older tests still use > jmock which should be replaced with mockito. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3209) Standard output is not redirected to log file
[
https://issues.apache.org/jira/browse/GEODE-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16596044#comment-16596044
]
Juan José Ramos Cassella commented on GEODE-3209:
-
This is fixed through GEODE-4101. When the member stats, if the
{{--redirect-output}} parameter is configured as {{true}}, all output sent to
{{standard error}} and {{standard output}} (including the callbacks) will go to
the member's log file.
> Standard output is not redirected to log file
> -
>
> Key: GEODE-3209
> URL: https://issues.apache.org/jira/browse/GEODE-3209
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Swapnil Bawaskar
>Priority: Minor
> Labels: EaseOfUse
>
> Standard output from Callbacks (CacheListeners, CacheWriters etc) should be
> redirected to the log file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5618) FunctionService.onServer() and FunctionService.onRegion() fail when multiuser-authentication=true
[
https://issues.apache.org/jira/browse/GEODE-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-5618.
-
Resolution: Fixed
Fix Version/s: 1.7.0
> FunctionService.onServer() and FunctionService.onRegion() fail when
> multiuser-authentication=true
> -
>
> Key: GEODE-5618
> URL: https://issues.apache.org/jira/browse/GEODE-5618
> Project: Geode
> Issue Type: Bug
> Components: functions, security
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The problem resides within the {{ServerFunctionExecutor}} class, specifically
> in the following section of code:
> {code:title=ServerFunctionExecutor.java|borderStyle=solid}
> public ResultCollector execute(final String functionName) {
> (...)
> byte[] functionAttributes = getFunctionAttributes(functionName);
> if (functionAttributes == null) {
> Object obj = GetFunctionAttributeOp.execute(this.pool, functionName);
> functionAttributes = (byte[]) obj;
> addFunctionAttributes(functionName, functionAttributes);
> }
> (..)
> }
> {code}
> We are specifically executing an internal function (namely
> {{GetFunctionAttributeOp}}) to retrieve the metadata for the function
> executed by the client *without setting the user attributes* required by the
> authentication mechanism and, as such, the execution fails for this
> particular function instead of the one executed by the client (it's not even
> part of the stack trace):
> {noformat}
> Exception in thread "main" java.lang.UnsupportedOperationException: Use Pool
> APIs for doing operations when multiuser-secure-mode-enabled is set to true.
> at
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1549)
> at
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1531)
> at org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:781)
> at
> org.apache.geode.cache.client.internal.GetFunctionAttributeOp.execute(GetFunctionAttributeOp.java:24)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:310)
> {noformat}
> The other top-level methods from {{ServerFunctionExecutor}} and
> {{ServerRegionFunctionExecutor}} configure the user attributes before
> actually executing the function, that's why (as a workaround), the user can
> use {{FunctionService.onServer(regionService).execute(new MyFunction())}},
> works as expected:
> {code}
> if (proxyCache != null) {
> if (this.proxyCache.isClosed()) {
> throw proxyCache.getCacheClosedException("Cache is closed for this user.");
> }
> UserAttributes.userAttributes.set(this.proxyCache.getUserAttributes());
> }
> {code}
> The solution would be to add the same _pre-operation logic_ to the buggy
> method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5607) Replace org.jmock with mockito
[
https://issues.apache.org/jira/browse/GEODE-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-5607.
-
Resolution: Fixed
Fix Version/s: 1.8.0
Changes already merged into {{develop}}.
> Replace org.jmock with mockito
> --
>
> Key: GEODE-5607
> URL: https://issues.apache.org/jira/browse/GEODE-5607
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Jens Deppe
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> We should consolidate on a single mocking framework. Older tests still use
> jmock which should be replaced with mockito.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-2789) Rewrite AutoBalancerJUnitTest to allow refactoring of GemFireCacheImpl
[
https://issues.apache.org/jira/browse/GEODE-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-2789.
-
Resolution: Fixed
Fix Version/s: 1.8.0
Fixed via b73f8bbde3e19942093e14f090789ee7bec5a299 on GEODE-5607
> Rewrite AutoBalancerJUnitTest to allow refactoring of GemFireCacheImpl
> --
>
> Key: GEODE-2789
> URL: https://issues.apache.org/jira/browse/GEODE-2789
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Priority: Major
> Fix For: 1.8.0
>
>
> This test is so brittle that any changes to GemFireCacheImpl results in a
> bunch of JMock failures:
> {noformat}
> java.lang.IllegalArgumentException
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at
> net.sf.cglib.proxy.BridgeMethodResolver.resolveAll(BridgeMethodResolver.java:61)
> at net.sf.cglib.proxy.Enhancer.emitMethods(Enhancer.java:911)
> at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:498)
> at
> net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
> at
> net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
> at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
> at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317)
> at
> org.jmock.lib.legacy.ClassImposteriser.proxyClass(ClassImposteriser.java:121)
> at
> org.jmock.lib.legacy.ClassImposteriser.imposterise(ClassImposteriser.java:66)
> at org.jmock.Mockery.mock(Mockery.java:148)
> at org.jmock.Mockery.mock(Mockery.java:124)
> at
> org.apache.geode.cache.util.AutoBalancerJUnitTest.testFacadeCollectMemberDetails2Regions(AutoBalancerJUnitTest.java:427)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}
> {noformat}
> java.lang.IllegalArgumentException
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at
> net.sf.cglib.proxy.BridgeMethodResolver.resolveAll(BridgeMethodResolver.java:61)
> at net.sf.cglib.proxy.Enhancer.emitMethods(Enhancer.java:911)
> at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:498)
> at
> net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGenerator
[jira] [Commented] (GEODE-2789) Rewrite AutoBalancerJUnitTest to allow refactoring of GemFireCacheImpl
[
https://issues.apache.org/jira/browse/GEODE-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16606779#comment-16606779
]
Juan José Ramos Cassella commented on GEODE-2789:
-
Fixed via b73f8bbde3e19942093e14f090789ee7bec5a299 on GEODE-5607.
> Rewrite AutoBalancerJUnitTest to allow refactoring of GemFireCacheImpl
> --
>
> Key: GEODE-2789
> URL: https://issues.apache.org/jira/browse/GEODE-2789
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Priority: Major
> Fix For: 1.8.0
>
>
> This test is so brittle that any changes to GemFireCacheImpl results in a
> bunch of JMock failures:
> {noformat}
> java.lang.IllegalArgumentException
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at
> net.sf.cglib.proxy.BridgeMethodResolver.resolveAll(BridgeMethodResolver.java:61)
> at net.sf.cglib.proxy.Enhancer.emitMethods(Enhancer.java:911)
> at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:498)
> at
> net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
> at
> net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
> at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
> at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317)
> at
> org.jmock.lib.legacy.ClassImposteriser.proxyClass(ClassImposteriser.java:121)
> at
> org.jmock.lib.legacy.ClassImposteriser.imposterise(ClassImposteriser.java:66)
> at org.jmock.Mockery.mock(Mockery.java:148)
> at org.jmock.Mockery.mock(Mockery.java:124)
> at
> org.apache.geode.cache.util.AutoBalancerJUnitTest.testFacadeCollectMemberDetails2Regions(AutoBalancerJUnitTest.java:427)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}
> {noformat}
> java.lang.IllegalArgumentException
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at
> net.sf.cglib.proxy.BridgeMethodResolver.resolveAll(BridgeMethodResolver.java:61)
> at net.sf.cglib.proxy.Enhancer.emitMethods(Enhancer.java:911)
> at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:498)
> at
> net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGener
[jira] [Issue Comment Deleted] (GEODE-2789) Rewrite AutoBalancerJUnitTest to allow refactoring of GemFireCacheImpl
[
https://issues.apache.org/jira/browse/GEODE-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-2789:
Comment: was deleted
(was: Fixed via b73f8bbde3e19942093e14f090789ee7bec5a299 on GEODE-5607.)
> Rewrite AutoBalancerJUnitTest to allow refactoring of GemFireCacheImpl
> --
>
> Key: GEODE-2789
> URL: https://issues.apache.org/jira/browse/GEODE-2789
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Priority: Major
> Fix For: 1.8.0
>
>
> This test is so brittle that any changes to GemFireCacheImpl results in a
> bunch of JMock failures:
> {noformat}
> java.lang.IllegalArgumentException
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at
> net.sf.cglib.proxy.BridgeMethodResolver.resolveAll(BridgeMethodResolver.java:61)
> at net.sf.cglib.proxy.Enhancer.emitMethods(Enhancer.java:911)
> at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:498)
> at
> net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
> at
> net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
> at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
> at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317)
> at
> org.jmock.lib.legacy.ClassImposteriser.proxyClass(ClassImposteriser.java:121)
> at
> org.jmock.lib.legacy.ClassImposteriser.imposterise(ClassImposteriser.java:66)
> at org.jmock.Mockery.mock(Mockery.java:148)
> at org.jmock.Mockery.mock(Mockery.java:124)
> at
> org.apache.geode.cache.util.AutoBalancerJUnitTest.testFacadeCollectMemberDetails2Regions(AutoBalancerJUnitTest.java:427)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}
> {noformat}
> java.lang.IllegalArgumentException
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at
> net.sf.cglib.proxy.BridgeMethodResolver.resolveAll(BridgeMethodResolver.java:61)
> at net.sf.cglib.proxy.Enhancer.emitMethods(Enhancer.java:911)
> at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:498)
> at
> net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGenerator
[jira] [Resolved] (GEODE-5353) gfsh hint should be case independent
[
https://issues.apache.org/jira/browse/GEODE-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-5353.
-
Resolution: Fixed
Fix Version/s: 1.8.0
Replaced the internal {{HashMap}} containing the {{topics}} for a {{TreeMap}}
with the {{String.CASE_INSENSITIVE_ORDER}} comparator.
> gfsh hint should be case independent
>
>
> Key: GEODE-5353
> URL: https://issues.apache.org/jira/browse/GEODE-5353
> Project: Geode
> Issue Type: Improvement
> Components: docs, gfsh
>Reporter: Karen Smoler Miller
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available, starter
> Fix For: 1.8.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The gfsh hint command does not accept topic arguments that start with lower
> case letters. It should. Here is an example:
> {{gfsh>hint help}}
> {{Unknown topic: help. Use hint; to view the list of available topics.}}{{ }}
> {{gfsh>hint Help}}
> {{Provides usage information for gfsh & its commands.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5314) MBeanStatsMonitor child classes should use atomics instead of volatiles to avoid data race
[
https://issues.apache.org/jira/browse/GEODE-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-5314.
-
Resolution: Fixed
Fix Version/s: 1.8.0
Changes merged into develop through
[be52507b73e46cf1b8578b23c4ea41ee40afc625|https://github.com/apache/geode/commit/be52507b73e46cf1b8578b23c4ea41ee40afc625].
> MBeanStatsMonitor child classes should use atomics instead of volatiles to
> avoid data race
> --
>
> Key: GEODE-5314
> URL: https://issues.apache.org/jira/browse/GEODE-5314
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Galen O'Sullivan
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 7h
> Remaining Estimate: 0h
>
> {{GcStatsMonitor}} has the following:
> {code}
> private volatile long collections = 0;
> private volatile long collectionTime = 0;
> {code}
>
> {code}
> collections -=
> statsMap.getOrDefault(StatsKey.VM_GC_STATS_COLLECTIONS,0).intValue();
> collectionTime -=
> statsMap.getOrDefault(StatsKey.VM_GC_STATS_COLLECTION_TIME,0).intValue();
> {code}
> Because these are volatile and not atomic fields, there will be a race
> condition. Other subclasses of {{MBeanStatsMonitor}} also use volatiles:
> AggregateRegionStatsMonitor, GatewaySenderOverflowMonitor,
> MemberLevelDiskMonitor, VMStatsMonitor.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5523) Remove DefaultHashMap
[
https://issues.apache.org/jira/browse/GEODE-5523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-5523.
-
Resolution: Fixed
Fix Version/s: 1.8.0
Changes merged into {{develop}} through commit
[8e3c5bb|https://github.com/apache/geode/commit/8e3c5bb35b8de490fe69c7f18fba3c32cac69227].
> Remove DefaultHashMap
> -
>
> Key: GEODE-5523
> URL: https://issues.apache.org/jira/browse/GEODE-5523
> Project: Geode
> Issue Type: Improvement
> Components: general, jmx, statistics
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The class {{MBeanStatsMonitor}} exposes the static class {{DefaultHashMap}},
> which is basically a wrapper of a simple {{java.util.Map}} that returns a
> default value ({{0}}) when the requested key doesn't exist.
> {code}
> public static class DefaultHashMap { // TODO: delete this class
> private Map internalMap = new HashMap<>();
> public DefaultHashMap() {}
> public Number get(final String key) {
> return internalMap.get(key) != null ? internalMap.get(key) : 0;
> }
> public void put(final String key, final Number value) {
> internalMap.put(key, value);
> }
> public void clear() {
> internalMap.clear();
> }
> /**
> * For testing only
> */
> Map getInternalMap() {
> return this.internalMap;
> }
> }
> {code}
> The containing class, {{MBeanStatsMonitor}}, also has a method that prevents
> {{null}} values from being returned when accessing the {{Map}}, which is
> redundant:
> {code}
> public Number getStatistic(final String statName) {
> Number value = statsMap.get(statName);
> return value != null ? value : 0;
> }
> {code}
> The class {{DefaultHashMap}} should be eliminated, and the method
> {{getStatistic}} should be refactored to use {{Map.getOrDefault(Object key, V
> defaultValue)}} instead of executing the logic manually.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5771) Geode should not allow user to configure pdx persistence on a client
[ https://issues.apache.org/jira/browse/GEODE-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan José Ramos Cassella reassigned GEODE-5771: --- Assignee: Juan José Ramos Cassella > Geode should not allow user to configure pdx persistence on a client > > > Key: GEODE-5771 > URL: https://issues.apache.org/jira/browse/GEODE-5771 > Project: Geode > Issue Type: Bug >Reporter: Dan Smith >Assignee: Juan José Ramos Cassella >Priority: Major > > Geode currently does not support persistence of PDX data on the client side. > This is to avoid dealing with issues that might arise if the client's PDX > data is inconsistent with the server side. > However, the client side API and XSD still allow the user to set pdx to be > persistent. It appears that this setting is simply ignored: > See ClientCacheFactory.setPdxPersistent and cache-1.0.xsd (the client-cache > element embeds a pdx element which has a persistence flag. > These methods should be deprecated or removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5771) Geode should not allow user to configure pdx persistence on a client
[ https://issues.apache.org/jira/browse/GEODE-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan José Ramos Cassella resolved GEODE-5771. - Resolution: Fixed Fix Version/s: 1.8.0 Merged into develop through commit [fbb132f|https://github.com/apache/geode/commit/fbb132f227e81fa8aa79367d0394098eb967359d]. > Geode should not allow user to configure pdx persistence on a client > > > Key: GEODE-5771 > URL: https://issues.apache.org/jira/browse/GEODE-5771 > Project: Geode > Issue Type: Bug >Reporter: Dan Smith >Assignee: Juan José Ramos Cassella >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Geode currently does not support persistence of PDX data on the client side. > This is to avoid dealing with issues that might arise if the client's PDX > data is inconsistent with the server side. > However, the client side API and XSD still allow the user to set pdx to be > persistent. It appears that this setting is simply ignored: > See ClientCacheFactory.setPdxPersistent and cache-1.0.xsd (the client-cache > element embeds a pdx element which has a persistence flag. > These methods should be deprecated or removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5830) ssl-enabled-components does not actually support "none"
[
https://issues.apache.org/jira/browse/GEODE-5830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-5830:
---
Assignee: Juan José Ramos Cassella
> ssl-enabled-components does not actually support "none"
> ---
>
> Key: GEODE-5830
> URL: https://issues.apache.org/jira/browse/GEODE-5830
> Project: Geode
> Issue Type: Bug
> Components: configuration, docs, messaging
>Reporter: Galen O'Sullivan
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> ConfigurationProperties.ssl-enabled-components says in its docs that "none"
> is a valid setting, but actually that throws an error when the Cache is
> created. This could be made a valid option or the docs just corrected.
> Docs:
> {code}
> /**
>* Options: "all","server","cluster","gateway","web","jmx","none" --
> As described
>* {@link org.apache.geode.security.SecurableCommunicationChannels}
> Since: Geode 1.0
>*/
> String SSL_ENABLED_COMPONENTS = "ssl-enabled-components";
> {code}
> This test fails with the exception that follows it:
> {code}
> @Test
> public void test() {
> final Properties properties = new Properties();
> properties.setProperty(ConfigurationProperties.SSL_ENABLED_COMPONENTS,
> "none");
> try (final Cache cache = new CacheFactory(properties).create()) {
> }
> }
> {code}
> {noformat}
> java.lang.IllegalArgumentException: org.apache.geode.GemFireConfigException:
> There is no registered component for the name: none
> at
> org.apache.geode.internal.AbstractConfig.commaDelimitedStringToSecurableCommunicationChannels(AbstractConfig.java:403)
> at
> org.apache.geode.internal.AbstractConfig.setAttribute(AbstractConfig.java:275)
> at
> org.apache.geode.distributed.internal.DistributionConfigImpl.initialize(DistributionConfigImpl.java:1623)
> at
> org.apache.geode.distributed.internal.DistributionConfigImpl.(DistributionConfigImpl.java:984)
> at
> org.apache.geode.distributed.internal.DistributionConfigImpl.(DistributionConfigImpl.java:893)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.(InternalDistributedSystem.java:530)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:354)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:343)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:335)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:211)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:219)
> at
> org.apache.geode.distributed.ConfigurationPropertiesTest.test(ConfigurationPropertiesTest.java:18)
> 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:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JU
[jira] [Updated] (GEODE-5838) Suppress javadoc generation warnings
[
https://issues.apache.org/jira/browse/GEODE-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-5838:
Priority: Trivial (was: Major)
> Suppress javadoc generation warnings
>
>
> Key: GEODE-5838
> URL: https://issues.apache.org/jira/browse/GEODE-5838
> Project: Geode
> Issue Type: Improvement
> Components: build
>Reporter: Juan José Ramos Cassella
>Priority: Trivial
>
> When compiling the project, the task {{geode-dunit:javadoc}} task generates
> the following warnings, polluting the build output:
> {noformat}
> > Task :geode-dunit:javadoc
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAccessController.java:32:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAuthenticator.java:34:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAccessController.java:32:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAuthenticator.java:34:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAccessController.java:32:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAuthenticator.java:34:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> {noformat}
> The {{@link}} tag incorrectly references a test class (it should reference
> the production interface), which is not part of the build class path when
> generating the {{javadocs}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5838) Suppress javadoc generation warnings
Juan José Ramos Cassella created GEODE-5838:
---
Summary: Suppress javadoc generation warnings
Key: GEODE-5838
URL: https://issues.apache.org/jira/browse/GEODE-5838
Project: Geode
Issue Type: Improvement
Components: build
Reporter: Juan José Ramos Cassella
When compiling the project, the task {{geode-dunit:javadoc}} task generates the
following warnings, polluting the build output:
{noformat}
> Task :geode-dunit:javadoc
/Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAccessController.java:32:
warning - Tag @link: reference not found:
org.apache.geode.examples.SimpleSecurityManager
/Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAuthenticator.java:34:
warning - Tag @link: reference not found:
org.apache.geode.examples.SimpleSecurityManager
/Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAccessController.java:32:
warning - Tag @link: reference not found:
org.apache.geode.examples.SimpleSecurityManager
/Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAuthenticator.java:34:
warning - Tag @link: reference not found:
org.apache.geode.examples.SimpleSecurityManager
/Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAccessController.java:32:
warning - Tag @link: reference not found:
org.apache.geode.examples.SimpleSecurityManager
/Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAuthenticator.java:34:
warning - Tag @link: reference not found:
org.apache.geode.examples.SimpleSecurityManager
{noformat}
The {{@link}} tag incorrectly references a test class (it should reference the
production interface), which is not part of the build class path when
generating the {{javadocs}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5838) Suppress javadoc generation warnings
[
https://issues.apache.org/jira/browse/GEODE-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-5838:
---
Assignee: Juan José Ramos Cassella
> Suppress javadoc generation warnings
>
>
> Key: GEODE-5838
> URL: https://issues.apache.org/jira/browse/GEODE-5838
> Project: Geode
> Issue Type: Improvement
> Components: build
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Trivial
>
> When compiling the project, the task {{geode-dunit:javadoc}} task generates
> the following warnings, polluting the build output:
> {noformat}
> > Task :geode-dunit:javadoc
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAccessController.java:32:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAuthenticator.java:34:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAccessController.java:32:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAuthenticator.java:34:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAccessController.java:32:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAuthenticator.java:34:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> {noformat}
> The {{@link}} tag incorrectly references a test class (it should reference
> the production interface), which is not part of the build class path when
> generating the {{javadocs}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5739) Server and LocatorStarter Rules should use respective Launchers
[ https://issues.apache.org/jira/browse/GEODE-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan José Ramos Cassella reassigned GEODE-5739: --- Assignee: Juan José Ramos Cassella > Server and LocatorStarter Rules should use respective Launchers > --- > > Key: GEODE-5739 > URL: https://issues.apache.org/jira/browse/GEODE-5739 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Jason Huynh >Assignee: Juan José Ramos Cassella >Priority: Major > > In a review, it was mentioned from that we can change ServerStarterRule and > LocatorStarterRule to use ServerLauncher and LocatorLauncher. > This way the rules are using the User API directly. The Launchers are > in-process APIs so they don't launch/fork new JVMs, they simply launch a > Server or a Locator. The APIs also include stopping and this stopMember() > method could then simply invoke serverLauncher.stop(). > PS: The forking of Server/Locator JVMs is performed by GFSH, not by these > Launcher classes. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5838) Suppress javadoc generation warnings
[
https://issues.apache.org/jira/browse/GEODE-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-5838.
-
Resolution: Fixed
Fix Version/s: 1.8.0
Changes merged into {{develop}} through
[4025ebf|https://github.com/apache/geode/commit/4025ebfd3396d4dda5f7c1d90540266aeed8c448].
> Suppress javadoc generation warnings
>
>
> Key: GEODE-5838
> URL: https://issues.apache.org/jira/browse/GEODE-5838
> Project: Geode
> Issue Type: Improvement
> Components: build
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When compiling the project, the task {{geode-dunit:javadoc}} task generates
> the following warnings, polluting the build output:
> {noformat}
> > Task :geode-dunit:javadoc
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAccessController.java:32:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAuthenticator.java:34:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAccessController.java:32:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAuthenticator.java:34:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAccessController.java:32:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAuthenticator.java:34:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> {noformat}
> The {{@link}} tag incorrectly references a test class (it should reference
> the production interface), which is not part of the build class path when
> generating the {{javadocs}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5830) ssl-enabled-components does not actually support "none"
[
https://issues.apache.org/jira/browse/GEODE-5830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-5830.
-
Resolution: Fixed
Fix Version/s: 1.8.0
Merged into {{develop}} through commit
[16cd4ae|https://github.com/apache/geode/commit/16cd4ae114db101d6030bdbeecdd09b4f932a61e].
> ssl-enabled-components does not actually support "none"
> ---
>
> Key: GEODE-5830
> URL: https://issues.apache.org/jira/browse/GEODE-5830
> Project: Geode
> Issue Type: Bug
> Components: configuration, docs, messaging
>Reporter: Galen O'Sullivan
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> ConfigurationProperties.ssl-enabled-components says in its docs that "none"
> is a valid setting, but actually that throws an error when the Cache is
> created. This could be made a valid option or the docs just corrected.
> Docs:
> {code}
> /**
>* Options: "all","server","cluster","gateway","web","jmx","none" --
> As described
>* {@link org.apache.geode.security.SecurableCommunicationChannels}
> Since: Geode 1.0
>*/
> String SSL_ENABLED_COMPONENTS = "ssl-enabled-components";
> {code}
> This test fails with the exception that follows it:
> {code}
> @Test
> public void test() {
> final Properties properties = new Properties();
> properties.setProperty(ConfigurationProperties.SSL_ENABLED_COMPONENTS,
> "none");
> try (final Cache cache = new CacheFactory(properties).create()) {
> }
> }
> {code}
> {noformat}
> java.lang.IllegalArgumentException: org.apache.geode.GemFireConfigException:
> There is no registered component for the name: none
> at
> org.apache.geode.internal.AbstractConfig.commaDelimitedStringToSecurableCommunicationChannels(AbstractConfig.java:403)
> at
> org.apache.geode.internal.AbstractConfig.setAttribute(AbstractConfig.java:275)
> at
> org.apache.geode.distributed.internal.DistributionConfigImpl.initialize(DistributionConfigImpl.java:1623)
> at
> org.apache.geode.distributed.internal.DistributionConfigImpl.(DistributionConfigImpl.java:984)
> at
> org.apache.geode.distributed.internal.DistributionConfigImpl.(DistributionConfigImpl.java:893)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.(InternalDistributedSystem.java:530)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:354)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:343)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:335)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:211)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:219)
> at
> org.apache.geode.distributed.ConfigurationPropertiesTest.test(ConfigurationPropertiesTest.java:18)
> 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:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRun
[jira] [Resolved] (GEODE-5739) Server and LocatorStarter Rules should use respective Launchers
[ https://issues.apache.org/jira/browse/GEODE-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan José Ramos Cassella resolved GEODE-5739. - Resolution: Won't Fix Looks like there's enough consent in that the JIRA must not be fixed (see this [discussion|https://github.com/apache/geode/pull/2604]). > Server and LocatorStarter Rules should use respective Launchers > --- > > Key: GEODE-5739 > URL: https://issues.apache.org/jira/browse/GEODE-5739 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Jason Huynh >Assignee: Juan José Ramos Cassella >Priority: Major > Labels: pull-request-available > Time Spent: 2h 10m > Remaining Estimate: 0h > > In a review, it was mentioned from that we can change ServerStarterRule and > LocatorStarterRule to use ServerLauncher and LocatorLauncher. > This way the rules are using the User API directly. The Launchers are > in-process APIs so they don't launch/fork new JVMs, they simply launch a > Server or a Locator. The APIs also include stopping and this stopMember() > method could then simply invoke serverLauncher.stop(). > PS: The forking of Server/Locator JVMs is performed by GFSH, not by these > Launcher classes. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3209) Standard output is not redirected to log file
[
https://issues.apache.org/jira/browse/GEODE-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella closed GEODE-3209.
---
This is fixed through GEODE-4101. When the member starts, if the
{{--redirect-output}} parameter is configured as {{true}}, all output sent to
{{standard error}} and {{standard output}} (including the callbacks) will go to
the member's log file.
> Standard output is not redirected to log file
> -
>
> Key: GEODE-3209
> URL: https://issues.apache.org/jira/browse/GEODE-3209
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Swapnil Bawaskar
>Priority: Minor
> Labels: EaseOfUse
> Fix For: 1.5.0
>
>
> Standard output from Callbacks (CacheListeners, CacheWriters etc) should be
> redirected to the log file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-1241) Rename classes and methods that are misspelled with "propogation"
[ https://issues.apache.org/jira/browse/GEODE-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan José Ramos Cassella resolved GEODE-1241. - Resolution: Fixed Fix Version/s: 1.7.0 Already fixed through commit [6f37769cd9311df39bdf0d8f4809c425f2865fe8|https://github.com/apache/geode/commit/6f37769cd9311df39bdf0d8f4809c425f2865fe8]. > Rename classes and methods that are misspelled with "propogation" > - > > Key: GEODE-1241 > URL: https://issues.apache.org/jira/browse/GEODE-1241 > Project: Geode > Issue Type: Wish > Components: general >Reporter: Kirk Lund >Priority: Trivial > Labels: starter > Fix For: 1.7.0 > > > The correct spelling is "propagation" > ConcurrentWANPropogation_1_DUnitTest > ConcurrentWANPropogation_2_DUnitTest > ConcurrentWANPropogation_2_DUnitTest.testSerialPropogationWithFilter > DataSerializerPropogationDUnitTest > ParallelWANPropogationConcurrentOpsOffHeapDUnitTest > ParallelWANStatsDUnitTest.testParallelPropogationWithFilter > SerialWANPropogationDUnitTest > SerialWANPropogationOffHeapDUnitTest > SerialWANPropogation_PartitionedRegionDUnitTest > SerialWANPropogation_PartitionedRegionOffHeapDUnitTest > SerialWANPropogationsFeatureDUnitTest > SerialWANPropogationsFeatureDUnitTest.testSerialPropogationWithFilter > SerialWANStatsDUnitTest.testSerialPropogationWithFilter > There are some misspellings in comments as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3209) Standard output is not redirected to log file
[ https://issues.apache.org/jira/browse/GEODE-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan José Ramos Cassella resolved GEODE-3209. - Resolution: Fixed Fix Version/s: 1.5.0 > Standard output is not redirected to log file > - > > Key: GEODE-3209 > URL: https://issues.apache.org/jira/browse/GEODE-3209 > Project: Geode > Issue Type: Bug > Components: logging >Reporter: Swapnil Bawaskar >Priority: Minor > Labels: EaseOfUse > Fix For: 1.5.0 > > > Standard output from Callbacks (CacheListeners, CacheWriters etc) should be > redirected to the log file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-3835) DistributedSystemBridgeJUnitTest should use TemporaryFolder
[ https://issues.apache.org/jira/browse/GEODE-3835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan José Ramos Cassella reassigned GEODE-3835: --- Assignee: Juan José Ramos Cassella > DistributedSystemBridgeJUnitTest should use TemporaryFolder > --- > > Key: GEODE-3835 > URL: https://issues.apache.org/jira/browse/GEODE-3835 > Project: Geode > Issue Type: Improvement > Components: jmx, management, tests >Reporter: Kirk Lund >Assignee: Juan José Ramos Cassella >Priority: Major > Labels: Ci, starter > > DistributedSystemBridgeJUnitTest should use TemporaryFolder instead of "/tmp". > [separated DistributedSystemBridgeJUnitTest from GEODE-1338] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5667) gfsh create gateway-receiver option "--manual-start" has counterintuitive default
[ https://issues.apache.org/jira/browse/GEODE-5667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan José Ramos Cassella reassigned GEODE-5667: --- Assignee: Juan José Ramos Cassella > gfsh create gateway-receiver option "--manual-start" has counterintuitive > default > - > > Key: GEODE-5667 > URL: https://issues.apache.org/jira/browse/GEODE-5667 > Project: Geode > Issue Type: Improvement > Components: docs, gfsh >Affects Versions: 1.6.0 >Reporter: Dave Barnes >Assignee: Juan José Ramos Cassella >Priority: Major > > The "--manual-start" option for the `gfsh create gateway-receiver` command, > when specified without a value (=true or =false), should set > manual-start=true. > Current behavior is that if specified without a value, the parameter is set > to null, which invokes the system's default behavior, which happens to be > `false`. > This is counterintuitive to the user, who (I'm certain) would expect > `--manual-start` to result in the parameter being set to `true`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5873) Some DUnitTest calls VMProvider.invokeInEveryMember without member arguments
[
https://issues.apache.org/jira/browse/GEODE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-5873:
---
Assignee: Juan José Ramos Cassella
> Some DUnitTest calls VMProvider.invokeInEveryMember without member arguments
> -
>
> Key: GEODE-5873
> URL: https://issues.apache.org/jira/browse/GEODE-5873
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Jianxia Chen
>Assignee: Juan José Ramos Cassella
>Priority: Trivial
> Labels: beginner
> Fix For: 1.8.0
>
>
> In some of the DUnitTest, when it calls {{VMProvider.invokeInEveryMember}}
> without providing the member argument. And the result is an no-op, because
> there is no member to execute the {{SerializableRunnableIF}}. e.g. in
> {{CreateJndiBindingCommandDUnitTest}} and
> {{DestroyJndiBindingCommandDUnitTest}}, {{VMProvider.invokeInEveryMember}} is
> called without any member. It probably should be passed {{server1, server2.}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-1241) Rename classes and methods that are misspelled with "propogation"
[ https://issues.apache.org/jira/browse/GEODE-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan José Ramos Cassella closed GEODE-1241. --- > Rename classes and methods that are misspelled with "propogation" > - > > Key: GEODE-1241 > URL: https://issues.apache.org/jira/browse/GEODE-1241 > Project: Geode > Issue Type: Wish > Components: general >Reporter: Kirk Lund >Priority: Trivial > Labels: starter > Fix For: 1.7.0 > > > The correct spelling is "propagation" > ConcurrentWANPropogation_1_DUnitTest > ConcurrentWANPropogation_2_DUnitTest > ConcurrentWANPropogation_2_DUnitTest.testSerialPropogationWithFilter > DataSerializerPropogationDUnitTest > ParallelWANPropogationConcurrentOpsOffHeapDUnitTest > ParallelWANStatsDUnitTest.testParallelPropogationWithFilter > SerialWANPropogationDUnitTest > SerialWANPropogationOffHeapDUnitTest > SerialWANPropogation_PartitionedRegionDUnitTest > SerialWANPropogation_PartitionedRegionOffHeapDUnitTest > SerialWANPropogationsFeatureDUnitTest > SerialWANPropogationsFeatureDUnitTest.testSerialPropogationWithFilter > SerialWANStatsDUnitTest.testSerialPropogationWithFilter > There are some misspellings in comments as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5873) Some DUnitTest calls VMProvider.invokeInEveryMember without member arguments
[
https://issues.apache.org/jira/browse/GEODE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-5873:
Fix Version/s: (was: 1.8.0)
1.9.0
> Some DUnitTest calls VMProvider.invokeInEveryMember without member arguments
> -
>
> Key: GEODE-5873
> URL: https://issues.apache.org/jira/browse/GEODE-5873
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Jianxia Chen
>Assignee: Juan José Ramos Cassella
>Priority: Trivial
> Labels: beginner, pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In some of the DUnitTest, when it calls {{VMProvider.invokeInEveryMember}}
> without providing the member argument. And the result is an no-op, because
> there is no member to execute the {{SerializableRunnableIF}}. e.g. in
> {{CreateJndiBindingCommandDUnitTest}} and
> {{DestroyJndiBindingCommandDUnitTest}}, {{VMProvider.invokeInEveryMember}} is
> called without any member. It probably should be passed {{server1, server2.}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5873) Some DUnitTest calls VMProvider.invokeInEveryMember without member arguments
[
https://issues.apache.org/jira/browse/GEODE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-5873.
-
Resolution: Fixed
Changes merged into develop through commit id
[7b252a6|https://github.com/apache/geode/commit/7b252a628379d21fcafb34ce96357c434357a108]
> Some DUnitTest calls VMProvider.invokeInEveryMember without member arguments
> -
>
> Key: GEODE-5873
> URL: https://issues.apache.org/jira/browse/GEODE-5873
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Jianxia Chen
>Assignee: Juan José Ramos Cassella
>Priority: Trivial
> Labels: beginner, pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In some of the DUnitTest, when it calls {{VMProvider.invokeInEveryMember}}
> without providing the member argument. And the result is an no-op, because
> there is no member to execute the {{SerializableRunnableIF}}. e.g. in
> {{CreateJndiBindingCommandDUnitTest}} and
> {{DestroyJndiBindingCommandDUnitTest}}, {{VMProvider.invokeInEveryMember}} is
> called without any member. It probably should be passed {{server1, server2.}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5871) TransactionUtils should be replaced by a static Logger
[ https://issues.apache.org/jira/browse/GEODE-5871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan José Ramos Cassella reassigned GEODE-5871: --- Assignee: Juan José Ramos Cassella > TransactionUtils should be replaced by a static Logger > -- > > Key: GEODE-5871 > URL: https://issues.apache.org/jira/browse/GEODE-5871 > Project: Geode > Issue Type: Improvement > Components: logging >Reporter: Jianxia Chen >Assignee: Juan José Ramos Cassella >Priority: Trivial > > TransactionUtils existed back when loggers only existed when the distributed > system was connected. Now that each class can have its own static logger that > will exist for the lifetime of that class, TransactionUtils can be removed > and any code that uses it can use a static logger created by calling > LogService.getLogger(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5871) TransactionUtils should be replaced by a static Logger
[ https://issues.apache.org/jira/browse/GEODE-5871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan José Ramos Cassella reassigned GEODE-5871: --- Assignee: (was: Juan José Ramos Cassella) > TransactionUtils should be replaced by a static Logger > -- > > Key: GEODE-5871 > URL: https://issues.apache.org/jira/browse/GEODE-5871 > Project: Geode > Issue Type: Improvement > Components: logging >Reporter: Jianxia Chen >Priority: Trivial > > TransactionUtils existed back when loggers only existed when the distributed > system was connected. Now that each class can have its own static logger that > will exist for the lifetime of that class, TransactionUtils can be removed > and any code that uses it can use a static logger created by calling > LogService.getLogger(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6042) Change VMProvider import (commons.lang -> commons.lang3)
Juan José Ramos Cassella created GEODE-6042:
---
Summary: Change VMProvider import (commons.lang -> commons.lang3)
Key: GEODE-6042
URL: https://issues.apache.org/jira/browse/GEODE-6042
Project: Geode
Issue Type: Bug
Reporter: Juan José Ramos Cassella
The latest
[commit|https://github.com/apache/geode/commit/7b252a628379d21fcafb34ce96357c434357a108]
to {{develop}} doesn't compile because {{commons-lang}} was upgraded to
{{commons-lang3}}, the import used by {{VMProvider}} is wrong.
[CI builds|https://github.com/apache/geode/pull/2812] were completely green
when the PR was opened, but the {{commons-lang}} version upgrade was merged to
{{develop}} before the PR and, thus, the compilation fails.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6042) Change VMProvider import (commons.lang -> commons.lang3)
[
https://issues.apache.org/jira/browse/GEODE-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-6042:
---
Assignee: Juan José Ramos Cassella
> Change VMProvider import (commons.lang -> commons.lang3)
>
>
> Key: GEODE-6042
> URL: https://issues.apache.org/jira/browse/GEODE-6042
> Project: Geode
> Issue Type: Bug
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> The latest
> [commit|https://github.com/apache/geode/commit/7b252a628379d21fcafb34ce96357c434357a108]
> to {{develop}} doesn't compile because {{commons-lang}} was upgraded to
> {{commons-lang3}}, the import used by {{VMProvider}} is wrong.
> [CI builds|https://github.com/apache/geode/pull/2812] were completely green
> when the PR was opened, but the {{commons-lang}} version upgrade was merged
> to {{develop}} before the PR and, thus, the compilation fails.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6042) Change VMProvider import (commons.lang -> commons.lang3)
[
https://issues.apache.org/jira/browse/GEODE-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-6042.
-
Resolution: Fixed
Fix Version/s: 1.9.0
> Change VMProvider import (commons.lang -> commons.lang3)
>
>
> Key: GEODE-6042
> URL: https://issues.apache.org/jira/browse/GEODE-6042
> Project: Geode
> Issue Type: Bug
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The latest
> [commit|https://github.com/apache/geode/commit/7b252a628379d21fcafb34ce96357c434357a108]
> to {{develop}} doesn't compile because {{commons-lang}} was upgraded to
> {{commons-lang3}}, the import used by {{VMProvider}} is wrong.
> [CI builds|https://github.com/apache/geode/pull/2812] were completely green
> when the PR was opened, but the {{commons-lang}} version upgrade was merged
> to {{develop}} before the PR and, thus, the compilation fails.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-3835) DistributedSystemBridgeJUnitTest should use TemporaryFolder
[ https://issues.apache.org/jira/browse/GEODE-3835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan José Ramos Cassella resolved GEODE-3835. - Resolution: Fixed Fix Version/s: 1.9.0 > DistributedSystemBridgeJUnitTest should use TemporaryFolder > --- > > Key: GEODE-3835 > URL: https://issues.apache.org/jira/browse/GEODE-3835 > Project: Geode > Issue Type: Improvement > Components: jmx, management, tests >Reporter: Kirk Lund >Assignee: Juan José Ramos Cassella >Priority: Major > Labels: Ci, pull-request-available, starter > Fix For: 1.9.0 > > Time Spent: 50m > Remaining Estimate: 0h > > DistributedSystemBridgeJUnitTest should use TemporaryFolder instead of "/tmp". > [separated DistributedSystemBridgeJUnitTest from GEODE-1338] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5342) gfsh command to validate offline disk stores creates the given disk store directory if it doesn't exist
[
https://issues.apache.org/jira/browse/GEODE-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-5342:
---
Assignee: Juan José Ramos Cassella
> gfsh command to validate offline disk stores creates the given disk store
> directory if it doesn't exist
> ---
>
> Key: GEODE-5342
> URL: https://issues.apache.org/jira/browse/GEODE-5342
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Lynn Gallinat
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> {noformat}
> gfsh> validate offline-disk-store --name=diskStore2
> --disk-dirs=/Users/lynn/doesNotExist
> Validating diskStore2
> Error in validating disk store diskStore2 is : The init file
> "/Users/lynn/doesNotExist/BACKUPdiskStore2.if" does not exist.
> The directory "/Users/lynn/doesNotExist" is now created.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5342) gfsh commands related to offline disk store operations create the given disk store directory if it doesn't exist
[
https://issues.apache.org/jira/browse/GEODE-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-5342:
Description:
{noformat}
gfsh> validate offline-disk-store --name=diskStore2
--disk-dirs=/Users/lynn/doesNotExist
Validating diskStore2
Error in validating disk store diskStore2 is : The init file
"/Users/lynn/doesNotExist/BACKUPdiskStore2.if" does not exist.
The directory "/Users/lynn/doesNotExist" is now created.
{noformat}
List of commands that create the disk-store when it doesn't exist:
* alter disk-store
* validate offline-disk-store
* upgrade offline-disk-store
* compact offline-disk-store
* describe offline-disk-store
was:
{noformat}
gfsh> validate offline-disk-store --name=diskStore2
--disk-dirs=/Users/lynn/doesNotExist
Validating diskStore2
Error in validating disk store diskStore2 is : The init file
"/Users/lynn/doesNotExist/BACKUPdiskStore2.if" does not exist.
The directory "/Users/lynn/doesNotExist" is now created.
{noformat}
> gfsh commands related to offline disk store operations create the given disk
> store directory if it doesn't exist
>
>
> Key: GEODE-5342
> URL: https://issues.apache.org/jira/browse/GEODE-5342
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Lynn Gallinat
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> {noformat}
> gfsh> validate offline-disk-store --name=diskStore2
> --disk-dirs=/Users/lynn/doesNotExist
> Validating diskStore2
> Error in validating disk store diskStore2 is : The init file
> "/Users/lynn/doesNotExist/BACKUPdiskStore2.if" does not exist.
> The directory "/Users/lynn/doesNotExist" is now created.
> {noformat}
> List of commands that create the disk-store when it doesn't exist:
> * alter disk-store
> * validate offline-disk-store
> * upgrade offline-disk-store
> * compact offline-disk-store
> * describe offline-disk-store
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5342) gfsh commands related to offline disk store operations create the given disk store directory if it doesn't exist
[
https://issues.apache.org/jira/browse/GEODE-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-5342:
Summary: gfsh commands related to offline disk store operations create the
given disk store directory if it doesn't exist (was: gfsh command to validate
offline disk stores creates the given disk store directory if it doesn't exist)
> gfsh commands related to offline disk store operations create the given disk
> store directory if it doesn't exist
>
>
> Key: GEODE-5342
> URL: https://issues.apache.org/jira/browse/GEODE-5342
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Lynn Gallinat
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> {noformat}
> gfsh> validate offline-disk-store --name=diskStore2
> --disk-dirs=/Users/lynn/doesNotExist
> Validating diskStore2
> Error in validating disk store diskStore2 is : The init file
> "/Users/lynn/doesNotExist/BACKUPdiskStore2.if" does not exist.
> The directory "/Users/lynn/doesNotExist" is now created.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5667) gfsh create gateway-receiver option "--manual-start" has counterintuitive default
[ https://issues.apache.org/jira/browse/GEODE-5667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan José Ramos Cassella reassigned GEODE-5667: --- Assignee: Dave Barnes (was: Juan José Ramos Cassella) > gfsh create gateway-receiver option "--manual-start" has counterintuitive > default > - > > Key: GEODE-5667 > URL: https://issues.apache.org/jira/browse/GEODE-5667 > Project: Geode > Issue Type: Improvement > Components: docs, gfsh >Affects Versions: 1.6.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > The "--manual-start" option for the `gfsh create gateway-receiver` command, > when specified without a value (=true or =false), should set > manual-start=true. > Current behavior is that if specified without a value, the parameter is set > to null, which invokes the system's default behavior, which happens to be > `false`. > This is counterintuitive to the user, who (I'm certain) would expect > `--manual-start` to result in the parameter being set to `true`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5667) gfsh create gateway-receiver option "--manual-start" has counterintuitive default
[ https://issues.apache.org/jira/browse/GEODE-5667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700568#comment-16700568 ] Juan José Ramos Cassella commented on GEODE-5667: - Reassigned to [~dbarnes97] to get the user guide updated. > gfsh create gateway-receiver option "--manual-start" has counterintuitive > default > - > > Key: GEODE-5667 > URL: https://issues.apache.org/jira/browse/GEODE-5667 > Project: Geode > Issue Type: Improvement > Components: docs, gfsh >Affects Versions: 1.6.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > The "--manual-start" option for the `gfsh create gateway-receiver` command, > when specified without a value (=true or =false), should set > manual-start=true. > Current behavior is that if specified without a value, the parameter is set > to null, which invokes the system's default behavior, which happens to be > `false`. > This is counterintuitive to the user, who (I'm certain) would expect > `--manual-start` to result in the parameter being set to `true`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5342) gfsh commands related to offline disk store operations create the given disk store directory if it doesn't exist
[
https://issues.apache.org/jira/browse/GEODE-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-5342.
-
Resolution: Fixed
Fix Version/s: 1.9.0
> gfsh commands related to offline disk store operations create the given disk
> store directory if it doesn't exist
>
>
> Key: GEODE-5342
> URL: https://issues.apache.org/jira/browse/GEODE-5342
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Lynn Gallinat
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> gfsh> validate offline-disk-store --name=diskStore2
> --disk-dirs=/Users/lynn/doesNotExist
> Validating diskStore2
> Error in validating disk store diskStore2 is : The init file
> "/Users/lynn/doesNotExist/BACKUPdiskStore2.if" does not exist.
> The directory "/Users/lynn/doesNotExist" is now created.
> {noformat}
> List of commands that create the disk-store when it doesn't exist:
> * alter disk-store
> * validate offline-disk-store
> * upgrade offline-disk-store
> * compact offline-disk-store
> * describe offline-disk-store
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4794) ConfigurePDXCommand Fails When Using Defaults
[
https://issues.apache.org/jira/browse/GEODE-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16723856#comment-16723856
]
Juan José Ramos Cassella commented on GEODE-4794:
-
[~amurmann]: this was fixed several months ago, not sure why it's still open...
{code:java}
jramos@MacBook-Pro-5:~/git/geode (develop): git tag --contains
ee0690097577ac9dbe241b0bb94ca6e8e4ed89fb
rel/v1.7.0
rel/v1.7.0.RC1
rel/v1.7.0.RC2
rel/v1.8.0
rel/v1.8.0.RC1
rel/v1.8.0.RC2
{code}
> ConfigurePDXCommand Fails When Using Defaults
> -
>
> Key: GEODE-4794
> URL: https://issues.apache.org/jira/browse/GEODE-4794
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Joey McAllister
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> While working on a fix for GEODE-4771 I've came across another bug: the
> {{configure pdx}} command fails when no parameters are specified, even when
> we state in the [User
> Guide|http://geode.apache.org/docs/guide/14/tools_modules/gfsh/command-pages/configure.html]
> that no parameters are mandatory.
> The source code doesn't generate a valid XML fragment when none of the
> parameters are set and, as such, the resulting {{XmlEntity}} ends up being
> empty, so a {{NullPointerException}} is thrown when the command tries to
> persist the changes to the cluster configuration service:
> {code:java}
> [error 2018/03/07 11:07:48.242 GMT locator1
> tid=0x55] error updating cluster configuration for group cluster
> java.lang.NullPointerException
> at java.io.StringReader.(StringReader.java:50)
> at
> org.apache.geode.management.internal.configuration.utils.XmlUtils.createNode(XmlUtils.java:242)
> at
> org.apache.geode.management.internal.configuration.utils.XmlUtils.addNewNode(XmlUtils.java:133)
> at
> org.apache.geode.distributed.internal.ClusterConfigurationService.addXmlEntity(ClusterConfigurationService.java:204)
> at
> org.apache.geode.management.internal.cli.commands.ConfigurePDXCommand.lambda$configurePDX$0(ConfigurePDXCommand.java:131)
> at
> org.apache.geode.management.internal.cli.commands.GfshCommand.persistClusterConfiguration(GfshCommand.java:72)
> at
> org.apache.geode.management.internal.cli.commands.ConfigurePDXCommand.configurePDX(ConfigurePDXCommand.java:130)
> 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:498)
> at
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:97)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:45)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:39)
> at
> org.apache.geode.management.internal.cli.remote.OnlineCommandProcessor.executeCommand(OnlineCommandProcessor.java:133)
> at
> org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1579)
> at
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:412)
> 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:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193)
> at
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
> at
> com.sun.jmx.mbe
[jira] [Assigned] (GEODE-6293) Gfsh execute function command expects the function to have a result
[
https://issues.apache.org/jira/browse/GEODE-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-6293:
---
Assignee: Juan José Ramos Cassella
> Gfsh execute function command expects the function to have a result
> ---
>
> Key: GEODE-6293
> URL: https://issues.apache.org/jira/browse/GEODE-6293
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Barry Oglesby
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> Functions with hasResult returning false cause gfsh to log this exception
> message:
> {noformat}
> gfsh>execute function --id=TestNoResultFunction --region=/data
> Member | Status | Message
> | -- |
>
> server-1 | ERROR | Exception: Cannot return any result as the
> Function#hasResult() is false
> {noformat}
> That message is coming from `UserFunctionExecution.execute` which does:
> {noformat}
> List results = (List)
> execution.execute(function.getId()).getResult();
> {noformat}
> Here is the stack where that happens:
> {noformat}
> java.lang.Exception: Stack trace
> at java.lang.Thread.dumpStack(Thread.java:1333)
> at
> org.apache.geode.internal.cache.execute.NoResult.getResult(NoResult.java:56)
> at
> org.apache.geode.management.internal.cli.functions.UserFunctionExecution.execute(UserFunctionExecution.java:156)
> at
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:193)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:367)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:433)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:956)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.doFunctionExecutionThread(ClusterDistributionManager.java:810)
> at
> org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Here is a potential fix that addresses the issue:
> {noformat}
> List results = null;
> ResultCollector rc = execution.execute(function.getId());
> if (function.hasResult()) {
> results = (List) rc.getResult();
> }
> {noformat}
> This fix causes gfsh to report an OK result:
> {noformat}
> gfsh>execute function --id=TestNoResultFunction --region=/data
> Member | Status | Message
> | -- | ---
> server-1 | OK | []
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6293) Gfsh execute function command expects the function to have a result
[
https://issues.apache.org/jira/browse/GEODE-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-6293.
-
Resolution: Fixed
Fix Version/s: 1.9.0
Fixed through
[9fa4dc2|https://github.com/apache/geode/commit/9fa4dc25c3f1dd9e470729eb707b3fe81fd7fc7e].
> Gfsh execute function command expects the function to have a result
> ---
>
> Key: GEODE-6293
> URL: https://issues.apache.org/jira/browse/GEODE-6293
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Barry Oglesby
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Functions with hasResult returning false cause gfsh to log this exception
> message:
> {noformat}
> gfsh>execute function --id=TestNoResultFunction --region=/data
> Member | Status | Message
> | -- |
>
> server-1 | ERROR | Exception: Cannot return any result as the
> Function#hasResult() is false
> {noformat}
> That message is coming from `UserFunctionExecution.execute` which does:
> {noformat}
> List results = (List)
> execution.execute(function.getId()).getResult();
> {noformat}
> Here is the stack where that happens:
> {noformat}
> java.lang.Exception: Stack trace
> at java.lang.Thread.dumpStack(Thread.java:1333)
> at
> org.apache.geode.internal.cache.execute.NoResult.getResult(NoResult.java:56)
> at
> org.apache.geode.management.internal.cli.functions.UserFunctionExecution.execute(UserFunctionExecution.java:156)
> at
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:193)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:367)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:433)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:956)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.doFunctionExecutionThread(ClusterDistributionManager.java:810)
> at
> org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Here is a potential fix that addresses the issue:
> {noformat}
> List results = null;
> ResultCollector rc = execution.execute(function.getId());
> if (function.hasResult()) {
> results = (List) rc.getResult();
> }
> {noformat}
> This fix causes gfsh to report an OK result:
> {noformat}
> gfsh>execute function --id=TestNoResultFunction --region=/data
> Member | Status | Message
> | -- | ---
> server-1 | OK | []
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6490) IntelliJ Compilation Failure due to Two Copies of ExtendsFunctionAdapter.java
Juan José Ramos Cassella created GEODE-6490:
---
Summary: IntelliJ Compilation Failure due to Two Copies of
ExtendsFunctionAdapter.java
Key: GEODE-6490
URL: https://issues.apache.org/jira/browse/GEODE-6490
Project: Geode
Issue Type: Bug
Components: build
Reporter: Juan José Ramos Cassella
IntelliJ started to fail some time ago because there are two copies of the
{{ExtendsFunctionAdapter.java}} file. The details about the cause of the error
and resolution can be found within the geode-dev list, specifically [this
thread|https://lists.apache.org/thread.html/9a2b7dcefcbcac2dad93565496fe6fde009d57f3e39766751885e62b@%3Cdev.geode.apache.org%3E].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6490) IntelliJ Compilation Failure due to Two Copies of ExtendsFunctionAdapter.java
[
https://issues.apache.org/jira/browse/GEODE-6490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-6490:
---
Assignee: Juan José Ramos Cassella
> IntelliJ Compilation Failure due to Two Copies of ExtendsFunctionAdapter.java
> -
>
> Key: GEODE-6490
> URL: https://issues.apache.org/jira/browse/GEODE-6490
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> IntelliJ started to fail some time ago because there are two copies of the
> {{ExtendsFunctionAdapter.java}} file. The details about the cause of the
> error and resolution can be found within the geode-dev list, specifically
> [this
> thread|https://lists.apache.org/thread.html/9a2b7dcefcbcac2dad93565496fe6fde009d57f3e39766751885e62b@%3Cdev.geode.apache.org%3E].
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-6490) IntelliJ Compilation Failure due to Two Copies of ExtendsFunctionAdapter.java
[
https://issues.apache.org/jira/browse/GEODE-6490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella closed GEODE-6490.
---
> IntelliJ Compilation Failure due to Two Copies of ExtendsFunctionAdapter.java
> -
>
> Key: GEODE-6490
> URL: https://issues.apache.org/jira/browse/GEODE-6490
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> IntelliJ started to fail some time ago because there are two copies of the
> {{ExtendsFunctionAdapter.java}} file. The details about the cause of the
> error and resolution can be found within the geode-dev list, specifically
> [this
> thread|https://lists.apache.org/thread.html/9a2b7dcefcbcac2dad93565496fe6fde009d57f3e39766751885e62b@%3Cdev.geode.apache.org%3E].
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6490) IntelliJ Compilation Failure due to Two Copies of ExtendsFunctionAdapter.java
[
https://issues.apache.org/jira/browse/GEODE-6490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-6490.
-
Resolution: Not A Problem
The steps described in the wiki are outdated, we must use the BUILDING.md
instead.
> IntelliJ Compilation Failure due to Two Copies of ExtendsFunctionAdapter.java
> -
>
> Key: GEODE-6490
> URL: https://issues.apache.org/jira/browse/GEODE-6490
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> IntelliJ started to fail some time ago because there are two copies of the
> {{ExtendsFunctionAdapter.java}} file. The details about the cause of the
> error and resolution can be found within the geode-dev list, specifically
> [this
> thread|https://lists.apache.org/thread.html/9a2b7dcefcbcac2dad93565496fe6fde009d57f3e39766751885e62b@%3Cdev.geode.apache.org%3E].
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6490) IntelliJ Compilation Failure due to Two Copies of ExtendsFunctionAdapter.java
[
https://issues.apache.org/jira/browse/GEODE-6490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16785668#comment-16785668
]
Juan José Ramos Cassella commented on GEODE-6490:
-
[~jbarrett]: you're right... I've always followed [Getting Started for Geode
Developers|https://cwiki.apache.org/confluence/display/GEODE/Getting+Started+for+Geode+Developers],
which states totally the opposite, that's why I'm hitting the error :-S.
{quote}
IntelliJ
In order to build the project successfully in IntelliJ and run tests, it is
recommended to disable → Preferences → Build, Execution, Deployment → Build
Tools → Gradle → "Create separate module per source set".
{quote}
Will quickly update the WIKI and add a reference to
[Bulding.md|https://github.com/apache/geode/blob/develop/BUILDING.md] instead.
Cheers.
> IntelliJ Compilation Failure due to Two Copies of ExtendsFunctionAdapter.java
> -
>
> Key: GEODE-6490
> URL: https://issues.apache.org/jira/browse/GEODE-6490
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> IntelliJ started to fail some time ago because there are two copies of the
> {{ExtendsFunctionAdapter.java}} file. The details about the cause of the
> error and resolution can be found within the geode-dev list, specifically
> [this
> thread|https://lists.apache.org/thread.html/9a2b7dcefcbcac2dad93565496fe6fde009d57f3e39766751885e62b@%3Cdev.geode.apache.org%3E].
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6519) Purge CreateGatewaySenderCommand Boolean Parameters
[
https://issues.apache.org/jira/browse/GEODE-6519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-6519:
---
Assignee: Juan José Ramos Cassella
> Purge CreateGatewaySenderCommand Boolean Parameters
> ---
>
> Key: GEODE-6519
> URL: https://issues.apache.org/jira/browse/GEODE-6519
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> Several of the {{CreateGatewaySenderCommand}} {{boolean}} parameters are left
> as {{null}} / {{false}} even when they are set through the command line
> without a value, this is extremely counter intuitive.
> As an example, as a user I would expect the command {{gfsh create
> gateway-sender --enable-persistence}} to create a persistent
> {{gateway-sender}} but, instead, it creates a non-persistent one.
> This ticket is to sanitate the following parameters, configuring them as
> {{true}} by default whenever they are specified in the command line without
> any value:
> * parallel
> * disk-synchronous
> * enable-persistence
> * enable-batch-conflation
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6519) Purge CreateGatewaySenderCommand Boolean Parameters
Juan José Ramos Cassella created GEODE-6519:
---
Summary: Purge CreateGatewaySenderCommand Boolean Parameters
Key: GEODE-6519
URL: https://issues.apache.org/jira/browse/GEODE-6519
Project: Geode
Issue Type: Bug
Components: gfsh
Reporter: Juan José Ramos Cassella
Several of the {{CreateGatewaySenderCommand}} {{boolean}} parameters are left
as {{null}} / {{false}} even when they are set through the command line without
a value, this is extremely counter intuitive.
As an example, as a user I would expect the command {{gfsh create
gateway-sender --enable-persistence}} to create a persistent {{gateway-sender}}
but, instead, it creates a non-persistent one.
This ticket is to sanitate the following parameters, configuring them as
{{true}} by default whenever they are specified in the command line without any
value:
* parallel
* disk-synchronous
* enable-persistence
* enable-batch-conflation
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6519) Purge CreateGatewaySenderCommand Boolean Parameters
[
https://issues.apache.org/jira/browse/GEODE-6519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-6519.
-
Resolution: Fixed
Fix Version/s: 1.10.0
> Purge CreateGatewaySenderCommand Boolean Parameters
> ---
>
> Key: GEODE-6519
> URL: https://issues.apache.org/jira/browse/GEODE-6519
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Several of the {{CreateGatewaySenderCommand}} {{boolean}} parameters are left
> as {{null}} / {{false}} even when they are set through the command line
> without a value, this is extremely counter intuitive.
> As an example, as a user I would expect the command {{gfsh create
> gateway-sender --enable-persistence}} to create a persistent
> {{gateway-sender}} but, instead, it creates a non-persistent one.
> This ticket is to sanitate the following parameters, configuring them as
> {{true}} by default whenever they are specified in the command line without
> any value:
> * parallel
> * disk-synchronous
> * enable-persistence
> * enable-batch-conflation
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6550) AlterRegionCommand Fails to set CacheWriter
[
https://issues.apache.org/jira/browse/GEODE-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-6550:
---
Assignee: Juan José Ramos Cassella
> AlterRegionCommand Fails to set CacheWriter
> ---
>
> Key: GEODE-6550
> URL: https://issues.apache.org/jira/browse/GEODE-6550
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> The {{alter region}} command checks the nullity of the {{cache-writer}}
> parameter but, when altering the region, sets the {{cache-loader}} attribute
> instead.
> {code:title=AlterRegionCommand.java|borderStyle=solid}
> public ResultModel alterRegion(...) {
> ...
> if (cacheWriter != null) {
> regionAttributesType.setCacheWriter(
> new DeclarableType(cacheLoader.getClassName(),
> cacheLoader.getInitProperties()));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6550) AlterRegionCommand Fails to set CacheWriter
[
https://issues.apache.org/jira/browse/GEODE-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-6550:
Description:
The {{alter region}} command checks the nullity of the {{cache-writer}}
parameter but, when altering the region, sets the {{cache-loader}} attribute
instead.
{code:java|title=AlterRegionCommand.java|borderStyle=solid}
public ResultModel alterRegion(...) {
...
if (cacheWriter != null) {
regionAttributesType.setCacheWriter(
new DeclarableType(cacheLoader.getClassName(),
cacheLoader.getInitProperties()));
}
...
}
{code}
was:
The {{alter region}} command checks the nullity of the {{cache-writer}}
parameter but, when altering the region, sets the {{cache-loader}} attribute
instead.
{code:title=AlterRegionCommand.java|borderStyle=solid}
public ResultModel alterRegion(...) {
...
if (cacheWriter != null) {
regionAttributesType.setCacheWriter(
new DeclarableType(cacheLoader.getClassName(),
cacheLoader.getInitProperties()));
}
}
{code}
> AlterRegionCommand Fails to set CacheWriter
> ---
>
> Key: GEODE-6550
> URL: https://issues.apache.org/jira/browse/GEODE-6550
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> The {{alter region}} command checks the nullity of the {{cache-writer}}
> parameter but, when altering the region, sets the {{cache-loader}} attribute
> instead.
> {code:java|title=AlterRegionCommand.java|borderStyle=solid}
> public ResultModel alterRegion(...) {
> ...
> if (cacheWriter != null) {
> regionAttributesType.setCacheWriter(
> new DeclarableType(cacheLoader.getClassName(),
> cacheLoader.getInitProperties()));
> }
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6550) AlterRegionCommand Fails to set CacheWriter
Juan José Ramos Cassella created GEODE-6550:
---
Summary: AlterRegionCommand Fails to set CacheWriter
Key: GEODE-6550
URL: https://issues.apache.org/jira/browse/GEODE-6550
Project: Geode
Issue Type: Bug
Components: gfsh
Reporter: Juan José Ramos Cassella
The {{alter region}} command checks the nullity of the {{cache-writer}}
parameter but, when altering the region, sets the {{cache-loader}} attribute
instead.
{code:title=AlterRegionCommand.java|borderStyle=solid}
public ResultModel alterRegion(...) {
...
if (cacheWriter != null) {
regionAttributesType.setCacheWriter(
new DeclarableType(cacheLoader.getClassName(),
cacheLoader.getInitProperties()));
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6551) Multiple Executions of RegionAlterFunction Leaves Partition Region Inconsistent
[
https://issues.apache.org/jira/browse/GEODE-6551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-6551:
---
Assignee: Juan José Ramos Cassella
> Multiple Executions of RegionAlterFunction Leaves Partition Region
> Inconsistent
> ---
>
> Key: GEODE-6551
> URL: https://issues.apache.org/jira/browse/GEODE-6551
> Project: Geode
> Issue Type: Bug
> Components: configuration, gfsh, wan
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> When trying to assign a non-persistent parallel {{gateway-sender}} /
> {{async-event-queue}} to a persistent partitioned region through {{gfsh}},
> the actual region is left inconsistent in the {{cluster configuration
> service}} if the internal function is executed more than once.
> The problem is that the {{gateway-sender}} / {{async-event-queue}} is added
> to the internal list too early within the execution lifecycle and, if the
> actual addition fails afterwards, the internal list is never reverted to its
> original state. This invalid configuration is persisted into the cluster
> configuration service afterwards (for the second, "successful execution"), so
> the subsequent restart of the servers will miserably fail.
> The following set of steps reproduces the problem for a {{gateway-sender}},
> but the logic is exactly the same for an {{async-event-queue}}:
> {noformat}
> gfsh -e "start locator --name=locator --port=10101"
> gfsh -e "start server --name=server --server-port=40404
> --locators=localhost[10101]"
> gfsh -e "connect --locator=localhost[10101]" -e "create disk-store
> --name=diskStore --dir=diskStore"
> gfsh -e "connect --locator=localhost[10101]" -e "create region
> --name=testRegion --type=PARTITION_PERSISTENT --disk-store=diskStore"
> gfsh -e "connect --locator=localhost[10101]" -e "create gateway-sender
> --id=gateway --parallel=true --remote-distributed-system-id=2
> --enable-persistence=false"
> # First Execution Fails
> gfsh -e "connect --locator=localhost[10101]" -e "alter region
> --name=testRegion --gateway-sender-id=gateway"
> Member | Status | Message
> -- | -- |
> ---
> server | ERROR |
> org.apache.geode.internal.cache.wan.GatewaySenderException: Non persistent
> gateway sender gateway can not be attached to persistent region /testRegion
> # Second Execution Succeeds
> gfsh -e "connect --locator=localhost[10101]" -e "alter region
> --name=testRegion --gateway-sender-id=gateway"
> Member | Status | Message
> -- | -- | -
> server | OK | Region testRegion altered
> gfsh -e "connect --locator=localhost[10101]" -e "stop server --name=server"
> gfsh -e "start server --name=server --server-port=40404
> --locators=localhost[10101]"
> The Cache Server process terminated unexpectedly with exit status 1.
> Please refer to the log file in /server for full details.
> Exception in thread "main"
> org.apache.geode.internal.cache.wan.GatewaySenderException: Non persistent
> gateway sender gateway can not be attached to persistent region /testRegion
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:454)
> # The log shows that the cluster configuration receiged is invalid:
> [info 2019/03/21 11:52:57.606 GMT tid=0x1] Received cluster
> configuration from the locator
> [info 2019/03/21 11:52:57.638 GMT tid=0x1]
> ***
> Configuration for 'cluster'
> Jar files to deployed
>
> http://geode.apache.org/schema/cache";
> xmlns:jdbc="http://geode.apache.org/schema/jdbc";
> xmlns:lucene="http://geode.apache.org/schema/lucene";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; version="1.0"
> xsi:schemaLocation="http://geode.apache.org/schema/lucene
> http://geode.apache.org/schema/lucene/lucene-1.0.xsd
> http://geode.apache.org/schema/jdbc
> http://geode.apache.org/schema/jdbc/jdbc-1.0.xsd
> http://geode.apache.org/schema/cache
> http://geode.apache.org/schema/cache/cache-1.0.
[jira] [Created] (GEODE-6551) Multiple Executions of RegionAlterFunction Leaves Partition Region Inconsistent
Juan José Ramos Cassella created GEODE-6551:
---
Summary: Multiple Executions of RegionAlterFunction Leaves
Partition Region Inconsistent
Key: GEODE-6551
URL: https://issues.apache.org/jira/browse/GEODE-6551
Project: Geode
Issue Type: Bug
Components: configuration, gfsh, wan
Reporter: Juan José Ramos Cassella
When trying to assign a non-persistent parallel {{gateway-sender}} /
{{async-event-queue}} to a persistent partitioned region through {{gfsh}}, the
actual region is left inconsistent in the {{cluster configuration service}} if
the internal function is executed more than once.
The problem is that the {{gateway-sender}} / {{async-event-queue}} is added to
the internal list too early within the execution lifecycle and, if the actual
addition fails afterwards, the internal list is never reverted to its original
state. This invalid configuration is persisted into the cluster configuration
service afterwards (for the second, "successful execution"), so the subsequent
restart of the servers will miserably fail.
The following set of steps reproduces the problem for a {{gateway-sender}}, but
the logic is exactly the same for an {{async-event-queue}}:
{noformat}
gfsh -e "start locator --name=locator --port=10101"
gfsh -e "start server --name=server --server-port=40404
--locators=localhost[10101]"
gfsh -e "connect --locator=localhost[10101]" -e "create disk-store
--name=diskStore --dir=diskStore"
gfsh -e "connect --locator=localhost[10101]" -e "create region
--name=testRegion --type=PARTITION_PERSISTENT --disk-store=diskStore"
gfsh -e "connect --locator=localhost[10101]" -e "create gateway-sender
--id=gateway --parallel=true --remote-distributed-system-id=2
--enable-persistence=false"
# First Execution Fails
gfsh -e "connect --locator=localhost[10101]" -e "alter region --name=testRegion
--gateway-sender-id=gateway"
Member | Status | Message
-- | -- |
---
server | ERROR | org.apache.geode.internal.cache.wan.GatewaySenderException:
Non persistent gateway sender gateway can not be attached to persistent region
/testRegion
# Second Execution Succeeds
gfsh -e "connect --locator=localhost[10101]" -e "alter region --name=testRegion
--gateway-sender-id=gateway"
Member | Status | Message
-- | -- | -
server | OK | Region testRegion altered
gfsh -e "connect --locator=localhost[10101]" -e "stop server --name=server"
gfsh -e "start server --name=server --server-port=40404
--locators=localhost[10101]"
The Cache Server process terminated unexpectedly with exit status 1. Please
refer to the log file in /server for full details.
Exception in thread "main"
org.apache.geode.internal.cache.wan.GatewaySenderException: Non persistent
gateway sender gateway can not be attached to persistent region /testRegion
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:454)
# The log shows that the cluster configuration receiged is invalid:
[info 2019/03/21 11:52:57.606 GMT tid=0x1] Received cluster
configuration from the locator
[info 2019/03/21 11:52:57.638 GMT tid=0x1]
***
Configuration for 'cluster'
Jar files to deployed
http://geode.apache.org/schema/cache";
xmlns:jdbc="http://geode.apache.org/schema/jdbc";
xmlns:lucene="http://geode.apache.org/schema/lucene";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; version="1.0"
xsi:schemaLocation="http://geode.apache.org/schema/lucene
http://geode.apache.org/schema/lucene/lucene-1.0.xsd
http://geode.apache.org/schema/jdbc
http://geode.apache.org/schema/jdbc/jdbc-1.0.xsd
http://geode.apache.org/schema/cache
http://geode.apache.org/schema/cache/cache-1.0.xsd";>
diskStore
{noformat}
The current validations executed within the {{RegionAlterFunction}} are not
enough and and should also include the persistent checks (currently done in
{{ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR}}) or, at
least, leave the internal list of {{gateway-sender}}/{{async-event-queue}} as
they were before.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6551) Multiple Executions of RegionAlterFunction Leaves Partition Region Inconsistent
[
https://issues.apache.org/jira/browse/GEODE-6551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-6551:
Description:
When trying to assign a non-persistent parallel {{gateway-sender}} /
{{async-event-queue}} to a persistent partitioned region through {{gfsh}}, the
actual region is left inconsistent in the {{cluster configuration service}} if
the internal function is executed more than once.
The problem is that the {{gateway-sender}} / {{async-event-queue}} is added to
the internal list too early within the execution lifecycle and, if the actual
addition fails afterwards, the internal list is never reverted to its original
state. This invalid configuration is persisted into the cluster configuration
service afterwards (for the second, "successful execution"), so the subsequent
restart of the servers will miserably fail.
The following set of steps reproduces the problem for a {{gateway-sender}},
but the logic is exactly the same for an {{async-event-queue}}:
{noformat}
gfsh -e "start locator --name=locator --port=10101"
gfsh -e "start server --name=server --server-port=40404
--locators=localhost[10101]"
gfsh -e "connect --locator=localhost[10101]" -e "create disk-store
--name=diskStore --dir=diskStore"
gfsh -e "connect --locator=localhost[10101]" -e "create region
--name=testRegion --type=PARTITION_PERSISTENT --disk-store=diskStore"
gfsh -e "connect --locator=localhost[10101]" -e "create gateway-sender
--id=gateway --parallel=true --remote-distributed-system-id=2
--enable-persistence=false"
# First Execution Fails
gfsh -e "connect --locator=localhost[10101]" -e "alter region --name=testRegion
--gateway-sender-id=gateway"
Member | Status | Message
-- | -- |
---
server | ERROR | org.apache.geode.internal.cache.wan.GatewaySenderException:
Non persistent gateway sender gateway can not be attached to persistent region
/testRegion
# Second Execution Succeeds
gfsh -e "connect --locator=localhost[10101]" -e "alter region --name=testRegion
--gateway-sender-id=gateway"
Member | Status | Message
-- | -- | -
server | OK | Region testRegion altered
gfsh -e "connect --locator=localhost[10101]" -e "stop server --name=server"
gfsh -e "start server --name=server --server-port=40404
--locators=localhost[10101]"
The Cache Server process terminated unexpectedly with exit status 1. Please
refer to the log file in /server for full details.
Exception in thread "main"
org.apache.geode.internal.cache.wan.GatewaySenderException: Non persistent
gateway sender gateway can not be attached to persistent region /testRegion
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:454)
# The log shows that the cluster configuration receiged is invalid:
[info 2019/03/21 11:52:57.606 GMT tid=0x1] Received cluster
configuration from the locator
[info 2019/03/21 11:52:57.638 GMT tid=0x1]
***
Configuration for 'cluster'
Jar files to deployed
http://geode.apache.org/schema/cache";
xmlns:jdbc="http://geode.apache.org/schema/jdbc";
xmlns:lucene="http://geode.apache.org/schema/lucene";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; version="1.0"
xsi:schemaLocation="http://geode.apache.org/schema/lucene
http://geode.apache.org/schema/lucene/lucene-1.0.xsd
http://geode.apache.org/schema/jdbc
http://geode.apache.org/schema/jdbc/jdbc-1.0.xsd
http://geode.apache.org/schema/cache
http://geode.apache.org/schema/cache/cache-1.0.xsd";>
diskStore
{noformat}
Improve the current validations invoked from within the {{RegionAlterFunction}}
and added through GEODE-4919 to also include the persistent checks (currently
done in {{ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR}}).
was:
When trying to assign a non-persistent parallel {{gateway-sender}} /
{{async-event-queue}} to a persistent partitioned region through {{gfsh}}, the
actual region is left inconsistent in the {{cluster configuration service}} if
the internal function is executed more than once.
The problem is that the {{gateway-sender}} / {{async-event-queue}} is added to
the internal list too early within the execution lifecycle and, if the actual
addition fails afterwards, the internal list is never reverted to its original
state. This invalid configuration is
[jira] [Resolved] (GEODE-6550) AlterRegionCommand Fails to set CacheWriter
[
https://issues.apache.org/jira/browse/GEODE-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-6550.
-
Resolution: Fixed
Fix Version/s: 1.10.0
> AlterRegionCommand Fails to set CacheWriter
> ---
>
> Key: GEODE-6550
> URL: https://issues.apache.org/jira/browse/GEODE-6550
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{alter region}} command checks the nullity of the {{cache-writer}}
> parameter but, when altering the region, sets the {{cache-loader}} attribute
> instead.
> {code:java|title=AlterRegionCommand.java|borderStyle=solid}
> public ResultModel alterRegion(...) {
> ...
> if (cacheWriter != null) {
> regionAttributesType.setCacheWriter(
> new DeclarableType(cacheLoader.getClassName(),
> cacheLoader.getInitProperties()));
> }
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6544) Can't log back in Pulse after an unauthorized login attempt
[ https://issues.apache.org/jira/browse/GEODE-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan José Ramos Cassella reassigned GEODE-6544: --- Assignee: Juan José Ramos Cassella > Can't log back in Pulse after an unauthorized login attempt > --- > > Key: GEODE-6544 > URL: https://issues.apache.org/jira/browse/GEODE-6544 > Project: Geode > Issue Type: Bug > Components: pulse >Reporter: Jinmei Liao >Assignee: Juan José Ramos Cassella >Priority: Major > > Steps to reproduce: > 1) start a locator with security manager > 2) try login using a username/password that can be authenticated, but not > authorized to view the clusterDatail.html (no data.read privilege) > 3) user gets a 403, which is correct, but then user can not get back to the > login page to enter correct credentials. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6544) Can't log back in Pulse after an unauthorized login attempt
[ https://issues.apache.org/jira/browse/GEODE-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan José Ramos Cassella resolved GEODE-6544. - Resolution: Fixed Fix Version/s: 1.10.0 > Can't log back in Pulse after an unauthorized login attempt > --- > > Key: GEODE-6544 > URL: https://issues.apache.org/jira/browse/GEODE-6544 > Project: Geode > Issue Type: Bug > Components: pulse >Reporter: Jinmei Liao >Assignee: Juan José Ramos Cassella >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Steps to reproduce: > 1) start a locator with security manager > 2) try login using a username/password that can be authenticated, but not > authorized to view the clusterDatail.html (no data.read privilege) > 3) user gets a 403, which is correct, but then user can not get back to the > login page to enter correct credentials. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
