[JBoss JIRA] (WFLY-5828) Format differences between default configuration and read/persisted oneFormat differences between default configuration and read/persisted one in infinispan/undertow/ejb3 subsystems and management section
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5828?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5828:
---------------------------------
Summary: Format differences between default configuration and read/persisted oneFormat differences between default configuration and read/persisted one in infinispan/undertow/ejb3 subsystems and management section (was: Format differences between default configuration and read/persisted one)
> Format differences between default configuration and read/persisted oneFormat differences between default configuration and read/persisted one in infinispan/undertow/ejb3 subsystems and management section
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5828
> URL: https://issues.jboss.org/browse/WFLY-5828
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB, Web (Undertow)
> Affects Versions: 10.0.0.CR4
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Labels: ux
> Fix For: 10.0.0.Final
>
>
> Neverending classic, just like every release:
> {noformat}[rhusar@syrah wildfly-10.0.0.Final-SNAPSHOT]$ diff standalone/configuration/standalone-ha.xml standalone/configuration/standalone_xml_history/standalone-ha.initial.xml
> 1c1
> < <?xml version='1.0' encoding='UTF-8'?>
> ---
> > <?xml version="1.0" ?>
> 4d3
> <
> 36,37d34
> <
> <
> 64c61
> < <file-handler name="file" formatter="json-formatter" path="audit-log.log" relative-to="jboss.server.data.dir"/>
> ---
> > <file-handler name="file" formatter="json-formatter" relative-to="jboss.server.data.dir" path="audit-log.log"/>
> 87d83
> <
> 178a175
> > <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
> 182d178
> < <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
> 186a183
> > <!-- Automatically configure pools. Alternatively, max-pool-size can be set to a specific value -->
> 193c190
> < <cache name="distributable" passivation-store-ref="infinispan" aliases="passivating clustered"/>
> ---
> > <cache name="distributable" aliases="passivating clustered" passivation-store-ref="infinispan"/>
> 220c217
> < <cache-container name="server" aliases="singleton cluster" module="org.wildfly.clustering.server" default-cache="default">
> ---
> > <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
> 226c223
> < <cache-container name="web" module="org.wildfly.clustering.web.infinispan" default-cache="dist">
> ---
> > <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
> 234c231
> < <cache-container name="ejb" aliases="sfsb" module="org.wildfly.clustering.ejb.infinispan" default-cache="dist">
> ---
> > <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
> 242c239
> < <cache-container name="hibernate" module="org.hibernate.infinispan" default-cache="local-query">
> ---
> > <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
> 244,247d240
> < <local-cache name="local-query">
> < <eviction max-entries="10000" strategy="LRU"/>
> < <expiration max-idle="100000"/>
> < </local-cache>
> 250c243
> < <eviction max-entries="10000" strategy="LRU"/>
> ---
> > <eviction strategy="LRU" max-entries="10000"/>
> 252a246,249
> > <local-cache name="local-query">
> > <eviction strategy="LRU" max-entries="10000"/>
> > <expiration max-idle="100000"/>
> > </local-cache>
> 403c400
> < <http-listener name="default" redirect-socket="https" socket-binding="http"/>
> ---
> > <http-listener name="default" socket-binding="http" redirect-socket="https"/>
> 418,419c415,416
> < <response-header name="server-header" header-value="WildFly/10" header-name="Server"/>
> < <response-header name="x-powered-by-header" header-value="Undertow/1" header-name="X-Powered-By"/>
> ---
> > <response-header name="server-header" header-name="Server" header-value="WildFly/10"/>
> > <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
> 434d430
> <
> 446d441
> <
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JGRP-2024) Receiving messages out of order.
by Dylan Turnbull (JIRA)
[ https://issues.jboss.org/browse/JGRP-2024?page=com.atlassian.jira.plugin.... ]
Dylan Turnbull commented on JGRP-2024:
--------------------------------------
I do agree, although I am a little bewildered. I had been using it the way I set it up in my test case, perhaps I was just getting lucky and the data was making it out before the buffer was overwritten.
Do you have any tips on how to improve performance? I'm finding it hard to push past 3Gbps...
> Receiving messages out of order.
> --------------------------------
>
> Key: JGRP-2024
> URL: https://issues.jboss.org/browse/JGRP-2024
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.7, 3.6.8
> Environment: RedHat 6.7
> Java 1.8.0 Update 45
> Reporter: Dylan Turnbull
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: jGroups Unit Test.zip, JGroupsMessageTest.java, jGroupsTestReciever.java
>
>
> After splitting a file into smaller messages and send them down the channel the messages are received on the other side out of order.
> Below is a sample output:
> *+On the sender:+*
> Sending...
> Data Sent:
> Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy te
> -----------------------------------------------------
> Data Sent:
> xt ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has sur
> -----------------------------------------------------
> Data Sent:
> vived not only five centuries, but also the leap into electronic typesetting, re
> -----------------------------------------------------
> Data Sent:
> d in the 1960s with the release of Letraset sheets containing Lorem Ipsum passag
> *+On the receiver:+*
> Listening...
> Data Received:
> xt ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has sur
> -----------------------------------------------------
> Data Received:
> vived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularise
> -----------------------------------------------------
> Data Received:
> d in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing so
> -----------------------------------------------------
> Data Received:
> ftware like Aldus PageMaker including versions of Lorem Ipsum.Lorem Ipsum passages, and more recently with desktop publishing so
> -----------------------------------------------------
> Data Received:
> ftware like Aldus PageMaker including versions of Lorem Ipsum.Lorem Ipsum passages, and more recently with desktop publishing so
> -----------------------------------------------------
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-4853) Provide two cluster test case for EJBClient
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-4853?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-4853:
-------------------------------------------
I have been looking at this test again. Found an issue with TransactionAttributes not getting picked up correctly in the managed transaction version of the test and fixed that. Updating the PR in the hope that it can be merged. The test seems to be much more stable than when first introduced.
> Provide two cluster test case for EJBClient
> -------------------------------------------
>
> Key: WFLY-4853
> URL: https://issues.jboss.org/browse/WFLY-4853
> Project: WildFly
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 10.0.0.Alpha4
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
>
> The Wildfly test suite is missing a test case for testing EJBClient interactions over two clusters, which does exist in the EAP test cycle. This test case aims to duplicate that multi-node SmartFrog test in the Wildfly testsuite so that errors are identified early.
> The test setup:
> - two clusters
> {noformat}
> ejb-forwarder = {node0, node1}
> ejb={node3, node4}
> {noformat}
> where each node of cluster ejb-forwarder has a remote outbound connection to node3
> - a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to cluster ejb
> - a non-forwarding deployment on cluster ejb
> - a client which makes invocations on the clustered deployment on ejb-forwarder every 10 ms
> The test execution:
> - once the servers and deployments have been deployed, each server is shut down and then restarted in turn, at which time the test ends.
> The expected behaviour:
> - at least 90% of client invocations will complete without exception
> - test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice versa, depending on which node of cluster ejb-forwarder is down)
> - server-client invocations on ejb will fail-over from node3 to node 4 (or vice versa depending on which node of cluster ejb is down)
> The invocation transaction attribute set up:
> - invocations from the client to ejb-forwarder are not in transaction scope
> - invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED
> This allows exercising invocations from a managed transaction context, which uncovered a number of issues...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1431) Look into loading Sasl providers on jigsaw
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1431?page=com.atlassian.jira.plugi... ]
Tomaz Cerar updated WFCORE-1431:
--------------------------------
Description:
With JDK9 jigsaw builds remoting and most tests related to it fail.
Problem is in org.xnio.sasl.SaslUtil.getFactories()
Which doesn't work correctly on Jigsaw as it prevents us form loading classes from java base image as they are not exported.
as workaround we have
{noformat}
-XaddExports:java.security.sasl/com.sun.security.sasl.digest=ALL-UNNAMED,java.security.sasl/com.sun.security.sasl=ALL-UNNAMED
{noformat}
but we should have proper solution.
was:
With JDK9 jigsaw builds remoting and most tests related to it fail.
Problem is in org.xnio.sasl.SaslUtil.getFactories()
Which doesn't work correctly on Jigsaw as it prevents us form loading classes from java base image as they are not exported.
as workaround we have
-XaddExports:java.security.sasl/com.sun.security.sasl.digest=ALL-UNNAMED,java.security.sasl/com.sun.security.sasl=ALL-UNNAMED
but we should have proper solution.
> Look into loading Sasl providers on jigsaw
> ------------------------------------------
>
> Key: WFCORE-1431
> URL: https://issues.jboss.org/browse/WFCORE-1431
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Remoting
> Affects Versions: 2.1.0.CR1
> Environment: JDK9 Jigsaw
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
>
> With JDK9 jigsaw builds remoting and most tests related to it fail.
> Problem is in org.xnio.sasl.SaslUtil.getFactories()
> Which doesn't work correctly on Jigsaw as it prevents us form loading classes from java base image as they are not exported.
> as workaround we have
> {noformat}
> -XaddExports:java.security.sasl/com.sun.security.sasl.digest=ALL-UNNAMED,java.security.sasl/com.sun.security.sasl=ALL-UNNAMED
> {noformat}
> but we should have proper solution.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1431) Look into loading Sasl providers on jigsaw
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFCORE-1431:
-----------------------------------
Summary: Look into loading Sasl providers on jigsaw
Key: WFCORE-1431
URL: https://issues.jboss.org/browse/WFCORE-1431
Project: WildFly Core
Issue Type: Sub-task
Components: Remoting
Affects Versions: 2.1.0.CR1
Environment: JDK9 Jigsaw
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
With JDK9 jigsaw builds remoting and most tests related to it fail.
Problem is in org.xnio.sasl.SaslUtil.getFactories()
Which doesn't work correctly on Jigsaw as it prevents us form loading classes from java base image as they are not exported.
as workaround we have
-XaddExports:java.security.sasl/com.sun.security.sasl.digest=ALL-UNNAMED,java.security.sasl/com.sun.security.sasl=ALL-UNNAMED
but we should have proper solution.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1079) Kie navigator cannot show organizational units content
by Robert (Bob) Brodt (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1079?page=com.atlassian.jira.plugi... ]
Robert (Bob) Brodt commented on DROOLS-1079:
--------------------------------------------
Sorry Thomas, I just found out that JBDSIS 9.1.0 does not contain the most recent build of droolsjbpm-tools. I will let Paul know to include it before the GA build.
> Kie navigator cannot show organizational units content
> ------------------------------------------------------
>
> Key: DROOLS-1079
> URL: https://issues.jboss.org/browse/DROOLS-1079
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Environment: JBoss Developer Studio 9.1.0.Beta2
> Drools plugin 6.4.0.201601201107
> Reporter: Tomas David
> Assignee: Robert (Bob) Brodt
> Priority: Blocker
> Labels: qe-recommend-fix-before-ga, reported-by-qe
> Attachments: server.log
>
>
> It is not possible to open organizational units and display associated repositories. Also when you create a new repository in org unit, it is not displayed in kie navigator but in business central app it is correctly created.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-3456) Can not call method with generic type parameter with null value
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-3456?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-3456:
------------------------------------
Farah, thank you very much! :-)
Big thanks to Trond also for fixing the WFLY-6280 issue! :-)
> Can not call method with generic type parameter with null value
> ---------------------------------------------------------------
>
> Key: WFLY-3456
> URL: https://issues.jboss.org/browse/WFLY-3456
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 8.1.0.Final
> Reporter: Marcel Neuwohner
> Assignee: Farah Juma
> Fix For: 9.0.0.Alpha1
>
>
> If you call a method with a generic type parameter from EL with null as parameter value you get
> {code}
> javax.el.MethodNotFoundException
> Unable to find unambiguous method: SimpleOrderHandler$Proxy$_$$_WeldClientProxy.getLastUpdate(null)
> at
> javax.el.Util.findWrapper(Util.java:322)
> javax.el.Util.findMethod(Util.java:203)
> javax.el.ELUtil.findMethod(ELUtil.java:288)
> javax.el.BeanELResolver.invoke(BeanELResolver.java:527)
> javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
> com.sun.el.parser.AstValue.getValue(AstValue.java:136)
> com.sun.el.parser.AstValue.getValue(AstValue.java:204)
> com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
> org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
> com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-3456) Can not call method with generic type parameter with null value
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3456?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-3456:
----------------------------------
Scott, just did a quick sanity test to verify that calling methods with a null parameter still works properly with the WFLY-6280 fix.
> Can not call method with generic type parameter with null value
> ---------------------------------------------------------------
>
> Key: WFLY-3456
> URL: https://issues.jboss.org/browse/WFLY-3456
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 8.1.0.Final
> Reporter: Marcel Neuwohner
> Assignee: Farah Juma
> Fix For: 9.0.0.Alpha1
>
>
> If you call a method with a generic type parameter from EL with null as parameter value you get
> {code}
> javax.el.MethodNotFoundException
> Unable to find unambiguous method: SimpleOrderHandler$Proxy$_$$_WeldClientProxy.getLastUpdate(null)
> at
> javax.el.Util.findWrapper(Util.java:322)
> javax.el.Util.findMethod(Util.java:203)
> javax.el.ELUtil.findMethod(ELUtil.java:288)
> javax.el.BeanELResolver.invoke(BeanELResolver.java:527)
> javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
> com.sun.el.parser.AstValue.getValue(AstValue.java:136)
> com.sun.el.parser.AstValue.getValue(AstValue.java:204)
> com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
> org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
> com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-5158) WARN ISPN000197: Error updating cluster member list at the boot up
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFLY-5158?page=com.atlassian.jira.plugin.... ]
Michal Vinkler updated WFLY-5158:
---------------------------------
Summary: WARN ISPN000197: Error updating cluster member list at the boot up (was: Execution error: org.infinispan.util.concurrent.TimeoutException: Replication timeout for node_name)
> WARN ISPN000197: Error updating cluster member list at the boot up
> ------------------------------------------------------------------
>
> Key: WFLY-5158
> URL: https://issues.jboss.org/browse/WFLY-5158
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Beta1, 10.0.0.CR2
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Fix For: 10.0.0.CR3
>
>
> Seen in ejb-ejbservlet and http-session scenarios intermittently (no matter what failover type or cache is used).
> When node perf18 is restarted after failover other servers log this error several times:
> {code}
> [JBossINF] [0m[31m16:11:43,595 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-107) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf18
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:752)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$6(JGroupsTransport.java:599)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$34/238012590.apply(Unknown Source)
> [JBossINF] at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF] at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF] at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.RspListFuture.timeout(RspListFuture.java:40)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$$Lambda$32/2073718099.run(Unknown Source)
> [JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
> In this particular test run, after perf18 restarted , perf19 logged the first error in 2 seconds, perf20 in 30 seconds, perf21 in 10 seconds.
> timeline:
> {code}
> perf18: [JBossINF] [0m[0m16:11:42,361 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta1) started in 20244ms - Started 747 of 993 services (424 services are lazy, passive or on-demand)
> perf19: [JBossINF] [0m[31m16:11:43,595 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-107) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf18
> perf20: [JBossINF] [0m[31m16:12:12,836 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-51) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf18
> perf21: [JBossINF] [0m[31m16:11:52,826 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-22) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf18
> {code}
> This error also intermittently appears after server is shutdown.
> Total number of errors for this particular test run: 1183
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month