[jira] [Assigned] (GEODE-10375) REST management discovery endpoint reports incorrect version
[ https://issues.apache.org/jira/browse/GEODE-10375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-10375: -- Assignee: Patrick Johnsn > REST management discovery endpoint reports incorrect version > > > Key: GEODE-10375 > URL: https://issues.apache.org/jira/browse/GEODE-10375 > Project: Geode > Issue Type: Bug > Components: rest (admin) >Affects Versions: 1.15.0 >Reporter: Owen Nichols >Assignee: Patrick Johnsn >Priority: Major > Labels: blocks-1.15.0, needsTriage > > prior to GEODE-10312, metadata about the management API url (obtained from > /management) correctly reported /v1/api-docs) > now that we have switched from swagger to springdoc it should now report > /v3/api-docs > see hardcoded value > [here|https://github.com/apache/geode/blob/develop/geode-web-management/src/main/java/org/apache/geode/management/internal/rest/controllers/DocLinksController.java#L38] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-10312) Remove SpringBootApplication In SwaggerConfig
[
https://issues.apache.org/jira/browse/GEODE-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn closed GEODE-10312.
--
> Remove SpringBootApplication In SwaggerConfig
> -
>
> Key: GEODE-10312
> URL: https://issues.apache.org/jira/browse/GEODE-10312
> Project: Geode
> Issue Type: Bug
> Components: locator, rest (admin), rest (dev)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
> Attachments: GEODE-10312.zip
>
>
> The issue was introduced by GEODE-10282. As part of commit
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4],
> {{SwaggerConfig}} classes used to start and configure the internal
> {{geode-web-management}} and {{geode-web-api}} services use the
> {{@SpringBootApplication}} annotation. This annotation automatically enables
> other spring annotations (like {{@EnableAutoConfiguration}} and
> {{@ComponentScan}}) which, in turn, might cause critical issues during
> startup as {{spring}} tries to automatically configure several services based
> on classes and interfaces found within the member's class path.
> ---
> I'm attaching a small scenario that reproduces the problem; the
> {{reproduce.sh}} script simply starts a locator making sure that the
> {{spring-jdbc-5.3.20.jar}} is part of the class path. When using any commit
> after
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4]
> the logs will contain the following:
> {noformat}
> [info 2022/05/16 15:54:38.997 IST locator0 tid=0x1] Adding webapp
> /management
> [info 2022/05/16 15:54:39.610 IST locator0 tid=0x1] Initializing
> Servlet 'management'
> [info 2022/05/16 15:54:42.124 IST locator0 tid=0x1] Will secure any
> request with
> [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@33ed6546,
>
> org.springframework.security.web.context.SecurityContextPersistenceFilter@5a503cf0,
> org.springframework.security.web.header.HeaderWriterFilter@5b04224a,
> org.springframework.security.web.authentication.logout.LogoutFilter@17db90a7,
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter@6f78c132,
>
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@42f9b425,
>
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter@54d62c35,
> org.springframework.security.web.session.SessionManagementFilter@78907a46,
> org.springframework.security.web.access.ExceptionTranslationFilter@eaf3dd0,
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor@7cd6b76a]
> [warn 2022/05/16 15:54:42.975 IST locator0 tid=0x1] Exception
> encountered during context initialization - cancelling refresh attempt:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> [error 2022/05/16 15:54:42.980 IST locator0 tid=0x1] Context
> initialization failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> at
> org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:800)
> at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:541)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1352)
> at
> o
[jira] [Comment Edited] (GEODE-10312) Remove SpringBootApplication In SwaggerConfig
[
https://issues.apache.org/jira/browse/GEODE-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542246#comment-17542246
]
Patrick Johnsn edited comment on GEODE-10312 at 5/25/22 10:10 PM:
--
The `
springdoc.api-docs.path` property should allow the api-docs URL to be changed,
but is being ignored. I just discovered that this works in previous versions of
springdoc, so downgrading from 1.6.8 to 1.6.1 fixes the issue and everything
works. I'm going to submit a bug against the project and see if we can get this
fixed.
was (Author: pjohnson):
The `
springdoc.api-docs.path` property should allow the api-docs URL to be changed,
but is being ignored. I just discovered that this works in previous versions of
springdoc, so downgrading from 1.6.x to 1.5.x fixes the issue and everything
works. I'm going to submit a bug against the project and see if we can get this
fixed.
> Remove SpringBootApplication In SwaggerConfig
> -
>
> Key: GEODE-10312
> URL: https://issues.apache.org/jira/browse/GEODE-10312
> Project: Geode
> Issue Type: Bug
> Components: locator, rest (admin), rest (dev)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Attachments: GEODE-10312.zip
>
>
> The issue was introduced by GEODE-10282. As part of commit
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4],
> {{SwaggerConfig}} classes used to start and configure the internal
> {{geode-web-management}} and {{geode-web-api}} services use the
> {{@SpringBootApplication}} annotation. This annotation automatically enables
> other spring annotations (like {{@EnableAutoConfiguration}} and
> {{@ComponentScan}}) which, in turn, might cause critical issues during
> startup as {{spring}} tries to automatically configure several services based
> on classes and interfaces found within the member's class path.
> ---
> I'm attaching a small scenario that reproduces the problem; the
> {{reproduce.sh}} script simply starts a locator making sure that the
> {{spring-jdbc-5.3.20.jar}} is part of the class path. When using any commit
> after
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4]
> the logs will contain the following:
> {noformat}
> [info 2022/05/16 15:54:38.997 IST locator0 tid=0x1] Adding webapp
> /management
> [info 2022/05/16 15:54:39.610 IST locator0 tid=0x1] Initializing
> Servlet 'management'
> [info 2022/05/16 15:54:42.124 IST locator0 tid=0x1] Will secure any
> request with
> [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@33ed6546,
>
> org.springframework.security.web.context.SecurityContextPersistenceFilter@5a503cf0,
> org.springframework.security.web.header.HeaderWriterFilter@5b04224a,
> org.springframework.security.web.authentication.logout.LogoutFilter@17db90a7,
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter@6f78c132,
>
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@42f9b425,
>
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter@54d62c35,
> org.springframework.security.web.session.SessionManagementFilter@78907a46,
> org.springframework.security.web.access.ExceptionTranslationFilter@eaf3dd0,
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor@7cd6b76a]
> [warn 2022/05/16 15:54:42.975 IST locator0 tid=0x1] Exception
> encountered during context initialization - cancelling refresh attempt:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> [error 2022/05/16 15:54:42.980 IST locator0 tid=0x1] Context
> initialization failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested excepti
[jira] [Commented] (GEODE-10312) Remove SpringBootApplication In SwaggerConfig
[
https://issues.apache.org/jira/browse/GEODE-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542246#comment-17542246
]
Patrick Johnsn commented on GEODE-10312:
The `
springdoc.api-docs.path` property should allow the api-docs URL to be changed,
but is being ignored. I just discovered that this works in previous versions of
springdoc, so downgrading from 1.6.x to 1.5.x fixes the issue and everything
works. I'm going to submit a bug against the project and see if we can get this
fixed.
> Remove SpringBootApplication In SwaggerConfig
> -
>
> Key: GEODE-10312
> URL: https://issues.apache.org/jira/browse/GEODE-10312
> Project: Geode
> Issue Type: Bug
> Components: locator, rest (admin), rest (dev)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Attachments: GEODE-10312.zip
>
>
> The issue was introduced by GEODE-10282. As part of commit
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4],
> {{SwaggerConfig}} classes used to start and configure the internal
> {{geode-web-management}} and {{geode-web-api}} services use the
> {{@SpringBootApplication}} annotation. This annotation automatically enables
> other spring annotations (like {{@EnableAutoConfiguration}} and
> {{@ComponentScan}}) which, in turn, might cause critical issues during
> startup as {{spring}} tries to automatically configure several services based
> on classes and interfaces found within the member's class path.
> ---
> I'm attaching a small scenario that reproduces the problem; the
> {{reproduce.sh}} script simply starts a locator making sure that the
> {{spring-jdbc-5.3.20.jar}} is part of the class path. When using any commit
> after
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4]
> the logs will contain the following:
> {noformat}
> [info 2022/05/16 15:54:38.997 IST locator0 tid=0x1] Adding webapp
> /management
> [info 2022/05/16 15:54:39.610 IST locator0 tid=0x1] Initializing
> Servlet 'management'
> [info 2022/05/16 15:54:42.124 IST locator0 tid=0x1] Will secure any
> request with
> [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@33ed6546,
>
> org.springframework.security.web.context.SecurityContextPersistenceFilter@5a503cf0,
> org.springframework.security.web.header.HeaderWriterFilter@5b04224a,
> org.springframework.security.web.authentication.logout.LogoutFilter@17db90a7,
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter@6f78c132,
>
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@42f9b425,
>
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter@54d62c35,
> org.springframework.security.web.session.SessionManagementFilter@78907a46,
> org.springframework.security.web.access.ExceptionTranslationFilter@eaf3dd0,
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor@7cd6b76a]
> [warn 2022/05/16 15:54:42.975 IST locator0 tid=0x1] Exception
> encountered during context initialization - cancelling refresh attempt:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> [error 2022/05/16 15:54:42.980 IST locator0 tid=0x1] Context
> initialization failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> at
> org.springframework.beans.factory.support.ConstructorResolver.createArgument
[jira] [Comment Edited] (GEODE-10312) Remove SpringBootApplication In SwaggerConfig
[
https://issues.apache.org/jira/browse/GEODE-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542109#comment-17542109
]
Patrick Johnsn edited comment on GEODE-10312 at 5/25/22 4:28 PM:
-
That is my concern, but I'm not sure. Most URLs are unchanged, including all
the endpoints I could find mentioned in the docs. Either way, I'm looking for a
way to avoid changing the URL.
was (Author: pjohnson):
That is my concern, but I'm not sure. Most URLs are unchanged, including all
the endpoints I could find mentioned in the docs.
> Remove SpringBootApplication In SwaggerConfig
> -
>
> Key: GEODE-10312
> URL: https://issues.apache.org/jira/browse/GEODE-10312
> Project: Geode
> Issue Type: Bug
> Components: locator, rest (admin), rest (dev)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Attachments: GEODE-10312.zip
>
>
> The issue was introduced by GEODE-10282. As part of commit
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4],
> {{SwaggerConfig}} classes used to start and configure the internal
> {{geode-web-management}} and {{geode-web-api}} services use the
> {{@SpringBootApplication}} annotation. This annotation automatically enables
> other spring annotations (like {{@EnableAutoConfiguration}} and
> {{@ComponentScan}}) which, in turn, might cause critical issues during
> startup as {{spring}} tries to automatically configure several services based
> on classes and interfaces found within the member's class path.
> ---
> I'm attaching a small scenario that reproduces the problem; the
> {{reproduce.sh}} script simply starts a locator making sure that the
> {{spring-jdbc-5.3.20.jar}} is part of the class path. When using any commit
> after
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4]
> the logs will contain the following:
> {noformat}
> [info 2022/05/16 15:54:38.997 IST locator0 tid=0x1] Adding webapp
> /management
> [info 2022/05/16 15:54:39.610 IST locator0 tid=0x1] Initializing
> Servlet 'management'
> [info 2022/05/16 15:54:42.124 IST locator0 tid=0x1] Will secure any
> request with
> [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@33ed6546,
>
> org.springframework.security.web.context.SecurityContextPersistenceFilter@5a503cf0,
> org.springframework.security.web.header.HeaderWriterFilter@5b04224a,
> org.springframework.security.web.authentication.logout.LogoutFilter@17db90a7,
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter@6f78c132,
>
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@42f9b425,
>
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter@54d62c35,
> org.springframework.security.web.session.SessionManagementFilter@78907a46,
> org.springframework.security.web.access.ExceptionTranslationFilter@eaf3dd0,
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor@7cd6b76a]
> [warn 2022/05/16 15:54:42.975 IST locator0 tid=0x1] Exception
> encountered during context initialization - cancelling refresh attempt:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> [error 2022/05/16 15:54:42.980 IST locator0 tid=0x1] Context
> initialization failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> at
> org.springframew
[jira] [Commented] (GEODE-10312) Remove SpringBootApplication In SwaggerConfig
[
https://issues.apache.org/jira/browse/GEODE-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542109#comment-17542109
]
Patrick Johnsn commented on GEODE-10312:
That is my concern, but I'm not sure. Most URLs are unchanged, including all
the endpoints I could find mentioned in the docs.
> Remove SpringBootApplication In SwaggerConfig
> -
>
> Key: GEODE-10312
> URL: https://issues.apache.org/jira/browse/GEODE-10312
> Project: Geode
> Issue Type: Bug
> Components: locator, rest (admin), rest (dev)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Attachments: GEODE-10312.zip
>
>
> The issue was introduced by GEODE-10282. As part of commit
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4],
> {{SwaggerConfig}} classes used to start and configure the internal
> {{geode-web-management}} and {{geode-web-api}} services use the
> {{@SpringBootApplication}} annotation. This annotation automatically enables
> other spring annotations (like {{@EnableAutoConfiguration}} and
> {{@ComponentScan}}) which, in turn, might cause critical issues during
> startup as {{spring}} tries to automatically configure several services based
> on classes and interfaces found within the member's class path.
> ---
> I'm attaching a small scenario that reproduces the problem; the
> {{reproduce.sh}} script simply starts a locator making sure that the
> {{spring-jdbc-5.3.20.jar}} is part of the class path. When using any commit
> after
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4]
> the logs will contain the following:
> {noformat}
> [info 2022/05/16 15:54:38.997 IST locator0 tid=0x1] Adding webapp
> /management
> [info 2022/05/16 15:54:39.610 IST locator0 tid=0x1] Initializing
> Servlet 'management'
> [info 2022/05/16 15:54:42.124 IST locator0 tid=0x1] Will secure any
> request with
> [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@33ed6546,
>
> org.springframework.security.web.context.SecurityContextPersistenceFilter@5a503cf0,
> org.springframework.security.web.header.HeaderWriterFilter@5b04224a,
> org.springframework.security.web.authentication.logout.LogoutFilter@17db90a7,
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter@6f78c132,
>
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@42f9b425,
>
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter@54d62c35,
> org.springframework.security.web.session.SessionManagementFilter@78907a46,
> org.springframework.security.web.access.ExceptionTranslationFilter@eaf3dd0,
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor@7cd6b76a]
> [warn 2022/05/16 15:54:42.975 IST locator0 tid=0x1] Exception
> encountered during context initialization - cancelling refresh attempt:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> [error 2022/05/16 15:54:42.980 IST locator0 tid=0x1] Context
> initialization failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> at
> org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:800)
> at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:541)
> at
> org.springframework
[jira] [Commented] (GEODE-10312) Remove SpringBootApplication In SwaggerConfig
[
https://issues.apache.org/jira/browse/GEODE-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541755#comment-17541755
]
Patrick Johnsn commented on GEODE-10312:
I think I may be close. I've removed @SpringBootApplication and the swagger
endpoints seem to be working. The only issue is that I've had to change
`v1/api-docs` to `v3/api-docs` in the URLs, which is the new default for
springdoc/AOS3.0. I thought this should be configurable with the
`springdoc.swagger-ui.configUrl` property, but it's seemingly ignored.
If changing the URL is permissible, then I think this is done, if not, I will
work on finding a way to configure it correctly.
> Remove SpringBootApplication In SwaggerConfig
> -
>
> Key: GEODE-10312
> URL: https://issues.apache.org/jira/browse/GEODE-10312
> Project: Geode
> Issue Type: Bug
> Components: locator, rest (admin), rest (dev)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Attachments: GEODE-10312.zip
>
>
> The issue was introduced by GEODE-10282. As part of commit
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4],
> {{SwaggerConfig}} classes used to start and configure the internal
> {{geode-web-management}} and {{geode-web-api}} services use the
> {{@SpringBootApplication}} annotation. This annotation automatically enables
> other spring annotations (like {{@EnableAutoConfiguration}} and
> {{@ComponentScan}}) which, in turn, might cause critical issues during
> startup as {{spring}} tries to automatically configure several services based
> on classes and interfaces found within the member's class path.
> ---
> I'm attaching a small scenario that reproduces the problem; the
> {{reproduce.sh}} script simply starts a locator making sure that the
> {{spring-jdbc-5.3.20.jar}} is part of the class path. When using any commit
> after
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4]
> the logs will contain the following:
> {noformat}
> [info 2022/05/16 15:54:38.997 IST locator0 tid=0x1] Adding webapp
> /management
> [info 2022/05/16 15:54:39.610 IST locator0 tid=0x1] Initializing
> Servlet 'management'
> [info 2022/05/16 15:54:42.124 IST locator0 tid=0x1] Will secure any
> request with
> [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@33ed6546,
>
> org.springframework.security.web.context.SecurityContextPersistenceFilter@5a503cf0,
> org.springframework.security.web.header.HeaderWriterFilter@5b04224a,
> org.springframework.security.web.authentication.logout.LogoutFilter@17db90a7,
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter@6f78c132,
>
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@42f9b425,
>
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter@54d62c35,
> org.springframework.security.web.session.SessionManagementFilter@78907a46,
> org.springframework.security.web.access.ExceptionTranslationFilter@eaf3dd0,
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor@7cd6b76a]
> [warn 2022/05/16 15:54:42.975 IST locator0 tid=0x1] Exception
> encountered during context initialization - cancelling refresh attempt:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> [error 2022/05/16 15:54:42.980 IST locator0 tid=0x1] Context
> initialization failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.l
[jira] [Commented] (GEODE-10312) Remove SpringBootApplication In SwaggerConfig
[
https://issues.apache.org/jira/browse/GEODE-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541628#comment-17541628
]
Patrick Johnsn commented on GEODE-10312:
I'm still having trouble getting Springdoc working correctly without
boot/autoconfiguration. It should be possible, but none of the documentation or
samples talk about doing it without boot. Apparently, the library was designed
to integrate with spring boot specifically.
I have made some progress: I've gotten swagger UI to start without boot for
geode-web-api at least, but not at the correct URL (v3/v1). This should be
configurable, but the properties seem to be ignored. This at least gives me a
starting point to figure out what's missing without boot.
> Remove SpringBootApplication In SwaggerConfig
> -
>
> Key: GEODE-10312
> URL: https://issues.apache.org/jira/browse/GEODE-10312
> Project: Geode
> Issue Type: Bug
> Components: locator, rest (admin), rest (dev)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.15.0
> Attachments: GEODE-10312.zip
>
>
> The issue was introduced by GEODE-10282. As part of commit
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4],
> {{SwaggerConfig}} classes used to start and configure the internal
> {{geode-web-management}} and {{geode-web-api}} services use the
> {{@SpringBootApplication}} annotation. This annotation automatically enables
> other spring annotations (like {{@EnableAutoConfiguration}} and
> {{@ComponentScan}}) which, in turn, might cause critical issues during
> startup as {{spring}} tries to automatically configure several services based
> on classes and interfaces found within the member's class path.
> ---
> I'm attaching a small scenario that reproduces the problem; the
> {{reproduce.sh}} script simply starts a locator making sure that the
> {{spring-jdbc-5.3.20.jar}} is part of the class path. When using any commit
> after
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4]
> the logs will contain the following:
> {noformat}
> [info 2022/05/16 15:54:38.997 IST locator0 tid=0x1] Adding webapp
> /management
> [info 2022/05/16 15:54:39.610 IST locator0 tid=0x1] Initializing
> Servlet 'management'
> [info 2022/05/16 15:54:42.124 IST locator0 tid=0x1] Will secure any
> request with
> [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@33ed6546,
>
> org.springframework.security.web.context.SecurityContextPersistenceFilter@5a503cf0,
> org.springframework.security.web.header.HeaderWriterFilter@5b04224a,
> org.springframework.security.web.authentication.logout.LogoutFilter@17db90a7,
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter@6f78c132,
>
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@42f9b425,
>
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter@54d62c35,
> org.springframework.security.web.session.SessionManagementFilter@78907a46,
> org.springframework.security.web.access.ExceptionTranslationFilter@eaf3dd0,
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor@7cd6b76a]
> [warn 2022/05/16 15:54:42.975 IST locator0 tid=0x1] Exception
> encountered during context initialization - cancelling refresh attempt:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> [error 2022/05/16 15:54:42.980 IST locator0 tid=0x1] Context
> initialization failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of
[jira] [Assigned] (GEODE-10312) Remove SpringBootApplication In SwaggerConfig
[
https://issues.apache.org/jira/browse/GEODE-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn reassigned GEODE-10312:
--
Assignee: Patrick Johnsn (was: Patrick Johnson)
> Remove SpringBootApplication In SwaggerConfig
> -
>
> Key: GEODE-10312
> URL: https://issues.apache.org/jira/browse/GEODE-10312
> Project: Geode
> Issue Type: Bug
> Components: locator, rest (admin), rest (dev)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.15.0
> Attachments: GEODE-10312.zip
>
>
> The issue was introduced by GEODE-10282. As part of commit
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4],
> {{SwaggerConfig}} classes used to start and configure the internal
> {{geode-web-management}} and {{geode-web-api}} services use the
> {{@SpringBootApplication}} annotation. This annotation automatically enables
> other spring annotations (like {{@EnableAutoConfiguration}} and
> {{@ComponentScan}}) which, in turn, might cause critical issues during
> startup as {{spring}} tries to automatically configure several services based
> on classes and interfaces found within the member's class path.
> ---
> I'm attaching a small scenario that reproduces the problem; the
> {{reproduce.sh}} script simply starts a locator making sure that the
> {{spring-jdbc-5.3.20.jar}} is part of the class path. When using any commit
> after
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4]
> the logs will contain the following:
> {noformat}
> [info 2022/05/16 15:54:38.997 IST locator0 tid=0x1] Adding webapp
> /management
> [info 2022/05/16 15:54:39.610 IST locator0 tid=0x1] Initializing
> Servlet 'management'
> [info 2022/05/16 15:54:42.124 IST locator0 tid=0x1] Will secure any
> request with
> [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@33ed6546,
>
> org.springframework.security.web.context.SecurityContextPersistenceFilter@5a503cf0,
> org.springframework.security.web.header.HeaderWriterFilter@5b04224a,
> org.springframework.security.web.authentication.logout.LogoutFilter@17db90a7,
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter@6f78c132,
>
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@42f9b425,
>
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter@54d62c35,
> org.springframework.security.web.session.SessionManagementFilter@78907a46,
> org.springframework.security.web.access.ExceptionTranslationFilter@eaf3dd0,
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor@7cd6b76a]
> [warn 2022/05/16 15:54:42.975 IST locator0 tid=0x1] Exception
> encountered during context initialization - cancelling refresh attempt:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> [error 2022/05/16 15:54:42.980 IST locator0 tid=0x1] Context
> initialization failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> at
> org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:800)
> at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:541)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1352)
> at
> org
[jira] [Resolved] (GEODE-10316) Convert the rest APIs to use plain spring rather than Spring Boot.
[ https://issues.apache.org/jira/browse/GEODE-10316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn resolved GEODE-10316. Resolution: Duplicate Closing in favor of GEODE-10312 > Convert the rest APIs to use plain spring rather than Spring Boot. > -- > > Key: GEODE-10316 > URL: https://issues.apache.org/jira/browse/GEODE-10316 > Project: Geode > Issue Type: Task > Components: rest (admin), rest (dev) >Affects Versions: 1.15.0 >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Related to https://issues.apache.org/jira/browse/GEODE-10282, where Boot was > introduced. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10316) Convert the rest APIs to use plain spring rather than Spring Boot.
[ https://issues.apache.org/jira/browse/GEODE-10316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538512#comment-17538512 ] Patrick Johnsn commented on GEODE-10316: I've got it working without Spring Boot, but only by changing the `v1` in the URLs to `v3` because swagger-ui is trying to fetch configuration from `/geode/v3/api-docs/swagger-config` instead of `/geode/v1/api-docs/swagger-config`. This SHOULD be configurable with `springdoc.swagger-ui.configUrl`, but it doesn't seem to be having any effect. Changing `v1` to `v3` isn't ideal, so I'm going to continue looking for a way to make it use `v1`. I have a rough PR: https://github.com/apache/geode/pull/7701 > Convert the rest APIs to use plain spring rather than Spring Boot. > -- > > Key: GEODE-10316 > URL: https://issues.apache.org/jira/browse/GEODE-10316 > Project: Geode > Issue Type: Task > Components: rest (admin), rest (dev) >Affects Versions: 1.15.0 >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Related to https://issues.apache.org/jira/browse/GEODE-10282, where Boot was > introduced. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10316) Convert the rest APIs to use plain spring rather than Spring Boot.
Patrick Johnsn created GEODE-10316: -- Summary: Convert the rest APIs to use plain spring rather than Spring Boot. Key: GEODE-10316 URL: https://issues.apache.org/jira/browse/GEODE-10316 Project: Geode Issue Type: Task Components: rest (admin), rest (dev) Affects Versions: 1.15.0 Reporter: Patrick Johnsn Related to https://issues.apache.org/jira/browse/GEODE-10282, where Boot was introduced. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10316) Convert the rest APIs to use plain spring rather than Spring Boot.
[ https://issues.apache.org/jira/browse/GEODE-10316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-10316: -- Assignee: Patrick Johnsn > Convert the rest APIs to use plain spring rather than Spring Boot. > -- > > Key: GEODE-10316 > URL: https://issues.apache.org/jira/browse/GEODE-10316 > Project: Geode > Issue Type: Task > Components: rest (admin), rest (dev) >Affects Versions: 1.15.0 >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Related to https://issues.apache.org/jira/browse/GEODE-10282, where Boot was > introduced. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10282) Migrate from springfox to springdoc
[ https://issues.apache.org/jira/browse/GEODE-10282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn resolved GEODE-10282. Fix Version/s: 1.15.0 Resolution: Fixed > Migrate from springfox to springdoc > --- > > Key: GEODE-10282 > URL: https://issues.apache.org/jira/browse/GEODE-10282 > Project: Geode > Issue Type: Task > Components: rest (admin), rest (dev) >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0 > > > Replace springfox with springdoc because springfox is no longer active. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10282) Migrate from springfox to springdoc
[ https://issues.apache.org/jira/browse/GEODE-10282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-10282: -- Assignee: Patrick Johnsn > Migrate from springfox to springdoc > --- > > Key: GEODE-10282 > URL: https://issues.apache.org/jira/browse/GEODE-10282 > Project: Geode > Issue Type: Task > Components: rest (admin), rest (dev) >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Replace springfox with springdoc because springfox is no longer active. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10282) Migrate from springfox to springdoc
Patrick Johnsn created GEODE-10282: -- Summary: Migrate from springfox to springdoc Key: GEODE-10282 URL: https://issues.apache.org/jira/browse/GEODE-10282 Project: Geode Issue Type: Task Components: rest (admin), rest (dev) Reporter: Patrick Johnsn Replace springfox with springdoc because springfox is no longer active. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10184) CI failure on windows: non-zero exit status on gfsh command in DeployWithLargeJarTest > deployLargeSetOfJars
[
https://issues.apache.org/jira/browse/GEODE-10184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn resolved GEODE-10184.
Fix Version/s: 1.15.0
Resolution: Fixed
> CI failure on windows: non-zero exit status on gfsh command in
> DeployWithLargeJarTest > deployLargeSetOfJars
>
>
> Key: GEODE-10184
> URL: https://issues.apache.org/jira/browse/GEODE-10184
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> Deploy large jar test fails due to non-zero exit status on gfsh command on
> windows
>
> [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14291025]
>
> {noformat}
> > Task :geode-assembly:acceptanceTest
> DeployWithLargeJarTest > deployLargeSetOfJars FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [e66e7d3e01750dd9: gfsh -e start locator --name=locator --max-heap=128m -e
> start server --name=server --max-heap=128m --server-port=0 -e sleep --time=1
> -e deploy
> --jars=C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-beanutils-1.9.4.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-codec-1.15.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-collections-3.2.2.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-digester-2.1.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-io-2.11.0.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-lang3-3.12.0.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-logging-1.2.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-modeler-2.0.1.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-validator-1.7.jar]]
>
> expected: 0
> but was: 1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> 176 tests completed, 1 failed, 18 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-results/acceptanceTest/1648482211/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-artifacts/1648482211/windows-acceptancetestfiles-openjdk8-1.15.0-build.1035.tgz{noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10261) VMProvider.invokeAsync does not consistently use Generic types
[ https://issues.apache.org/jira/browse/GEODE-10261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-10261: -- Assignee: Patrick Johnsn > VMProvider.invokeAsync does not consistently use Generic types > -- > > Key: GEODE-10261 > URL: https://issues.apache.org/jira/browse/GEODE-10261 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.14.4 >Reporter: Joris Melchior >Assignee: Patrick Johnsn >Priority: Minor > Labels: needsTriage > > In the VMProvider class there are several invokeAsync methods with various > signatures and in some cases they come with Generic type parameters and in > some cases they don't. > It's possible that some of this is influenced by the use of > SerializableCallableIF vs. SerializableRunnableIF so we need to dig a little > deeper to find out to what degree we need to or can make changes here. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn resolved GEODE-9880.
---
Resolution: Workaround
The issue only exists when running in an environment without the ability to do
DNS lookups from the client which, according to Charlie, is something we
shouldn't support.
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.12.10, membership
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn updated GEODE-9880:
--
Labels: blocks-1.12.10 membership (was: blocks-1.12.10 blocks-1.15.0
membership)
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.12.10, membership
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17523945#comment-17523945
]
Patrick Johnsn commented on GEODE-9880:
---
Some details to reproduce:
1. GemfirePoolManager creates org.apache.geode.cache.client.PoolFactory
2. GemfirePoolManager sets locators by calling poolFactory.addLocator(). This
sets IP ADDRESS-es of locators
3. Then, among other things, there is a process done over and over internally
by geode cache instance that sends a query to configured locators to
dynamically update the list of locators
3.1 Before actually sending the request to a locator, the hostname will be
found, based on the ip address, and stored as part of the configured locators
list.
3.2 When the request-response is done, the response will be a currently active
list of locators, but this will include only HOST NAMES.
3.3 The configured list of locators will be merged with the currently active
locators got from the response.
Then 3.1 will be repeated again.
The merging done in step 3.3 tries to extend the initially configured locators
list, but skips the matches BASED ON THE HOSTNAME.
If prior to sending the request the 3.1 was done, then the merging step has no
practical effect, because the hostname in the initial list and in the response
matches.
This is the happy path that happens naturally when there is just one locator
configured - i.e. for a non HA setup.
But for HA setup, when there are two locators, 3.1-3.3 flow completes with the
first locator, while the second locator's configuration contains only the IP
ADDRESS, since the step 3.2 was not done yet for that entry.
At this point, the first locator response contains the HOSTNAME of the second
locator, and this name is added to the configured locators list, without
understanding that it is already there in the list.
So we end up with two entries for the second locator - one with IP address only
and another with hostname only.
After this, whenever there is a need to contact a locator, unluckily, the entry
with only the hostname is picked as the first preferred locator to be
contacted, but this time, the ip address will not be auto-generated for the
entry, instead a null reference of type InetAddress will be obtained and
attempted to use in a code which has appeared in 1.12.5 to do stricter TLS
handshake. This is where we get the null pointer exception, and the whole
communication with the locators gets blocked. Other configured locators are no
more contacted because of the exception.
The good news is that, probably by some configuration, the hostname that is
obtained from the ip address is not actually involved strictly in TLS SNI
process. This would be a problem since the certificates that we have configured
have common name (CN) set to fixed value such as "common-name" and there is no
subject alternative name (SAN).
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.12.10, blocks-1.15.0, membership
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn reassigned GEODE-9880:
-
Assignee: Patrick Johnsn
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.12.10, blocks-1.15.0, membership
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10184) CI failure on windows: non-zero exit status on gfsh command in DeployWithLargeJarTest > deployLargeSetOfJars
[
https://issues.apache.org/jira/browse/GEODE-10184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520783#comment-17520783
]
Patrick Johnsn commented on GEODE-10184:
The problem is caused by the way Windows handles concurrent file access. We
check that the status file exists, and then if it does, try to read it. This
will sometimes fail on Windows if the file is being accessed by another
process. The solution is to check not only if the file exists, but also if it
can be opened before trying to read from it. Once opened, it must remain open
until we are done with it, to avoid a race condition where another process
could get ahold of it between the check and the read.
> CI failure on windows: non-zero exit status on gfsh command in
> DeployWithLargeJarTest > deployLargeSetOfJars
>
>
> Key: GEODE-10184
> URL: https://issues.apache.org/jira/browse/GEODE-10184
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: needsTriage
>
> Deploy large jar test fails due to non-zero exit status on gfsh command on
> windows
>
> [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14291025]
>
> {noformat}
> > Task :geode-assembly:acceptanceTest
> DeployWithLargeJarTest > deployLargeSetOfJars FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [e66e7d3e01750dd9: gfsh -e start locator --name=locator --max-heap=128m -e
> start server --name=server --max-heap=128m --server-port=0 -e sleep --time=1
> -e deploy
> --jars=C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-beanutils-1.9.4.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-codec-1.15.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-collections-3.2.2.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-digester-2.1.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-io-2.11.0.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-lang3-3.12.0.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-logging-1.2.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-modeler-2.0.1.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-validator-1.7.jar]]
>
> expected: 0
> but was: 1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> 176 tests completed, 1 failed, 18 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-results/acceptanceTest/1648482211/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-artifacts/1648482211/windows-acceptancetestfiles-openjdk8-1.15.0-build.1035.tgz{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10217) Mockito Unable to Mock org.apache.geode.internal.cache.DiskRegion
Patrick Johnsn created GEODE-10217:
--
Summary: Mockito Unable to Mock
org.apache.geode.internal.cache.DiskRegion
Key: GEODE-10217
URL: https://issues.apache.org/jira/browse/GEODE-10217
Project: Geode
Issue Type: Bug
Components: core, tests
Reporter: Patrick Johnsn
Mokito cannot mock DiskRegion, DiskRegionView, and AbstractDiskRegion because
Byte Buddy could not instrument all classes within the mock's type hierarchy.
{noformat}
DiskEntryHelperTest > doSynchronousWriteReturnsTrueWhenDiskRegionIsSync FAILED
10:19:40org.mockito.exceptions.base.MockitoException:
10:19:40Mockito cannot mock this class: class
org.apache.geode.internal.cache.DiskRegion.
10:19:40
10:19:40If you're not sure why you're getting this error, please report to
the mailing list.
10:19:40
10:19:40
10:19:40Java : 1.8
10:19:40JVM vendor name: BellSoft
10:19:40JVM vendor version : 25.322-b06
10:19:40JVM name : OpenJDK 64-Bit Server VM
10:19:40JVM version: 1.8.0_322-b06
10:19:40JVM info : mixed mode
10:19:40OS name: Linux
10:19:40OS version : 5.4.0-1069-gcp
10:19:40
10:19:40
10:19:40You are seeing this disclaimer because Mockito is configured to
create inlined mocks.
10:19:40You can learn about inline mocks and their limitations under item
#39 of the Mockito class javadoc.
10:19:40
10:19:40Underlying exception :
org.mockito.exceptions.base.MockitoException: Could not modify all classes
[class org.apache.geode.internal.cache.DiskRegion, interface
org.apache.geode.internal.cache.persistence.DiskRegionView, class
org.apache.geode.internal.cache.AbstractDiskRegion]
10:19:40at
org.apache.geode.internal.cache.entries.DiskEntryHelperTest.(DiskEntryHelperTest.java:44)
10:19:40
10:19:40Caused by:
10:19:40org.mockito.exceptions.base.MockitoException: Could not modify
all classes [class org.apache.geode.internal.cache.DiskRegion, interface
org.apache.geode.internal.cache.persistence.DiskRegionView, class
org.apache.geode.internal.cache.AbstractDiskRegion]
10:19:40at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
10:19:40at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
10:19:40... 1 more
10:19:40
10:19:40Caused by:
10:19:40java.lang.IllegalStateException:
10:19:40Byte Buddy could not instrument all classes within the
mock's type hierarchy
10:19:40
10:19:40This problem should never occur for javac-compiled classes.
This problem has been observed for classes that are:
10:19:40 - Compiled by older versions of scalac
10:19:40 - Classes that are part of the Android distribution
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.triggerRetransformation(InlineBytecodeGenerator.java:280)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.mockClass(InlineBytecodeGenerator.java:213)
10:19:40at
org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.lambda$mockClass$0(TypeCachingBytecodeGenerator.java:47)
10:19:40at
net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
10:19:40at
net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
10:19:40at
org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.mockClass(TypeCachingBytecodeGenerator.java:40)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMockType(InlineDelegateByteBuddyMockMaker.java:389)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.doCreateMock(InlineDelegateByteBuddyMockMaker.java:349)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMock(InlineDelegateByteBuddyMockMaker.java:328)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineByteBuddyMockMaker.createMock(InlineByteBuddyMockMaker.java:56)
10:19:40at
org.mockito.internal.util.MockUtil.createMock(MockUtil.java:53)
10:19:40at
org.mockito.internal.MockitoCore.mock(MockitoCore.java:96)
10:19:40at org.mockito.Mockito.mock(Mockito.java:1965)
10:19:40at org.mockito.Mockito.mock(Mockito.java:1880)
10:19
[jira] [Commented] (GEODE-10184) CI failure on windows: non-zero exit status on gfsh command in DeployWithLargeJarTest > deployLargeSetOfJars
[
https://issues.apache.org/jira/browse/GEODE-10184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515580#comment-17515580
]
Patrick Johnsn commented on GEODE-10184:
The issue seems to come from the ControlFileWatchdog not being able to read the
PID from the vf.gf.server.status file because it's either empty or missing,
probably empty. I haven't been able to reproduce the issue other than by
manually deleting the vf.gf.server.status file, which doesn't tell us much. The
failure's test output doesn't indicate why vf.gf.server.status is
blank/missing, so without being able to reproduce it, I can't figure out what
caused it to fail.
> CI failure on windows: non-zero exit status on gfsh command in
> DeployWithLargeJarTest > deployLargeSetOfJars
>
>
> Key: GEODE-10184
> URL: https://issues.apache.org/jira/browse/GEODE-10184
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: needsTriage
>
> Deploy large jar test fails due to non-zero exit status on gfsh command on
> windows
>
> [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14291025]
>
> {noformat}
> > Task :geode-assembly:acceptanceTest
> DeployWithLargeJarTest > deployLargeSetOfJars FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [e66e7d3e01750dd9: gfsh -e start locator --name=locator --max-heap=128m -e
> start server --name=server --max-heap=128m --server-port=0 -e sleep --time=1
> -e deploy
> --jars=C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-beanutils-1.9.4.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-codec-1.15.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-collections-3.2.2.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-digester-2.1.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-io-2.11.0.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-lang3-3.12.0.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-logging-1.2.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-modeler-2.0.1.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-validator-1.7.jar]]
>
> expected: 0
> but was: 1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> 176 tests completed, 1 failed, 18 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-results/acceptanceTest/1648482211/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-artifacts/1648482211/windows-acceptancetestfiles-openjdk8-1.15.0-build.1035.tgz{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10184) CI failure on windows: non-zero exit status on gfsh command in DeployWithLargeJarTest > deployLargeSetOfJars
[
https://issues.apache.org/jira/browse/GEODE-10184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn reassigned GEODE-10184:
--
Assignee: Patrick Johnsn
> CI failure on windows: non-zero exit status on gfsh command in
> DeployWithLargeJarTest > deployLargeSetOfJars
>
>
> Key: GEODE-10184
> URL: https://issues.apache.org/jira/browse/GEODE-10184
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: needsTriage
>
> Deploy large jar test fails due to non-zero exit status on gfsh command on
> windows
>
> [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14291025]
>
> {noformat}
> > Task :geode-assembly:acceptanceTest
> DeployWithLargeJarTest > deployLargeSetOfJars FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [e66e7d3e01750dd9: gfsh -e start locator --name=locator --max-heap=128m -e
> start server --name=server --max-heap=128m --server-port=0 -e sleep --time=1
> -e deploy
> --jars=C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-beanutils-1.9.4.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-codec-1.15.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-collections-3.2.2.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-digester-2.1.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-io-2.11.0.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-lang3-3.12.0.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-logging-1.2.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-modeler-2.0.1.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-validator-1.7.jar]]
>
> expected: 0
> but was: 1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> 176 tests completed, 1 failed, 18 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-results/acceptanceTest/1648482211/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-artifacts/1648482211/windows-acceptancetestfiles-openjdk8-1.15.0-build.1035.tgz{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-8705) Using JBoss Modules to implement classloader isolated jar deployment
[ https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492174#comment-17492174 ] Patrick Johnsn commented on GEODE-8705: --- Classloader isolation in Hydra can be toggled by setting the Prms.classloaderIsolated parameter to true or false. > Using JBoss Modules to implement classloader isolated jar deployment > > > Key: GEODE-8705 > URL: https://issues.apache.org/jira/browse/GEODE-8705 > Project: Geode > Issue Type: New Feature >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Introduce Classloader isolation into Geode, to avoid the potential conflict > of custom code dependencies, from deployed jars, and the dependencies of the > Geode system. > This problem became evident when Geode was still dependent on Spring > framework 4.3 and users wanted to deploy custom jars that used Spring > framework 5. This caused many library version conflicts. > This problem is not limited to the usage of Spring in the system but to ANY > dependent library that Geode and any potential custom jar would use. > The end goal is to have a system that is Classloader isolated and allows for > the usage of libraries of different versions within Geode without any > conflicts. > > See RFC > [https://cwiki.apache.org/confluence/display/GEODE/ClassLoader+Isolation] for > further details -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-8705) Using JBoss Modules to implement classloader isolated jar deployment
[ https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492172#comment-17492172 ] Patrick Johnsn commented on GEODE-8705: --- By default, DUnits run without classloader isolation. This behavior can be toggled by setting the `classloader.isolated` system property (true/false) when launching the test(s). > Using JBoss Modules to implement classloader isolated jar deployment > > > Key: GEODE-8705 > URL: https://issues.apache.org/jira/browse/GEODE-8705 > Project: Geode > Issue Type: New Feature >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Introduce Classloader isolation into Geode, to avoid the potential conflict > of custom code dependencies, from deployed jars, and the dependencies of the > Geode system. > This problem became evident when Geode was still dependent on Spring > framework 4.3 and users wanted to deploy custom jars that used Spring > framework 5. This caused many library version conflicts. > This problem is not limited to the usage of Spring in the system but to ANY > dependent library that Geode and any potential custom jar would use. > The end goal is to have a system that is Classloader isolated and allows for > the usage of libraries of different versions within Geode without any > conflicts. > > See RFC > [https://cwiki.apache.org/confluence/display/GEODE/ClassLoader+Isolation] for > further details -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8705) Using JBoss Modules to implement classloader isolated jar deployment
[ https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn updated GEODE-8705: -- Description: Introduce Classloader isolation into Geode, to avoid the potential conflict of custom code dependencies, from deployed jars, and the dependencies of the Geode system. This problem became evident when Geode was still dependent on Spring framework 4.3 and users wanted to deploy custom jars that used Spring framework 5. This caused many library version conflicts. This problem is not limited to the usage of Spring in the system but to ANY dependent library that Geode and any potential custom jar would use. The end goal is to have a system that is Classloader isolated and allows for the usage of libraries of different versions within Geode without any conflicts. See RFC [https://cwiki.apache.org/confluence/display/GEODE/ClassLoader+Isolation] for further details was: Introduce Classloader isolation into Geode, to avoid the potential conflict of custom code dependencies, from deploy jar, and the dependencies of the Geode system. This problem because evident when Geode was still dependent on Spring framework 4.3 and users wanted to deploy custom jars that used Spring framework 5. This caused many library version conflicts. This problem is not limited to the usage of Spring in the system but to ANY dependent library that Geode and any potential custom jar would use. The end goal is to have a system that is Classloader isolated and allows for the usage of libraries of different versions within the Geode without any conflicts. See RFC [https://cwiki.apache.org/confluence/display/GEODE/ClassLoader+Isolation] for further details > Using JBoss Modules to implement classloader isolated jar deployment > > > Key: GEODE-8705 > URL: https://issues.apache.org/jira/browse/GEODE-8705 > Project: Geode > Issue Type: New Feature >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Introduce Classloader isolation into Geode, to avoid the potential conflict > of custom code dependencies, from deployed jars, and the dependencies of the > Geode system. > This problem became evident when Geode was still dependent on Spring > framework 4.3 and users wanted to deploy custom jars that used Spring > framework 5. This caused many library version conflicts. > This problem is not limited to the usage of Spring in the system but to ANY > dependent library that Geode and any potential custom jar would use. > The end goal is to have a system that is Classloader isolated and allows for > the usage of libraries of different versions within Geode without any > conflicts. > > See RFC > [https://cwiki.apache.org/confluence/display/GEODE/ClassLoader+Isolation] for > further details -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9377) Revert deploymentName on Deployment configuration object.
[ https://issues.apache.org/jira/browse/GEODE-9377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn resolved GEODE-9377. --- Fix Version/s: 1.15.0 Resolution: Fixed > Revert deploymentName on Deployment configuration object. > - > > Key: GEODE-9377 > URL: https://issues.apache.org/jira/browse/GEODE-9377 > Project: Geode > Issue Type: Bug > Components: configuration, gfsh, management >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Revert the addition of deploymentName to Deployment to avoid serialization > issues with older versions that use fileName. Deployment name was added as > part of ticket GEODE-8705, to support a dropped feature. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9377) Revert deploymentName on Deployment configuration object.
Patrick Johnsn created GEODE-9377: - Summary: Revert deploymentName on Deployment configuration object. Key: GEODE-9377 URL: https://issues.apache.org/jira/browse/GEODE-9377 Project: Geode Issue Type: Bug Components: configuration, gfsh, management Reporter: Patrick Johnsn Revert the addition of deploymentName to Deployment to avoid serialization issues with older versions that use fileName. Deployment name was added as part of ticket GEODE-8705, to support a dropped feature. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9377) Revert deploymentName on Deployment configuration object.
[ https://issues.apache.org/jira/browse/GEODE-9377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-9377: - Assignee: Patrick Johnsn > Revert deploymentName on Deployment configuration object. > - > > Key: GEODE-9377 > URL: https://issues.apache.org/jira/browse/GEODE-9377 > Project: Geode > Issue Type: Bug > Components: configuration, gfsh, management >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Revert the addition of deploymentName to Deployment to avoid serialization > issues with older versions that use fileName. Deployment name was added as > part of ticket GEODE-8705, to support a dropped feature. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9065) Create a ClasspathService interface to back ClassPathLoader
[ https://issues.apache.org/jira/browse/GEODE-9065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn updated GEODE-9065: -- Summary: Create a ClasspathService interface to back ClassPathLoader (was: Create a ClassLoaderService interface to back ClassPathLoader) > Create a ClasspathService interface to back ClassPathLoader > --- > > Key: GEODE-9065 > URL: https://issues.apache.org/jira/browse/GEODE-9065 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.15.0 >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > The ClasspathService will encapsulate the differences between classloading in > JBoss modules compared to the current way of working. There will be an > implementation for JBoss and another for legacy. This interface will be used > to back the ClassPathLoader so it will behave appropriately in both worlds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9065) Create a ClassLoaderService interface to back ClassPathLoader
[ https://issues.apache.org/jira/browse/GEODE-9065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn updated GEODE-9065: -- Description: The ClasspathService will encapsulate the differences between classloading in JBoss modules compared to the current way of working. There will be an implementation for JBoss and another for legacy. This interface will be used to back the ClassPathLoader so it will behave appropriately in both worlds. (was: The ClassLoaderService will encapsulate the differences between classloading in JBoss modules compared to the current way of working. There will be an implementation for JBoss and another for legacy. Tjs interface will be sed to back the ClassPathLoader so it will behave appropriately in both worlds.) > Create a ClassLoaderService interface to back ClassPathLoader > - > > Key: GEODE-9065 > URL: https://issues.apache.org/jira/browse/GEODE-9065 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.15.0 >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > The ClasspathService will encapsulate the differences between classloading in > JBoss modules compared to the current way of working. There will be an > implementation for JBoss and another for legacy. This interface will be used > to back the ClassPathLoader so it will behave appropriately in both worlds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9065) Create a ClassLoaderService interface to back ClassPathLoader
[ https://issues.apache.org/jira/browse/GEODE-9065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-9065: - Assignee: Patrick Johnsn > Create a ClassLoaderService interface to back ClassPathLoader > - > > Key: GEODE-9065 > URL: https://issues.apache.org/jira/browse/GEODE-9065 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.15.0 >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > The ClassLoaderService will encapsulate the differences between classloading > in JBoss modules compared to the current way of working. There will be an > implementation for JBoss and another for legacy. Tjs interface will be sed to > back the ClassPathLoader so it will behave appropriately in both worlds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9065) Create a ClassLoaderService interface to back ClassPathLoader
Patrick Johnsn created GEODE-9065: - Summary: Create a ClassLoaderService interface to back ClassPathLoader Key: GEODE-9065 URL: https://issues.apache.org/jira/browse/GEODE-9065 Project: Geode Issue Type: Improvement Affects Versions: 1.15.0 Reporter: Patrick Johnsn The ClassLoaderService will encapsulate the differences between classloading in JBoss modules compared to the current way of working. There will be an implementation for JBoss and another for legacy. Tjs interface will be sed to back the ClassPathLoader so it will behave appropriately in both worlds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8466) Create a ClassLoaderService to abstract away dealing with the default ClassLoader directly
[ https://issues.apache.org/jira/browse/GEODE-8466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn resolved GEODE-8466. --- Resolution: Won't Do > Create a ClassLoaderService to abstract away dealing with the default > ClassLoader directly > -- > > Key: GEODE-8466 > URL: https://issues.apache.org/jira/browse/GEODE-8466 > Project: Geode > Issue Type: New Feature > Components: core >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > With the addition of ClassLoader isolation using JBoss Modules GEODE-8067, > the manner in which we interact with the ClassLoader needs to change. > An abstraction is required around the default functions like > `findResourceAsStream`, `loadClass` and `loadService`. > As these features will behave differently between different ClassLoader > implementations, it is best to have a single service that will expose that > functionality in a transparent manner. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8905) Introduce JarDeploymentService
Patrick Johnsn created GEODE-8905: - Summary: Introduce JarDeploymentService Key: GEODE-8905 URL: https://issues.apache.org/jira/browse/GEODE-8905 Project: Geode Issue Type: Improvement Components: gfsh, management Reporter: Patrick Johnsn Introduce a JarDeploymentService interface that will allow us to interchange the current way of deploying jars with the new modular approach. There will be an implementation that delegates to the existing JarDeployer and will maintain current behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8733) Local region holds onto data by reference
[
https://issues.apache.org/jira/browse/GEODE-8733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn updated GEODE-8733:
--
Issue Type: Bug (was: Improvement)
> Local region holds onto data by reference
> -
>
> Key: GEODE-8733
> URL: https://issues.apache.org/jira/browse/GEODE-8733
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.13.0
>Reporter: Patrick Johnsn
>Priority: Major
>
> If the client region is configured as `CACHING_PROXY`, the data on the server
> and the data in the local region can become out of sync because the local
> region stores things by reference, for example, if you were to do:
>
> {code:java}
> list.add(1);
> list.add(2);
> list.add(3);
> list.add(4);
> map.put(1, "a");
> map.put(2, "b");
> map.put(3, "c");
> map.put(4, "d");
> Class1 obj = new Class1(1, list, map);
> region.put(obj.id, obj);
> map.clear();
> list.clear();
> map.put(12, "This shouldn't be here");
> list.add(38);
> System.out.println(region.get(1).toString());{code}
>
> the values retrieved by region.get(1) would look like "Class1\{id=1,
> someList=[38], someMap={12=This shouldn't be here}}" even though that update
> was made AFTER the put.
>
> If you queried the server, you'd get the expected values because you're going
> directly to the server instead of the local region.
>
> This issue was originally reported against Spring Data Geode but is
> reproducible in plain Geode.
> Original ticket for context: https://jira.spring.io/browse/DATAGEODE-388
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8733) Local region holds onto data by reference
Patrick Johnsn created GEODE-8733:
-
Summary: Local region holds onto data by reference
Key: GEODE-8733
URL: https://issues.apache.org/jira/browse/GEODE-8733
Project: Geode
Issue Type: Improvement
Components: regions
Affects Versions: 1.13.0
Reporter: Patrick Johnsn
If the client region is configured as `CACHING_PROXY`, the data on the server
and the data in the local region can become out of sync because the local
region stores things by reference, for example, if you were to do:
{code:java}
list.add(1);
list.add(2);
list.add(3);
list.add(4);
map.put(1, "a");
map.put(2, "b");
map.put(3, "c");
map.put(4, "d");
Class1 obj = new Class1(1, list, map);
region.put(obj.id, obj);
map.clear();
list.clear();
map.put(12, "This shouldn't be here");
list.add(38);
System.out.println(region.get(1).toString());{code}
the values retrieved by region.get(1) would look like "Class1\{id=1,
someList=[38], someMap={12=This shouldn't be here}}" even though that update
was made AFTER the put.
If you queried the server, you'd get the expected values because you're going
directly to the server instead of the local region.
This issue was originally reported against Spring Data Geode but is
reproducible in plain Geode.
Original ticket for context: https://jira.spring.io/browse/DATAGEODE-388
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8619) Create ServiceRegistry
Patrick Johnsn created GEODE-8619: - Summary: Create ServiceRegistry Key: GEODE-8619 URL: https://issues.apache.org/jira/browse/GEODE-8619 Project: Geode Issue Type: Improvement Reporter: Patrick Johnsn Create ServiceRegistry to hold single instances of services to be accessed statically where they are required. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8502) Pass member name as gemfire property in StartServerCommand
[ https://issues.apache.org/jira/browse/GEODE-8502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn updated GEODE-8502: -- Component/s: core Description: Currently, the StartServerCommand puts the server name arbitrarily on the command used to launch the server process. We should instead set the name as a -D property to make it consistent with other properties and avoid the logic necessary to decern the name from other parts of the command string. This may also be applicable to other commands like StartLocatorCommand. Along with changing the command, we need to change ServerLauncher to expect the name to come in this new form. was:Currently, the StartServerCommand puts the server name arbitrarily on the command used to launch the server process. We should instead set the name as a -D property to make it consistent with other properties and avoid the logic necessary to decern the name from other parts of the command string. This may also be applicable to other commands like StartLocatorCommand. > Pass member name as gemfire property in StartServerCommand > -- > > Key: GEODE-8502 > URL: https://issues.apache.org/jira/browse/GEODE-8502 > Project: Geode > Issue Type: Task > Components: core, gfsh >Reporter: Patrick Johnsn >Priority: Major > > Currently, the StartServerCommand puts the server name arbitrarily on the > command used to launch the server process. We should instead set the name as > a -D property to make it consistent with other properties and avoid the logic > necessary to decern the name from other parts of the command string. This may > also be applicable to other commands like StartLocatorCommand. > > Along with changing the command, we need to change ServerLauncher to expect > the name to come in this new form. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8502) Pass member name as gemfire property in StartServerCommand
Patrick Johnsn created GEODE-8502: - Summary: Pass member name as gemfire property in StartServerCommand Key: GEODE-8502 URL: https://issues.apache.org/jira/browse/GEODE-8502 Project: Geode Issue Type: Task Components: gfsh Reporter: Patrick Johnsn Currently, the StartServerCommand puts the server name arbitrarily on the command used to launch the server process. We should instead set the name as a -D property to make it consistent with other properties and avoid the logic necessary to decern the name from other parts of the command string. This may also be applicable to other commands like StartLocatorCommand. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8461) Create new ClassLoader Isolated ServerLauncher
Patrick Johnsn created GEODE-8461:
-
Summary: Create new ClassLoader Isolated ServerLauncher
Key: GEODE-8461
URL: https://issues.apache.org/jira/browse/GEODE-8461
Project: Geode
Issue Type: Improvement
Reporter: Patrick Johnsn
Create a new ServerLauncher that is to be used to bootstrap a server in a
separate Java Process with ClassLoader isolation.
Using BootstrappingService and ModuleService.
This Launcher will be in a separate Geode module {{geode-launchers}} and not be
dependent on {{geode-core}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8461) Create new ClassLoader Isolated ServerLauncher
[
https://issues.apache.org/jira/browse/GEODE-8461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn reassigned GEODE-8461:
-
Assignee: Patrick Johnsn
> Create new ClassLoader Isolated ServerLauncher
> --
>
> Key: GEODE-8461
> URL: https://issues.apache.org/jira/browse/GEODE-8461
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnsn
>Priority: Major
>
> Create a new ServerLauncher that is to be used to bootstrap a server in a
> separate Java Process with ClassLoader isolation.
> Using BootstrappingService and ModuleService.
> This Launcher will be in a separate Geode module {{geode-launchers}} and not
> be dependent on {{geode-core}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8239) Gradle configuration to create manifests for all Geode jars
[ https://issues.apache.org/jira/browse/GEODE-8239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn resolved GEODE-8239. --- Fix Version/s: 1.14.0 Resolution: Fixed > Gradle configuration to create manifests for all Geode jars > --- > > Key: GEODE-8239 > URL: https://issues.apache.org/jira/browse/GEODE-8239 > Project: Geode > Issue Type: Sub-task > Components: client/server >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > Fix For: 1.14.0 > > > Modify the Gradle configuration to generate a manifest file with "Class-Path" > and "Dependent-Modules" attributes inside the jars. This manifest will be > used when defining modules using the jars. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8306) Introduce GeodeEntityResolver2 interface on top of EntityResolver2
Patrick Johnsn created GEODE-8306: - Summary: Introduce GeodeEntityResolver2 interface on top of EntityResolver2 Key: GEODE-8306 URL: https://issues.apache.org/jira/browse/GEODE-8306 Project: Geode Issue Type: Improvement Reporter: Patrick Johnsn Introduce GeodeEntityResolver2 interface on top of EntityResolver2 to introduce an init method for passing in a ModuleService. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8306) Introduce GeodeEntityResolver2 interface on top of EntityResolver2
[ https://issues.apache.org/jira/browse/GEODE-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-8306: - Assignee: Patrick Johnsn > Introduce GeodeEntityResolver2 interface on top of EntityResolver2 > -- > > Key: GEODE-8306 > URL: https://issues.apache.org/jira/browse/GEODE-8306 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Introduce GeodeEntityResolver2 interface on top of EntityResolver2 to > introduce an init method for passing in a ModuleService. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8271) Update Spring dependencies to newer patch versions
Patrick Johnsn created GEODE-8271: - Summary: Update Spring dependencies to newer patch versions Key: GEODE-8271 URL: https://issues.apache.org/jira/browse/GEODE-8271 Project: Geode Issue Type: Improvement Reporter: Patrick Johnsn Update all Spring artifacts to the latest patch versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8271) Update Spring dependencies to newer patch versions
[ https://issues.apache.org/jira/browse/GEODE-8271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-8271: - Assignee: Patrick Johnsn > Update Spring dependencies to newer patch versions > -- > > Key: GEODE-8271 > URL: https://issues.apache.org/jira/browse/GEODE-8271 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Update all Spring artifacts to the latest patch versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8239) Gradle configuration to create manifests for all Geode jars
[ https://issues.apache.org/jira/browse/GEODE-8239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-8239: - Assignee: Patrick Johnsn (was: Patrick Johnson) > Gradle configuration to create manifests for all Geode jars > --- > > Key: GEODE-8239 > URL: https://issues.apache.org/jira/browse/GEODE-8239 > Project: Geode > Issue Type: Sub-task > Components: client/server >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Modify the Gradle configuration to generate a manifest file with "Class-Path" > and "Dependent-Modules" attributes inside the jars. This manifest will be > used when defining modules using the jars. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8190) Create JBoss Module to load jar with manifest and classpath
[ https://issues.apache.org/jira/browse/GEODE-8190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-8190: - Assignee: Patrick Johnsn (was: Patrick Johnson) > Create JBoss Module to load jar with manifest and classpath > --- > > Key: GEODE-8190 > URL: https://issues.apache.org/jira/browse/GEODE-8190 > Project: Geode > Issue Type: Sub-task > Components: client/server >Reporter: Udo Kohlmeyer >Assignee: Patrick Johnsn >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8190) Create JBoss Module to load jar with manifest and classpath
[ https://issues.apache.org/jira/browse/GEODE-8190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn resolved GEODE-8190. --- Resolution: Done > Create JBoss Module to load jar with manifest and classpath > --- > > Key: GEODE-8190 > URL: https://issues.apache.org/jira/browse/GEODE-8190 > Project: Geode > Issue Type: Sub-task > Components: client/server >Reporter: Udo Kohlmeyer >Assignee: Patrick Johnsn >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8239) Gradle configuration to create manifests for all Geode jars
Patrick Johnsn created GEODE-8239: - Summary: Gradle configuration to create manifests for all Geode jars Key: GEODE-8239 URL: https://issues.apache.org/jira/browse/GEODE-8239 Project: Geode Issue Type: Sub-task Reporter: Patrick Johnsn Modify the Gradle configuration to generate a manifest file with "Class-Path" and "Dependent-Modules" attributes inside the jars. This manifest will be used when defining modules using the jars. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8169) Create BootStrappingService Implementation
[ https://issues.apache.org/jira/browse/GEODE-8169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn updated GEODE-8169: -- Description: Create an implementation of the BootStrappingService interface to load Geode using ModuleService. > Create BootStrappingService Implementation > -- > > Key: GEODE-8169 > URL: https://issues.apache.org/jira/browse/GEODE-8169 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Priority: Major > > Create an implementation of the BootStrappingService interface to load Geode > using ModuleService. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8169) Create BootStrappingService Implementation
[ https://issues.apache.org/jira/browse/GEODE-8169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-8169: - Assignee: Patrick Johnsn > Create BootStrappingService Implementation > -- > > Key: GEODE-8169 > URL: https://issues.apache.org/jira/browse/GEODE-8169 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Create an implementation of the BootStrappingService interface to load Geode > using ModuleService. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8169) Create BootStrappingService Implementation
Patrick Johnsn created GEODE-8169: - Summary: Create BootStrappingService Implementation Key: GEODE-8169 URL: https://issues.apache.org/jira/browse/GEODE-8169 Project: Geode Issue Type: Sub-task Reporter: Patrick Johnsn -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8148) Implement unloadModule in JBossModuleService
[ https://issues.apache.org/jira/browse/GEODE-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-8148: - Assignee: Patrick Johnsn > Implement unloadModule in JBossModuleService > > > Key: GEODE-8148 > URL: https://issues.apache.org/jira/browse/GEODE-8148 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > unloadModule will unload JBoss modules previously loaded by loadModule. > unloadModule takes a String that represents the name of the module to find > and unload. It should return true when successfully unloading a module and > false if it cannot find or cannot unload the specified module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8148) Implement unloadModule in JBossModuleService
Patrick Johnsn created GEODE-8148: - Summary: Implement unloadModule in JBossModuleService Key: GEODE-8148 URL: https://issues.apache.org/jira/browse/GEODE-8148 Project: Geode Issue Type: Sub-task Reporter: Patrick Johnsn unloadModule will unload JBoss modules previously loaded by loadModule. unloadModule takes a String that represents the name of the module to find and unload. It should return true when successfully unloading a module and false if it cannot find or cannot unload the specified module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8137) Implement loadService on JBossModuleService
[ https://issues.apache.org/jira/browse/GEODE-8137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-8137: - Assignee: Patrick Johnsn > Implement loadService on JBossModuleService > --- > > Key: GEODE-8137 > URL: https://issues.apache.org/jira/browse/GEODE-8137 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Implement loadService to load implementations of a given interface from JBoss > Modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8137) Implement loadService on JBossModuleService
Patrick Johnsn created GEODE-8137: - Summary: Implement loadService on JBossModuleService Key: GEODE-8137 URL: https://issues.apache.org/jira/browse/GEODE-8137 Project: Geode Issue Type: Sub-task Reporter: Patrick Johnsn Implement loadService to load implementations of a given interface from JBoss Modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (GEODE-8044) Move services related to classloader-isolation to geode-common-services.
[ https://issues.apache.org/jira/browse/GEODE-8044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reopened GEODE-8044: --- > Move services related to classloader-isolation to geode-common-services. > > > Key: GEODE-8044 > URL: https://issues.apache.org/jira/browse/GEODE-8044 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (GEODE-8033) Create ModuleService Interface
[ https://issues.apache.org/jira/browse/GEODE-8033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reopened GEODE-8033: --- > Create ModuleService Interface > -- > > Key: GEODE-8033 > URL: https://issues.apache.org/jira/browse/GEODE-8033 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Introduce a new Gradle sub-project called `geode-module` and create a > ModuleService interface within it. This interface will be used to load/unload > modules and services in a classloader-isolated way. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8037) Create BootstrappingService Interface
[ https://issues.apache.org/jira/browse/GEODE-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn updated GEODE-8037: -- Fix Version/s: 1.14.0 > Create BootstrappingService Interface > - > > Key: GEODE-8037 > URL: https://issues.apache.org/jira/browse/GEODE-8037 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > Fix For: 1.14.0 > > > Create a BootstrapingService interface. The BootstrappingService will use the > ModuleService to bootstrap Geode in a classloader-isolated way, i.e. loading > the necessary modules to run Geode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8041) Create ManagementService Interface
[ https://issues.apache.org/jira/browse/GEODE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn updated GEODE-8041: -- Description: Create a ManagementService interface. The ManagementService will configure and start Geode (create a Cache given some configuration properties) after the BootstrappingService has bootstrapped the environment and loaded the relevant modules. (was: Create a ManagementService interface, which will be used to create a cache given some configuration.) > Create ManagementService Interface > -- > > Key: GEODE-8041 > URL: https://issues.apache.org/jira/browse/GEODE-8041 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Create a ManagementService interface. The ManagementService will configure > and start Geode (create a Cache given some configuration properties) after > the BootstrappingService has bootstrapped the environment and loaded the > relevant modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8037) Create BootstrappingService Interface
[ https://issues.apache.org/jira/browse/GEODE-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn resolved GEODE-8037. --- Resolution: Fixed > Create BootstrappingService Interface > - > > Key: GEODE-8037 > URL: https://issues.apache.org/jira/browse/GEODE-8037 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Create a BootstrapingService interface. The BootstrappingService will use the > ModuleService to bootstrap Geode in a classloader-isolated way, i.e. loading > the necessary modules to run Geode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8037) Create BootstrappingService Interface
[ https://issues.apache.org/jira/browse/GEODE-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn updated GEODE-8037: -- Description: Create a BootstrapingService interface. The BootstrappingService will use the ModuleService to bootstrap Geode in a classloader-isolated way, i.e. loading the necessary modules to run Geode. (was: Create a BootstrapingService interface.) > Create BootstrappingService Interface > - > > Key: GEODE-8037 > URL: https://issues.apache.org/jira/browse/GEODE-8037 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Create a BootstrapingService interface. The BootstrappingService will use the > ModuleService to bootstrap Geode in a classloader-isolated way, i.e. loading > the necessary modules to run Geode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8043) Create JBoss-Modules ModuleService Implementation - loadModule
[ https://issues.apache.org/jira/browse/GEODE-8043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn updated GEODE-8043: -- Parent: GEODE-8067 Issue Type: Sub-task (was: New Feature) > Create JBoss-Modules ModuleService Implementation - loadModule > -- > > Key: GEODE-8043 > URL: https://issues.apache.org/jira/browse/GEODE-8043 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Implement the loadModule method of the ModuleService interface using > JBoss-Modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8041) Create ManagementService Interface
[ https://issues.apache.org/jira/browse/GEODE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn updated GEODE-8041: -- Parent: GEODE-8067 Issue Type: Sub-task (was: New Feature) > Create ManagementService Interface > -- > > Key: GEODE-8041 > URL: https://issues.apache.org/jira/browse/GEODE-8041 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Create a ManagementService interface, which will be used to create a cache > given some configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8037) Create BootstrappingService Interface
[ https://issues.apache.org/jira/browse/GEODE-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn updated GEODE-8037: -- Parent: GEODE-8067 Issue Type: Sub-task (was: New Feature) > Create BootstrappingService Interface > - > > Key: GEODE-8037 > URL: https://issues.apache.org/jira/browse/GEODE-8037 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Create a BootstrapingService interface. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8068) Revert GEODE-8033 and GEODE-8044
Patrick Johnsn created GEODE-8068: - Summary: Revert GEODE-8033 and GEODE-8044 Key: GEODE-8068 URL: https://issues.apache.org/jira/browse/GEODE-8068 Project: Geode Issue Type: New Feature Reporter: Patrick Johnsn -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8033) Create ModuleService Interface
[ https://issues.apache.org/jira/browse/GEODE-8033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn updated GEODE-8033: -- Fix Version/s: (was: 1.12.1) 1.13.0 > Create ModuleService Interface > -- > > Key: GEODE-8033 > URL: https://issues.apache.org/jira/browse/GEODE-8033 > Project: Geode > Issue Type: New Feature >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > Fix For: 1.13.0 > > > Introduce a new Gradle sub-project called `geode-module` and create a > ModuleService interface within it. This interface will be used to load/unload > modules and services in a classloader-isolated way. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8044) Move services related to classloader-isolation to geode-common-services.
[ https://issues.apache.org/jira/browse/GEODE-8044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn resolved GEODE-8044. --- Fix Version/s: 1.13.0 Resolution: Fixed > Move services related to classloader-isolation to geode-common-services. > > > Key: GEODE-8044 > URL: https://issues.apache.org/jira/browse/GEODE-8044 > Project: Geode > Issue Type: New Feature >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > Fix For: 1.13.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8033) Create ModuleService Interface
[ https://issues.apache.org/jira/browse/GEODE-8033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn resolved GEODE-8033. --- Fix Version/s: 1.12.1 Resolution: Fixed > Create ModuleService Interface > -- > > Key: GEODE-8033 > URL: https://issues.apache.org/jira/browse/GEODE-8033 > Project: Geode > Issue Type: New Feature >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > Fix For: 1.12.1 > > > Introduce a new Gradle sub-project called `geode-module` and create a > ModuleService interface within it. This interface will be used to load/unload > modules and services in a classloader-isolated way. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8044) Move services related to classloader-isolation to geode-common-services.
[ https://issues.apache.org/jira/browse/GEODE-8044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-8044: - Assignee: Patrick Johnsn > Move services related to classloader-isolation to geode-common-services. > > > Key: GEODE-8044 > URL: https://issues.apache.org/jira/browse/GEODE-8044 > Project: Geode > Issue Type: New Feature >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8037) Create BootstrappingService Interface
[ https://issues.apache.org/jira/browse/GEODE-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn updated GEODE-8037: -- Description: Create a BootstrapingService interface. (was: Introduce a new Gradle sub-project called geode-bootstrapping and create a BootstrapingService interface.) > Create BootstrappingService Interface > - > > Key: GEODE-8037 > URL: https://issues.apache.org/jira/browse/GEODE-8037 > Project: Geode > Issue Type: New Feature >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Create a BootstrapingService interface. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8044) Move services related to classloader-isolation to geode-common-services.
Patrick Johnsn created GEODE-8044: - Summary: Move services related to classloader-isolation to geode-common-services. Key: GEODE-8044 URL: https://issues.apache.org/jira/browse/GEODE-8044 Project: Geode Issue Type: New Feature Reporter: Patrick Johnsn -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8041) Create ManagementService Interface
[ https://issues.apache.org/jira/browse/GEODE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn updated GEODE-8041: -- Description: Create a ManagementService interface, which will be used to create a cache given some configuration. (was: Introduce geode-uber-management sub-project and create a ManagementService interface, which will be used to create a cache given some configuration.) > Create ManagementService Interface > -- > > Key: GEODE-8041 > URL: https://issues.apache.org/jira/browse/GEODE-8041 > Project: Geode > Issue Type: New Feature >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Create a ManagementService interface, which will be used to create a cache > given some configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8043) Create JBoss-Modules ModuleService Implementation - loadModule
Patrick Johnsn created GEODE-8043: - Summary: Create JBoss-Modules ModuleService Implementation - loadModule Key: GEODE-8043 URL: https://issues.apache.org/jira/browse/GEODE-8043 Project: Geode Issue Type: New Feature Reporter: Patrick Johnsn Implement the loadModule method of the ModuleService interface using JBoss-Modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8043) Create JBoss-Modules ModuleService Implementation - loadModule
[ https://issues.apache.org/jira/browse/GEODE-8043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-8043: - Assignee: Patrick Johnsn > Create JBoss-Modules ModuleService Implementation - loadModule > -- > > Key: GEODE-8043 > URL: https://issues.apache.org/jira/browse/GEODE-8043 > Project: Geode > Issue Type: New Feature >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Implement the loadModule method of the ModuleService interface using > JBoss-Modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8041) Create ManagementService Interface
[ https://issues.apache.org/jira/browse/GEODE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-8041: - Assignee: Patrick Johnsn > Create ManagementService Interface > -- > > Key: GEODE-8041 > URL: https://issues.apache.org/jira/browse/GEODE-8041 > Project: Geode > Issue Type: New Feature >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Introduce geode-uber-management sub-project and create a ManagementService > interface, which will be used to create a cache given some configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8041) Create ManagementService Interface
Patrick Johnsn created GEODE-8041: - Summary: Create ManagementService Interface Key: GEODE-8041 URL: https://issues.apache.org/jira/browse/GEODE-8041 Project: Geode Issue Type: New Feature Reporter: Patrick Johnsn Introduce geode-uber-management sub-project and create a ManagementService interface, which will be used to create a cache given some configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8037) Create BootstrappingService Interface
[ https://issues.apache.org/jira/browse/GEODE-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-8037: - Assignee: Patrick Johnsn > Create BootstrappingService Interface > - > > Key: GEODE-8037 > URL: https://issues.apache.org/jira/browse/GEODE-8037 > Project: Geode > Issue Type: New Feature >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > INtroduce a new Gradle sub-project called geode-bootstrapping and create a > BootstrapingService interface. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8037) Create BootstrappingService Interface
[ https://issues.apache.org/jira/browse/GEODE-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn updated GEODE-8037: -- Description: Introduce a new Gradle sub-project called geode-bootstrapping and create a BootstrapingService interface. (was: INtroduce a new Gradle sub-project called geode-bootstrapping and create a BootstrapingService interface.) > Create BootstrappingService Interface > - > > Key: GEODE-8037 > URL: https://issues.apache.org/jira/browse/GEODE-8037 > Project: Geode > Issue Type: New Feature >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Introduce a new Gradle sub-project called geode-bootstrapping and create a > BootstrapingService interface. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8037) Create BootstrappingService Interface
Patrick Johnsn created GEODE-8037: - Summary: Create BootstrappingService Interface Key: GEODE-8037 URL: https://issues.apache.org/jira/browse/GEODE-8037 Project: Geode Issue Type: New Feature Reporter: Patrick Johnsn INtroduce a new Gradle sub-project called geode-bootstrapping and create a BootstrapingService interface. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8033) Create ModuleService Interface
[ https://issues.apache.org/jira/browse/GEODE-8033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-8033: - Assignee: Patrick Johnsn > Create ModuleService Interface > -- > > Key: GEODE-8033 > URL: https://issues.apache.org/jira/browse/GEODE-8033 > Project: Geode > Issue Type: New Feature >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Introduce a new Gradle sub-project called `geode-module` and create a > ModuleService interface within it. This interface will be used to load/unload > modules and services in a classloader-isolated way. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8033) Create ModuleService Interface
Patrick Johnsn created GEODE-8033: - Summary: Create ModuleService Interface Key: GEODE-8033 URL: https://issues.apache.org/jira/browse/GEODE-8033 Project: Geode Issue Type: New Feature Reporter: Patrick Johnsn Introduce a new Gradle sub-project called `geode-module` and create a ModuleService interface within it. This interface will be used to load/unload modules and services in a classloader-isolated way. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8005) NPE on locator when connecting to ClusterManagementService using a cache.
Patrick Johnsn created GEODE-8005:
-
Summary: NPE on locator when connecting to
ClusterManagementService using a cache.
Key: GEODE-8005
URL: https://issues.apache.org/jira/browse/GEODE-8005
Project: Geode
Issue Type: Bug
Components: gfsh, management
Reporter: Patrick Johnsn
Starting a cluster in gfsh like this:
{code:java}
gfsh> start locator
gfsh> start server{code}
And creating a GeodeConnectionConfig like this:
{code:java}
ClientCache clientCache = new ClientCacheFactory()
.addPoolLocator("localhost", 10334)
.create();
ConnectionConfig connectionConfig = new
GeodeConnectionConfig(clientCache);{code}
will result in the following exception on the client:
{code:java}
Exception in thread "main" java.lang.IllegalStateException: Unable to discover
a locator that has ClusterManagementService running.Exception in thread "main"
java.lang.IllegalStateException: Unable to discover a locator that has
ClusterManagementService running. at
org.apache.geode.management.internal.api.GeodeConnectionConfig.setClientCache(GeodeConnectionConfig.java:126)
at
org.apache.geode.management.internal.api.GeodeConnectionConfig.(GeodeConnectionConfig.java:74)
at example.v2.Experiment.main(Experiment.java:42) {code}
And this exception in the locator logs:
{code:java}
java.lang.NullPointerExceptionjava.lang.NullPointerException at
org.apache.geode.management.internal.configuration.handlers.ClusterManagementServiceInfoRequestHandler.processRequest(ClusterManagementServiceInfoRequestHandler.java:56)
at
org.apache.geode.distributed.internal.membership.gms.locator.PrimaryHandler.processRequest(PrimaryHandler.java:70)
at
org.apache.geode.distributed.internal.tcpserver.TcpServer.processOneConnection(TcpServer.java:421)
at
org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:326)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748) {code}
A workaround for this is to set "--bind-address=localhost" when starting the
locator.
Despite this exception, the ClusterManagementService is running on the locator
and the endpoints can still be accessed using hostname and port.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn updated GEODE-7763:
--
Attachment: 1.11_thread_dumps.rtf
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Attachments: 1.11-client-stats.gfs, 1.11-server-stats.gfs,
> 1.11_thread_dumps.rtf, 1.9-client-stats.gfs, 1.9-server-stats.gfs, 1.9.log,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt
>
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2. with Apache Geode 1.9.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set to *180* and the *Workload
> Size* (or number of Region operations) was set to *10,000*.
> This had to be significantly adjusted in SSDG 2.3 using Apache Geode 1.11
> (and, as it turns out, Apache Geode 1.10 as well), as can be seen in the
> {{2.3.0.M1}} release bits source,
> [here|https://github.com/spring-projects/spring-session-data-geode/blob/2.3.0.M1/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L94-L95].
> It turns out different combinations of the Thread Count (number of workers,
> or "concurrent Sessions") and Workload Size ultimately determine whether this
> test class passes or not.
> In
[jira] [Updated] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn updated GEODE-7763:
--
Attachment: 1.9.log
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Attachments: 1.11-client-stats.gfs, 1.11-server-stats.gfs,
> 1.9-client-stats.gfs, 1.9-server-stats.gfs, 1.9.log,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt
>
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2. with Apache Geode 1.9.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set to *180* and the *Workload
> Size* (or number of Region operations) was set to *10,000*.
> This had to be significantly adjusted in SSDG 2.3 using Apache Geode 1.11
> (and, as it turns out, Apache Geode 1.10 as well), as can be seen in the
> {{2.3.0.M1}} release bits source,
> [here|https://github.com/spring-projects/spring-session-data-geode/blob/2.3.0.M1/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L94-L95].
> It turns out different combinations of the Thread Count (number of workers,
> or "concurrent Sessions") and Workload Size ultimately determine whether this
> test class passes or not.
> In other words, if I increase the Threa
[jira] [Updated] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn updated GEODE-7763:
--
Attachment: 1.9-server-stats.gfs
1.9-client-stats.gfs
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Attachments: 1.11-client-stats.gfs, 1.11-server-stats.gfs,
> 1.9-client-stats.gfs, 1.9-server-stats.gfs,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt
>
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set to *180* and the *Workload
> Size* (or number of Region operations) was set to *10,000*.
> This had to be significantly adjusted in SSDG 2.3 using Apache Geode 1.11
> (and, as it turns out, Apache Geode 1.10 as well), as can be seen in the
> {{2.3.0.M1}} release bits source,
> [here|https://github.com/spring-projects/spring-session-data-geode/blob/2.3.0.M1/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L94-L95].
> It turns out different combinations of the Thread Count (number of workers,
> or "concurrent Sessions") and Workload Size ultimately determine whether this
> test class passes or not.
> In other words, if I in
[jira] [Updated] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn updated GEODE-7763:
--
Attachment: 1.11-server-stats.gfs
1.11-client-stats.gfs
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Attachments: 1.11-client-stats.gfs, 1.11-server-stats.gfs,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt
>
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set to *180* and the *Workload
> Size* (or number of Region operations) was set to *10,000*.
> This had to be significantly adjusted in SSDG 2.3 using Apache Geode 1.11
> (and, as it turns out, Apache Geode 1.10 as well), as can be seen in the
> {{2.3.0.M1}} release bits source,
> [here|https://github.com/spring-projects/spring-session-data-geode/blob/2.3.0.M1/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L94-L95].
> It turns out different combinations of the Thread Count (number of workers,
> or "concurrent Sessions") and Workload Size ultimately determine whether this
> test class passes or not.
> In other words, if I increase the Thread Count, then the Workload Si
[jira] [Updated] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn updated GEODE-7763:
--
Attachment: (was: 1.11.-server-stats.txt)
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Attachments: apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt
>
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set to *180* and the *Workload
> Size* (or number of Region operations) was set to *10,000*.
> This had to be significantly adjusted in SSDG 2.3 using Apache Geode 1.11
> (and, as it turns out, Apache Geode 1.10 as well), as can be seen in the
> {{2.3.0.M1}} release bits source,
> [here|https://github.com/spring-projects/spring-session-data-geode/blob/2.3.0.M1/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L94-L95].
> It turns out different combinations of the Thread Count (number of workers,
> or "concurrent Sessions") and Workload Size ultimately determine whether this
> test class passes or not.
> In other words, if I increase the Thread Count, then the Workload Size must
> decrease, otherwise the test fails! If I increase the Workload
[jira] [Updated] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn updated GEODE-7763:
--
Attachment: (was: 1.11-client-stats.txt)
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Attachments: apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt
>
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set to *180* and the *Workload
> Size* (or number of Region operations) was set to *10,000*.
> This had to be significantly adjusted in SSDG 2.3 using Apache Geode 1.11
> (and, as it turns out, Apache Geode 1.10 as well), as can be seen in the
> {{2.3.0.M1}} release bits source,
> [here|https://github.com/spring-projects/spring-session-data-geode/blob/2.3.0.M1/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L94-L95].
> It turns out different combinations of the Thread Count (number of workers,
> or "concurrent Sessions") and Workload Size ultimately determine whether this
> test class passes or not.
> In other words, if I increase the Thread Count, then the Workload Size must
> decrease, otherwise the test fails! If I increase the Workload S
[jira] [Updated] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn updated GEODE-7763:
--
Attachment: (was: client-stats.txt)
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Attachments: 1.11-client-stats.txt, 1.11.-server-stats.txt,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt
>
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set to *180* and the *Workload
> Size* (or number of Region operations) was set to *10,000*.
> This had to be significantly adjusted in SSDG 2.3 using Apache Geode 1.11
> (and, as it turns out, Apache Geode 1.10 as well), as can be seen in the
> {{2.3.0.M1}} release bits source,
> [here|https://github.com/spring-projects/spring-session-data-geode/blob/2.3.0.M1/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L94-L95].
> It turns out different combinations of the Thread Count (number of workers,
> or "concurrent Sessions") and Workload Size ultimately determine whether this
> test class passes or not.
> In other words, if I increase the Thread Count, then the Workload Size must
> decrease, otherwise
[jira] [Updated] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn updated GEODE-7763:
--
Attachment: (was: server-stats.txt)
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Attachments: 1.11-client-stats.txt, 1.11.-server-stats.txt,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt
>
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set to *180* and the *Workload
> Size* (or number of Region operations) was set to *10,000*.
> This had to be significantly adjusted in SSDG 2.3 using Apache Geode 1.11
> (and, as it turns out, Apache Geode 1.10 as well), as can be seen in the
> {{2.3.0.M1}} release bits source,
> [here|https://github.com/spring-projects/spring-session-data-geode/blob/2.3.0.M1/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L94-L95].
> It turns out different combinations of the Thread Count (number of workers,
> or "concurrent Sessions") and Workload Size ultimately determine whether this
> test class passes or not.
> In other words, if I increase the Thread Count, then the Workload Size must
> decrease, otherwise
[jira] [Updated] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn updated GEODE-7763:
--
Attachment: 1.11.-server-stats.txt
1.11-client-stats.txt
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Attachments: 1.11-client-stats.txt, 1.11.-server-stats.txt,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt
>
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set to *180* and the *Workload
> Size* (or number of Region operations) was set to *10,000*.
> This had to be significantly adjusted in SSDG 2.3 using Apache Geode 1.11
> (and, as it turns out, Apache Geode 1.10 as well), as can be seen in the
> {{2.3.0.M1}} release bits source,
> [here|https://github.com/spring-projects/spring-session-data-geode/blob/2.3.0.M1/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L94-L95].
> It turns out different combinations of the Thread Count (number of workers,
> or "concurrent Sessions") and Workload Size ultimately determine whether this
> test class passes or not.
> In other words, if I increase the Thread Count, then the Workload
[jira] [Updated] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn updated GEODE-7763:
--
Attachment: server-stats.txt
client-stats.txt
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Attachments: 1.11-client-stats.txt, 1.11.-server-stats.txt,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt
>
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set to *180* and the *Workload
> Size* (or number of Region operations) was set to *10,000*.
> This had to be significantly adjusted in SSDG 2.3 using Apache Geode 1.11
> (and, as it turns out, Apache Geode 1.10 as well), as can be seen in the
> {{2.3.0.M1}} release bits source,
> [here|https://github.com/spring-projects/spring-session-data-geode/blob/2.3.0.M1/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L94-L95].
> It turns out different combinations of the Thread Count (number of workers,
> or "concurrent Sessions") and Workload Size ultimately determine whether this
> test class passes or not.
> In other words, if I increase the Thread Count, then the Workload Size must
[jira] [Updated] (GEODE-7521) Region name in RebalanceCommand is missing leading '/'
[ https://issues.apache.org/jira/browse/GEODE-7521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn updated GEODE-7521: -- Fix Version/s: 1.12.0 > Region name in RebalanceCommand is missing leading '/' > -- > > Key: GEODE-7521 > URL: https://issues.apache.org/jira/browse/GEODE-7521 > Project: Geode > Issue Type: Bug >Reporter: Patrick Johnsn >Assignee: Patrick Johnson >Priority: Major > Fix For: 1.12.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7496) Decouple management API from Gfsh RebalanceCommand
[ https://issues.apache.org/jira/browse/GEODE-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn resolved GEODE-7496. --- Fix Version/s: 1.12.0 Assignee: Patrick Johnsn Resolution: Fixed > Decouple management API from Gfsh RebalanceCommand > -- > > Key: GEODE-7496 > URL: https://issues.apache.org/jira/browse/GEODE-7496 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > Fix For: 1.12.0 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
