[JBoss JIRA] (DROOLS-3731) DMN UX - More info overlaid on models.
by Tao Zhu (Jira)
[ https://issues.jboss.org/browse/DROOLS-3731?page=com.atlassian.jira.plugi... ]
Tao Zhu updated DROOLS-3731:
----------------------------
Attachment: 屏幕快照 2019-06-11 下午3.10.26.png
> DMN UX - More info overlaid on models.
> --------------------------------------
>
> Key: DROOLS-3731
> URL: https://issues.jboss.org/browse/DROOLS-3731
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Tao Zhu
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam, drools-tools
> Attachments: Screen Shot 2019-05-29 at 2.49.21 PM.png, download (1).png, download.png, 屏幕快照 2019-06-11 下午3.02.19.png, 屏幕快照 2019-06-11 下午3.10.26.png
>
>
> As a practitioner, there are situations where I need to show additional information about a model... for instance: test coverage report: I need to draw a model and color code the nodes to show which nodes were executed by tests, or which rows on a DT were a match. Or when I execute a single test, what was the actual value of a given node or expression.
> Note: Maybe in read-only mode with an "overlay" on top of the model the additional metadata information. See process instance diagram design examples.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3731) DMN UX - More info overlaid on models.
by Tao Zhu (Jira)
[ https://issues.jboss.org/browse/DROOLS-3731?page=com.atlassian.jira.plugi... ]
Tao Zhu updated DROOLS-3731:
----------------------------
Attachment: 屏幕快照 2019-06-11 下午3.02.19.png
> DMN UX - More info overlaid on models.
> --------------------------------------
>
> Key: DROOLS-3731
> URL: https://issues.jboss.org/browse/DROOLS-3731
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Tao Zhu
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam, drools-tools
> Attachments: Screen Shot 2019-05-29 at 2.49.21 PM.png, download (1).png, download.png, 屏幕快照 2019-06-11 下午3.02.19.png
>
>
> As a practitioner, there are situations where I need to show additional information about a model... for instance: test coverage report: I need to draw a model and color code the nodes to show which nodes were executed by tests, or which rows on a DT were a match. Or when I execute a single test, what was the actual value of a given node or expression.
> Note: Maybe in read-only mode with an "overlay" on top of the model the additional metadata information. See process instance diagram design examples.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFCORE-4514) ProxyMetadataSource breaks contract of ClassMetadataSource#getDeclaredMethods (resulting in "illegal reflective access operation" in Java 11)
by Jaikiran Pai (Jira)
Jaikiran Pai created WFCORE-4514:
------------------------------------
Summary: ProxyMetadataSource breaks contract of ClassMetadataSource#getDeclaredMethods (resulting in "illegal reflective access operation" in Java 11)
Key: WFCORE-4514
URL: https://issues.jboss.org/browse/WFCORE-4514
Project: WildFly Core
Issue Type: Bug
Components: Server
Affects Versions: 9.0.1.Final
Environment: Java 11
Reporter: Jaikiran Pai
Assignee: Jeff Mesnil
While investigating this issue reported in the forum thread[1], where the user states that using Java 11 shows up a warning about illegal reflective access:
{code}
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jboss.invocation.proxy.AbstractProxyFactory$1 (jar:file:/C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/invocation/main/jboss-invocation-1.5.2.Final.jar!/) to method java.lang.Object.clone()
WARNING: Please consider reporting this to the maintainers of org.jboss.invocation.proxy.AbstractProxyFactory$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
{code}
I realized that, that issue is in fact triggered by, what I believe, is a bug and a violation of an (internal) API contract in WildFly.
What seems to be happening is - when the proxy class is being defined for (EJB) component, in the jboss-invocation library here[2], the implementation there overrides the component classes' methods. It does that for the entire class hierarchy of the component class and stops at the Object.class (rightly so) through the use of this check[3] (currentClass != Object.class). In this implementation, within the loop, it then calls:
{code}
ClassMetadataSource data = reflectionMetadataSource.getClassMetadata(currentClass);
{code}
which is an API exposed by the org.jboss.invocation.proxy.reflection.ReflectionMetadataSource interface. The returned ClassMetadataSource is then used within that loop as follows:
{code}
for (Method method : data.getDeclaredMethods()) {
....
{code}
The getDeclaredMethods() API, exposed by ClassMetadataSource[5] is expected to (only) return the methods that are declared by that class. Turns out, the implementation in WildFly[6], for this interface, doesn't honour that contract and instead returns all methods (including the ones that are in the super class) on that class:
{code}
public Collection<Method> getDeclaredMethods() {
return index.getClassMethods();
}
{code}
The index.getClassMethods() is a call to the ClassReflectionIndex#getClassMethods() whose implementation[7] walks through the entire class hierarchy and returns all the methods on that class.
This (unexpected) implemetation of ProxyMetadataSource#getDeclaredMethods()[6] causes the check in [3] to end up being irrelevant and as a result the code in [2] ends up trying to take control over methods on the Object class (by calling method.setAccessible(true)[8]) and one such method is the "clone" method. This ultimately results in that illegal reflective access warning.
Looking at the history of ProxyMetadataSource#getDeclaredMethods() in WildFly, it looks like the implementation was changed to accomodate/fix this issue https://issues.jboss.org/browse/WFCORE-579 in this commit https://github.com/wildfly/wildfly-core/commit/4382f0c28dab2d0494926b8a34.... The previous implementation was returning the correct methods (only the declared ones). Looking at that JIRA and linked bugzilla to it, I think the original issue might need a different fix. I haven't yet had a chance to look more into that issue.
Of course, one way to solve the current issue at hand (the illegal reflective access one) would be to add a check in
jboss-invocation's AbstractProxyFactory similar to this https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/..., but IMO, that would be more of a hack than an actual fix since the API contract violation in ProxyMetadataSource will still be an issue and can (and probably does) cause some unexpected problems.
[1] https://developer.jboss.org/message/989623#989623
[2] https://github.com/jbossas/jboss-invocation/blob/master/src/main/java/org...
[3] https://github.com/jbossas/jboss-invocation/blob/master/src/main/java/org...
[4] https://github.com/jbossas/jboss-invocation/blob/master/src/main/java/org...
[5] https://github.com/jbossas/jboss-invocation/blob/master/src/main/java/org...
[6] https://github.com/wildfly/wildfly-core/blob/5391b40b79f72d2a57d4e32234af...
[7] https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
[8] https://github.com/jbossas/jboss-invocation/blob/master/src/main/java/org...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Marek Kopecky (Jira)
[ https://issues.jboss.org/browse/WFLY-11566?page=com.atlassian.jira.plugin... ]
Marek Kopecky commented on WFLY-11566:
--------------------------------------
Hi Tomek, I'm trying RestClientProxyTest#testGetClient locally with WF master with RESTEasy from 3.7 branch (without your fixes). The test passes.
> ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
> ----------------------------------------------------------------------------------
>
> Key: WFLY-11566
> URL: https://issues.jboss.org/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
> 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.12.1#712002)
7 years, 1 month
[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2299:
---------------------------
Fix Version/s: 4.1.2
(was: 4.1.1)
> LockService does not work correctly if unlock/lock is called in immediate succession
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2299
> URL: https://issues.jboss.org/browse/JGRP-2299
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Environment: Windows 10 Oracle JDK 1.8 131
> AIX IBM Java 8
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.2
>
> Attachments: JGroupsExample.java, udp+lock.xml
>
>
> In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
> This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
> If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (JGRP-2320) FILE_PING.findMembers() optimizations
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2320?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2320:
---------------------------
Fix Version/s: 4.1.2
(was: 4.1.1)
> FILE_PING.findMembers() optimizations
> -------------------------------------
>
> Key: JGRP-2320
> URL: https://issues.jboss.org/browse/JGRP-2320
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.6.16, 4.0.15
> Reporter: Nick Sawadsky
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.1.2
>
>
> Following on from JGRP-2288, a couple of possible optimizations/improvements to {{FILE_PING.findMembers()}} were identified.
> 1. After the initial call to {{readAll()}}, some corrective steps are taken if the local node address was not returned by {{readAll()}}. However, in the case where {{findMembers()}} is invoked by {{TP.fetchResponsesFromDiscoveryProtocol()}}, it is normal if the local node address is not returned, since the {{readAll()}} responses are filtered based on the {{members}} parameter.
> To avoid unnecessary writes to the file or cloud store, it would be good to add some checks based on whether {{members}} is null or not. For example, the calls to {{write()}} and {{writeAll()}} should probably not occur unless {{members}} is null.
> 2. In the call to {{sendDiscoveryResponse()}}, the last parameter is always {{false}}. However, it seems possible for a coordinator to get to this point in some edge cases. Though I haven't been able to identify any clear bugs that this would lead to, it might be better to pass {{is_coord}} as the last parameter.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (JGRP-2335) Code for determining the coordinator hangs in certain conditions
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2335?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2335:
---------------------------
Fix Version/s: 4.1.2
(was: 4.1.1)
> Code for determining the coordinator hangs in certain conditions
> ----------------------------------------------------------------
>
> Key: JGRP-2335
> URL: https://issues.jboss.org/browse/JGRP-2335
> Project: JGroups
> Issue Type: Bug
> Reporter: Aieksiei Illarionov
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.2
>
>
> Affected version:
> {code:xml}
> <dependency>
> <groupId>org.jgroups</groupId>
> <artifactId>jgroups</artifactId>
> <version>4.0.0.Final</version>
> </dependency>
> {code}
> ClientGmsImpl#joinInternal hangs because #firstOfAllClients always returns false when all of the following conditions are satisfied:
> - using JDBC_PING for discovery protocol
> - JGROUPSPING table contains data from previous sessions
> - all of the previous sessions were killed (kill -9)
> - AddressGenerator is not customized
> The sorted set
> {code:java}
> SortedSet<Address> clients=new TreeSet<>();
> {code}
> contains the dead servers discovered from JGROUPSPING. When the new server is added to the sorted set, it never becomes the first in the sorted set.
> Suggestions: either
> a) somehow involve MembershipChangePolicy in ordering strategy, or
> b) make the new server (joiner) the first in the sorted set, or
> c) make UUID addresses to sort depending on their time of creation.
> I've used the following config:
> {code:xml}
> <!--
> TCP based stack, with flow control and message bundling. This is usually used when IP
> multicasting cannot be used in a network, e.g. because it is disabled (routers discard multicast).
> Note that TCP.bind_addr and TCPPING.initial_hosts should be set, possibly via system properties, e.g.
> -Djgroups.bind_addr=192.168.5.2 and -Djgroups.tcpping.initial_hosts=192.168.5.2[7800]
> author: Bela Ban
> -->
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:org:jgroups"
> xmlns:fork="fork"
> xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd fork http://www.jgroups.org/schema/fork-stacks.xsd">
> <TCP bind_port="7800"
> port_range="10"
> bind_addr="<placeholder here>"
> recv_buf_size="${tcp.recv_buf_size:130k}"
> send_buf_size="${tcp.send_buf_size:130k}"
> max_bundle_size="64K"
> sock_conn_timeout="300"
> thread_pool.min_threads="0"
> thread_pool.max_threads="20"
> thread_pool.keep_alive_time="30000"/>
> <JDBC_PING
> remove_all_data_on_view_change="true"
> connection_driver="com.microsoft.sqlserver.jdbc.SQLServerDriver"
> connection_url="jdbc:sqlserver://localhost:1433;databaseName=mydatabase"
> connection_username="user"
> connection_password="password"
> />
> <MERGE3 min_interval="10000"
> max_interval="30000"/>
> <FD_SOCK/>
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="1500" />
> <BARRIER />
> <pbcast.NAKACK2 use_mcast_xmit="false"
> discard_delivered_msgs="true"/>
> <UNICAST3
> conn_close_timeout="240000"
> xmit_interval="5000"/>
> <pbcast.STABLE desired_avg_gossip="50000"
> max_bytes="4M"/>
> <pbcast.GMS print_local_addr="true" join_timeout="2000"
> view_bundling="true"
> membership_change_policy="ru.illar.AppMembershipChangePolicy"/>
> <MFC max_credits="2M"
> min_threshold="0.4"/>
> <FRAG2 frag_size="60K" />
> <!--RSVP resend_interval="2000" timeout="10000"/-->
> <pbcast.STATE_TRANSFER/>
> </config>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month