[JBoss JIRA] (WFLY-3173) Default number of DIST owners is too conservative
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3173?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reassigned WFLY-3173:
------------------------------------
Assignee: Radoslav Husar (was: Paul Ferraro)
> Default number of DIST owners is too conservative
> -------------------------------------------------
>
> Key: WFLY-3173
> URL: https://issues.jboss.org/browse/WFLY-3173
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
>
> WildFly uses DIST by default using 4 owners, which is too conservative. I think we should lower this default value to 2, which is Infinispan's default value. We'll get a nice performance bump too.
> Don't forget to create transformers to handle the default value change for old model versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (WFLY-3173) Default number of DIST owners is too conservative
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-3173:
----------------------------------
Summary: Default number of DIST owners is too conservative
Key: WFLY-3173
URL: https://issues.jboss.org/browse/WFLY-3173
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 8.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
WildFly uses DIST by default using 4 owners, which is too conservative. I think we should lower this default value to 2, which is Infinispan's default value. We'll get a nice performance bump too.
Don't forget to create transformers to handle the default value change for old model versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (WFLY-3087) Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3087:
-----------------------------------
There ware many changes in work for 8.0.1 coming up soon,
can you test it if it is fixed there? you can grab nightly build at https://community.jboss.org/thread/224262
> Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3087
> URL: https://issues.jboss.org/browse/WFLY-3087
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: windows server 2008
> Reporter: Admin FlirtyMob
> Assignee: Stuart Douglas
> Fix For: 8.0.1.Final
>
>
> 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JGRP-1815) TP: sending a message to a non-existent physical address takes too much time
by Bela Ban (JIRA)
Bela Ban created JGRP-1815:
------------------------------
Summary: TP: sending a message to a non-existent physical address takes too much time
Key: JGRP-1815
URL: https://issues.jboss.org/browse/JGRP-1815
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5
When sending a message in the transport, e.g. a message batch, and one or more destinations have no physical addresses in {{logical_addr_cache}}, then we loop {{physical_addr_max_fetch_attempts}} (default: 3) times and also sleep a random number of ms (in range [1..500]).
This delays the sending of other messages in the same batch, or of other messages in general. Also, if TransferQueueBundler is used, the transfer queue might get filled, so other sender threads are blocked.
SOLUTION:
* Remove the loop when sending a message: if the physical address for a message is not found, simply send a discovery request and drop the message
* The discovery request needs to be sent on a separate thread, as calling {{up(Event)}} directly could also delay the sending of the message or message batch.
* JGRP-1814 will also help, as connections to left members are closed, and therefore not finding a physical address for a destination should be rare
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (WFLY-3087) Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
by Frank Hempel (JIRA)
[ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.... ]
Frank Hempel commented on WFLY-3087:
------------------------------------
It can be reproduced. All you have to do is don't implement the binaryMessage()-handler in the WebSocket endpoint class. Then the binaryMessage attribute of the AnnotatedEndpoint object is null which is not tested in the handleBinaryMessage method. Anyway, the result at clients would always be the same: no handler -> no action ;)
> Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3087
> URL: https://issues.jboss.org/browse/WFLY-3087
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: windows server 2008
> Reporter: Admin FlirtyMob
> Assignee: Stuart Douglas
> Fix For: 8.0.1.Final
>
>
> 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76)
> at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (WFLY-2632) JGroups drops unicast messages after shutdown/restart
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-2632?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated WFLY-2632:
--------------------------------------
Fix Version/s: 8.0.1.Final
> JGroups drops unicast messages after shutdown/restart
> -----------------------------------------------------
>
> Key: WFLY-2632
> URL: https://issues.jboss.org/browse/WFLY-2632
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 8.0.1.Final
>
>
> JGroups drops unicast messages (citing wrong destination) after a node in a cluster is shutdown and then restarted.
> The JGroups version in use is 3.4.1.Final.
> Steps to reproduce:
> - start two nodes A, B using the server configuration standalone-ha.xml to create a cluster
> - shutdown A
> - restart A
> - after restart, we see these messages:
> {noformat}
> 13:15:03,227 INFO [stdout] (ServerService Thread Pool -- 63)
> 13:15:03,228 INFO [stdout] (ServerService Thread Pool -- 63) -------------------------------------------------------------------
> 13:15:03,228 INFO [stdout] (ServerService Thread Pool -- 63) GMS: address=lenovo/web, cluster=web, physical address=127.0.0.1:55200
> 13:15:03,229 INFO [stdout] (ServerService Thread Pool -- 63) -------------------------------------------------------------------
> 13:15:03,414 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000094: Received new cluster view: [fred/
> web|3] (2) [fred/web, lenovo/web]
> 13:15:03,422 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000079: Cache local address is lenovo/web
> , physical addresses are [127.0.0.1:55200]
> 13:15:03,427 INFO [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 63) ISPN000128: Infinispan version: Infinispan 'Infinium' 6
> .0.0.CR1
> 13:15:03,533 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5
> -f005-ddb2-b377-46b165e2aa77
> 13:15:03,609 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 61) ISPN000031: MBeans were successfully registered to the platform
> MBean server.
> 13:15:03,610 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 62) ISPN000031: MBeans were successfully registered to the platform
> MBean server.
> 13:15:03,765 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 62) JBAS010281: Started default-host/distributable cache from web contain
> er
> 13:15:03,768 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 61) JBAS010281: Started dist cache from web container
> 13:15:03,906 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017534: Register web context: /distributable
> 13:15:03,978 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "distributable.war" (runtime-name : "distributable.war")
> 13:15:04,033 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5
> -f005-ddb2-b377-46b165e2aa77
> 13:15:04,059 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 13:15:04,060 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 13:15:04,060 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Beta2-SNAPSHOT "WildFly" started in 5193ms - Started 293 of 410 services (178 services are lazy, passive or on-demand)
> 13:15:04,533 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> 13:15:05,034 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> 13:15:05,534 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> {noformat}
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (WFLY-3168) Wrong Mojarra version on Linux
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3168?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-3168:
----------------------------------
Are you sure you're running the same version of WildFly on both Linux and Windows? WildFly 8 Final only contains Mojarra 2.2.5 (the Mojarra jar is in the modules/system/layers/base/com/sun/jsf-impl/main directory). Mojarra 2.1.7 hasn't been included in the modules/com/sun/jsf-impl directory since AS 7.1.1.Final.
> Wrong Mojarra version on Linux
> ------------------------------
>
> Key: WFLY-3168
> URL: https://issues.jboss.org/browse/WFLY-3168
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.Final
> Environment: Linux
> Reporter: Thorsten Richter
> Assignee: Farah Juma
> Labels: jsf, linux, mojarra, viewscoped
>
> We had a bug on Linux that the @ViewScoped annotation didn't work for AJAX requests. We found out, that the Mojarra version is causing the problem. On our Windows development machines everything worked fine, but on the Linux production server @ViewScoped didn't work.
> So we searched for the root cause and found out, that the Mojarra version was different on Linux.
> The Linux package of Wildfly contains an older version of Mojarra (2.1.7) within the modules/com/sun/jsf-impl folder that needs to be deleted.
> The Windows package of Wildfly doesn't even contain a com folder within modules.
> So maybe the whole com folder on Linux is wrong?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month