[JBoss JIRA] (WFCORE-4791) HttpManagementConstantHeadersTestCase causes tests failures
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-4791?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-4791:
--------------------------------
Fix Version/s: 11.0.0.Beta8
(was: 11.0.0.Beta7)
> HttpManagementConstantHeadersTestCase causes tests failures
> -----------------------------------------------------------
>
> Key: WFCORE-4791
> URL: https://issues.redhat.com/browse/WFCORE-4791
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Richard Opalka
> Assignee: Tomas Terem
> Priority: Major
> Fix For: 11.0.0.Beta8
>
> Attachments: testsuite.log
>
>
> Commit 68928b0b in WildFly-Core introduced new regression.
> High probably test doesn't do proper test environment clean up
> and some tests following it are thus failing. The issue isn't visible
> in our CI environment so it probably depends on actual tests ordering.
> I am able to reproduce this issue on my laptop always.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Tomasz Adamski (Jira)
[ https://issues.redhat.com/browse/WFLY-11566?page=com.atlassian.jira.plugi... ]
Tomasz Adamski commented on WFLY-11566:
---------------------------------------
I have amended the PR leaving the bean and normalizer as the same class.
> ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
> ----------------------------------------------------------------------------------
>
> Key: WFLY-11566
> URL: https://issues.redhat.com/browse/WFLY-11566
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, EJB, REST
> Affects Versions: 14.0.0.Final, 15.0.1.Final
> Reporter: Alexander Wagner
> Assignee: Tomasz Adamski
> Priority: Critical
> Labels: downstream_dependency
> Attachments: WFLY-11566-3.tar
>
>
> You got an exception if you call methods on JAX-RS endpoints which are also e.g. a stateless EJB and have Set or List as query parameters.
> As a workaround we use the "@Context UriInfo info" as parameter an read the parameter manually. As a downside this parameters are missing than in automated api generation with e.g. swagger. Without the @NotEmpty annotation it works fine. Without the generic type parameter ie just List it works fine. Making it a simple CDI bean makes it work fine.
> This issue is caused by [commit - WFLY-9628 Allow to switch to Hibernate Validator 6.0 / Bean Validation 2.0|https://github.com/wildfly/wildfly/commit/02f230d91f55f86ee6cadf53832...]
> Steps to reproduce:
> {code:java}
> @Stateless
> @Path("/")
> public class Resource {
> @POST
> @Path("put/list")
> @Consumes(MediaType.APPLICATION_JSON)
> public String putList(@NotEmpty List<String> a) {
> return "Hello bars " + a.stream().collect(Collectors.joining(", "));
> }
> }
> {code}
> {noformat}
> [mkopecky@dhcp-10-40-5-71 bin]$ curl -d '["a","b","c"]' -H "Content-Type: application/json" -X POST http://localhost:8080/jaxrs-wf/put/list
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> [mkopecky@dhcp-10-40-5-71 bin]$
> {noformat}
> {noformat}
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> at org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply(OverridingMethodMustNotAlterParameterConstraints.java:24)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:461)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:377)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:192)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.lambda$getBeanMetaData$0(BeanMetaDataManager.java:160)
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:159)
> at org.hibernate.validator.internal.engine.ValidationContext$ValidationContextBuilder.forValidateParameters(ValidationContext.java:619)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:254)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:224)
> at org.jboss.resteasy.plugins.validation.GeneralValidatorImpl.validateAllParameters(GeneralValidatorImpl.java:177)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:118)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Links:
> * [forum|https://developer.jboss.org/thread/278822]
> * WFLY-11566
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2433) Smaller changes in Message/BaseMessage
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2433?page=com.atlassian.jira.plugin... ]
Bela Ban edited comment on JGRP-2433 at 1/14/20 8:31 AM:
---------------------------------------------------------
* Implemented {{copy()}} in {{BaseMessage}} and also introduced a method {{copyPayload()}} that's overwritten by subclasses
* I guess perf tests should be run once Infinispan has switched to JGroups 5.0 in a temp branch. Preliminary perf numbers for JGroups itself were added to JGRP-2218 some time ago.
* I prefer to continue using a short for {{flags}} and a byte for {{transient_flags}}, and not collapse them into one short, as this would leave me with only 3 additional flags. Once I remove flags (e.g. RSVP...), and possibly also remove the {{dest}} field from {{Message}}, I might reconsider this suggestion...
* I added {{msg_factory_class}} which requires the fully qualified name of a {{MsgFactory}} impl class; this cannot be set at runtime (as you mentioned, we'd not propagate that to other protocols, which fetch a ref at {{init()}} time).
* Changed ID for message type from byte -> short
* I don't think we'll be able to avoid detecting collisions between different registrations using the same ID until runtime, but since I widened the byte to a short, we have more space and less likelyhood of collisions. Wildfly and Infinispan could for example shared a common document in which they list all message types and thus avoid collisions.
* Added abstract methods {{writePayload()}} and {{readPayload()}} to {{BaseMessage}}. These are the only ones that need to be implemented instead of {{writeTo()}}, {{writeToNoAddresses()}} and {{readFrom()}}
was (Author: belaban):
* Implemented {{copy()}} in {{BaseMessage}} and also introduced a method {{copyPayload()}} that's overwritten by subclasses
* I guess perf tests should be run once Infinispan has switched to JGroups 5.0 in a temp branch. Preliminary perf numbers for JGroups itself were added to JGRP-2218 some time ago.
* I prefer to continue using a short for {{flags}} and a byte for {{transient_flags}}, and not collapse them into one short, as this would leave me with only 3 additional flags. Once I remove flags (e.g. RSVP...), and possibly also remove the {{dest}} field from {{Message}}, I might reconsider this suggestion...
* I added {{msg_factory_class}} which requires the fully qualified name of a {{MsgFactory}} impl class; this cannot be set at runtime (as you mentioned, we'd not propagate that to other protocols, which fetch a ref at {{init()}} time).
* Changed ID for message type from byte -> short
* I don't think we'll be able to avoid detecting collisions between different registrations using the same ID until runtime, but since I widened the byte to a short, we have more space and less likelyhood of collisions. Wildfly and Infinispan could for example shared a common document in which they list all message types and thus avoid collisions.
> Smaller changes in Message/BaseMessage
> --------------------------------------
>
> Key: JGRP-2433
> URL: https://issues.redhat.com/browse/JGRP-2433
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0
>
>
> Based on Pedro's suggestions (copied from \[1\]):
> *Comments/Suggestions*
> I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/...
> * The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}}
> * Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed.
>
> * -It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom-
> * -{{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO.-
> * -{{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere-
> * -I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types-
> * -Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network-
> * -no perf-ack numbers-
> \[1\] https://issues.redhat.com/browse/JGRP-2218
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2433) Smaller changes in Message/BaseMessage
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2433?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2433:
---------------------------
Description:
Based on Pedro's suggestions (copied from \[1\]):
*Comments/Suggestions*
I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/...
* The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}}
* Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed.
* -It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom-
* -{{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO.-
* -{{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere-
* -I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types-
* -Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network-
* -no perf-ack numbers-
\[1\] https://issues.redhat.com/browse/JGRP-2218
was:
Based on Pedro's suggestions (copied from \[1\]):
*Comments/Suggestions*
I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/...
* The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}}
* Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed.
* It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom
* -{{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO.-
* -{{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere-
* -I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types-
* -Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network-
* -no perf-ack numbers-
\[1\] https://issues.redhat.com/browse/JGRP-2218
> Smaller changes in Message/BaseMessage
> --------------------------------------
>
> Key: JGRP-2433
> URL: https://issues.redhat.com/browse/JGRP-2433
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0
>
>
> Based on Pedro's suggestions (copied from \[1\]):
> *Comments/Suggestions*
> I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/...
> * The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}}
> * Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed.
>
> * -It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom-
> * -{{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO.-
> * -{{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere-
> * -I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types-
> * -Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network-
> * -no perf-ack numbers-
> \[1\] https://issues.redhat.com/browse/JGRP-2218
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2433) Smaller changes in Message/BaseMessage
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2433?page=com.atlassian.jira.plugin... ]
Bela Ban edited comment on JGRP-2433 at 1/14/20 7:49 AM:
---------------------------------------------------------
* Implemented {{copy()}} in {{BaseMessage}} and also introduced a method {{copyPayload()}} that's overwritten by subclasses
* I guess perf tests should be run once Infinispan has switched to JGroups 5.0 in a temp branch. Preliminary perf numbers for JGroups itself were added to JGRP-2218 some time ago.
* I prefer to continue using a short for {{flags}} and a byte for {{transient_flags}}, and not collapse them into one short, as this would leave me with only 3 additional flags. Once I remove flags (e.g. RSVP...), and possibly also remove the {{dest}} field from {{Message}}, I might reconsider this suggestion...
* I added {{msg_factory_class}} which requires the fully qualified name of a {{MsgFactory}} impl class; this cannot be set at runtime (as you mentioned, we'd not propagate that to other protocols, which fetch a ref at {{init()}} time).
* Changed ID for message type from byte -> short
* I don't think we'll be able to avoid detecting collisions between different registrations using the same ID until runtime, but since I widened the byte to a short, we have more space and less likelyhood of collisions. Wildfly and Infinispan could for example shared a common document in which they list all message types and thus avoid collisions.
was (Author: belaban):
* Implemented {{copy()}} in {{BaseMessage}} and also introduced a method {{copyPayload()}} that's overwritten by subclasses
* I guess perf tests should be run once Infinispan has switched to JGroups 5.0 in a temp branch. Preliminary perf numbers for JGroups itself were added to JGRP-2218 some time ago.
* I prefer to continue using a short for {{flags}} and a byte for {{transient_flags}}, and not collapse them into one short, as this would leave me with only 3 additional flags. Once I remove flags (e.g. RSVP...), and possibly also remove the {{dest}} field from {{Message}}, I might reconsider this suggestion...
* I added {{msg_factory_class}} which requires the fully qualified name of a {{MsgFactory}} impl class; this cannot be set at runtime (as you mentioned, we'd not propagate that to other protocols, which fetch a ref at {{init()}} time).
* Changed ID for message type from byte -> short
> Smaller changes in Message/BaseMessage
> --------------------------------------
>
> Key: JGRP-2433
> URL: https://issues.redhat.com/browse/JGRP-2433
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0
>
>
> Based on Pedro's suggestions (copied from \[1\]):
> *Comments/Suggestions*
> I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/...
> * The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}}
> * Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed.
>
> * It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom
> * -{{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO.-
> * -{{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere-
> * -I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types-
> * -Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network-
> * -no perf-ack numbers-
> \[1\] https://issues.redhat.com/browse/JGRP-2218
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2433) Smaller changes in Message/BaseMessage
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2433?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2433:
---------------------------
Description:
Based on Pedro's suggestions (copied from \[1\]):
*Comments/Suggestions*
I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/...
* The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}}
* Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed.
* It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom
* -{{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO.-
* -{{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere-
* -I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types-
* -Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network-
* -no perf-ack numbers-
\[1\] https://issues.redhat.com/browse/JGRP-2218
was:
Based on Pedro's suggestions (copied from \[1\]):
*Comments/Suggestions*
I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/...
* The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}}
* Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed.
* It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom
* -{{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO.-
* -{{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere-
* I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types.
* -Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network-
* -no perf-ack numbers-
\[1\] https://issues.redhat.com/browse/JGRP-2218
> Smaller changes in Message/BaseMessage
> --------------------------------------
>
> Key: JGRP-2433
> URL: https://issues.redhat.com/browse/JGRP-2433
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0
>
>
> Based on Pedro's suggestions (copied from \[1\]):
> *Comments/Suggestions*
> I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/...
> * The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}}
> * Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed.
>
> * It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom
> * -{{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO.-
> * -{{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere-
> * -I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types-
> * -Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network-
> * -no perf-ack numbers-
> \[1\] https://issues.redhat.com/browse/JGRP-2218
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2433) Smaller changes in Message/BaseMessage
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2433?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2433:
---------------------------
Description:
Based on Pedro's suggestions (copied from \[1\]):
*Comments/Suggestions*
I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/...
* The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}}
* Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed.
* It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom
* -{{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO.-
* -{{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere-
* I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types.
* -Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network-
* -no perf-ack numbers-
\[1\] https://issues.redhat.com/browse/JGRP-2218
was:
Based on Pedro's suggestions (copied from \[1\]):
*Comments/Suggestions*
I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/...
* The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}}
* Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed.
* It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom
* {{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO.
* {{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere :)
* I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types.
* Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network
* no perf-ack numbers :(
\[1\] https://issues.redhat.com/browse/JGRP-2218
> Smaller changes in Message/BaseMessage
> --------------------------------------
>
> Key: JGRP-2433
> URL: https://issues.redhat.com/browse/JGRP-2433
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0
>
>
> Based on Pedro's suggestions (copied from \[1\]):
> *Comments/Suggestions*
> I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/...
> * The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}}
> * Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed.
>
> * It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom
> * -{{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO.-
> * -{{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere-
> * I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types.
> * -Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network-
> * -no perf-ack numbers-
> \[1\] https://issues.redhat.com/browse/JGRP-2218
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months