[JBoss JIRA] (JGRP-1865) Test FORK and RELAY2
by Bela Ban (JIRA)
Bela Ban created JGRP-1865:
------------------------------
Summary: Test FORK and RELAY2
Key: JGRP-1865
URL: https://issues.jboss.org/browse/JGRP-1865
Project: JGroups
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.6
Test whether RELAY2 still works OK when placed over FORK. This combo will be used in WildFly 9.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JGRP-1863) Excessive dropped messages due to missing physical address
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-1863?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on JGRP-1863:
------------------------------------
I do think we will - since I plan to add FORK (whether implicitly or explicitly, I haven't decided) to our default stacks. RELAY2 is not in the default stacks, but our relay tests (which add it to the stack) should exercise the compatibility of the 2 when the time comes.
> Excessive dropped messages due to missing physical address
> ----------------------------------------------------------
>
> Key: JGRP-1863
> URL: https://issues.jboss.org/browse/JGRP-1863
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.5
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 3.5
>
>
> When running the x-site replication tests (and only those tests - the others run fine) from the clustering testsuite in WildFly against JGroups 3.5, I encounter failures due to:
> {noformat}
> 12:15:48,537 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site SFO: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from SFO (sync, timeout=10000)
> {noformat}
> The logs preceding this indicate the cause of the timeout:
> {noformat}
> 12:15:38,536 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(NYC), dropping message
> 12:15:38,536 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(SFO), dropping message
> 12:15:39,506 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(SFO), dropping message
> 12:15:39,507 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(NYC), dropping message
> {noformat}
> These messages repeat about 100 or so times over a period of 10 seconds.
> A little investigation reveals that the process for fetching physical addresses for a given logical destination address has changed. In 3.4, a given call to sendToSingleMember(...) would attempt to lookup the physical address by sending a Event.GET_PHYSICAL_ADDRESS up the stack and wait a predetermined period for a response. Any concurrent calls to sendToSingleMember(...) would also wait, but only one thread in a given time period would ever send the Event.GET_PHYSICAL_ADDRESS event up the stack.
> In 3.5 the process is different. In org.jgroups.protocols.TP, the FIND_MBRS event is used to lookup the phsyical addresses, instead of directly sending up a GET_PHYSICAL_ADDRESS event. However, looking at the implementation of the FIND_MBRS event handling within org.jgroups.protocols.Discovery, I see that this triggers a asynchronous GET_MBRS_REQ message. Since this message is sent asynchronously, this means that the response from the original FIND_MBRS event will most certainly be empty. Thus the thread that initiated the FIND_MBRS will most certainly log the PhysicalAddrMissing warning, as will any concurrent/subsequent calls to sendToSingleMember(...) for the same destination until that asynchronous processing completes. This is a departure from the logic in 3.4, where the thread initiating the physical address lookup would wait for some time for the address cache to be updated. I should think that the PhysicalAddrMissing warnings should stop once the original GET_MBRS_REQ message is handled, but that doesn't seem to be happening (hence the 100 or so sequential warning messages over a period of 10 seconds preceding the timeout log message from infinispan).
> Curiously, I see a org.jgroups.protocols.TP.setPingData(...) method, which seems to be responsible for populating the physical address cache from the FIND_MBRS event results from org.jgroups.protocols.Discovery - however, this method doesn't seem to be referenced anywhere. Might that be the source of the problem?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-838) Can't get implementing classname for JSR77 MBean
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-838?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on WFLY-838:
----------------------------------
Just waiting for your pull request :)
> Can't get implementing classname for JSR77 MBean
> ------------------------------------------------
>
> Key: WFLY-838
> URL: https://issues.jboss.org/browse/WFLY-838
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMX
> Reporter: Anders Welen
> Priority: Minor
> Fix For: Awaiting Volunteers
>
>
> The following exception are thrown when asking the MBean server for the classname implementing "jboss.jsr77:j2eeType=WebModule,name=MyWar.war,J2EEServer=default".
> It should be a legal call. Why are the code clearly states it's illegal?
>
> java.lang.IllegalStateException: JBAS019905: Should not get called
> at org.jboss.as.jsr77.managedobject.J2EEDeployedObjectHandlers$J2EEModuleHandler.queryObjectNames(J2EEDeployedObjectHandlers.java:245)
> at org.jboss.as.jsr77.managedobject.BaseHandler.getMBeanInfo(BaseHandler.java:64)
> at org.jboss.as.jsr77.managedobject.J2EEDeployedObjectHandlers.getMBeanInfo(J2EEDeployedObjectHandlers.java:147)
> at org.jboss.as.jsr77.managedobject.ManagedObjectHandlerRegistry.getMBeanInfo(ManagedObjectHandlerRegistry.java:112)
> at org.jboss.as.jsr77.subsystem.JSR77ManagementMBeanServer.getMBeanInfo(JSR77ManagementMBeanServer.java:179)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanInfo(PluggableMBeanServerImpl.java:212)
>
> The error can easily be triggered by using JConsole to browse the same MBean.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-838) Can't get implementing classname for JSR77 MBean
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/WFLY-838?page=com.atlassian.jira.plugin.s... ]
Rob Stryker commented on WFLY-838:
----------------------------------
Seems pretty silly that this still exists. It prevents anything traversing a jmx tree for a server from succeeding. Any chance of getting this fixed?
> Can't get implementing classname for JSR77 MBean
> ------------------------------------------------
>
> Key: WFLY-838
> URL: https://issues.jboss.org/browse/WFLY-838
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMX
> Reporter: Anders Welen
> Priority: Minor
> Fix For: Awaiting Volunteers
>
>
> The following exception are thrown when asking the MBean server for the classname implementing "jboss.jsr77:j2eeType=WebModule,name=MyWar.war,J2EEServer=default".
> It should be a legal call. Why are the code clearly states it's illegal?
>
> java.lang.IllegalStateException: JBAS019905: Should not get called
> at org.jboss.as.jsr77.managedobject.J2EEDeployedObjectHandlers$J2EEModuleHandler.queryObjectNames(J2EEDeployedObjectHandlers.java:245)
> at org.jboss.as.jsr77.managedobject.BaseHandler.getMBeanInfo(BaseHandler.java:64)
> at org.jboss.as.jsr77.managedobject.J2EEDeployedObjectHandlers.getMBeanInfo(J2EEDeployedObjectHandlers.java:147)
> at org.jboss.as.jsr77.managedobject.ManagedObjectHandlerRegistry.getMBeanInfo(ManagedObjectHandlerRegistry.java:112)
> at org.jboss.as.jsr77.subsystem.JSR77ManagementMBeanServer.getMBeanInfo(JSR77ManagementMBeanServer.java:179)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanInfo(PluggableMBeanServerImpl.java:212)
>
> The error can easily be triggered by using JConsole to browse the same MBean.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JGRP-1864) UDP unable to bind to ephemeral port: port out of range:65536
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1864?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1864:
---------------------------
Priority: Minor (was: Major)
> UDP unable to bind to ephemeral port: port out of range:65536
> -------------------------------------------------------------
>
> Key: JGRP-1864
> URL: https://issues.jboss.org/browse/JGRP-1864
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> It looks like {{UDP.createEphemeralDatagramSocket()}} swallows any errors it gets while creating the socket, and throws this exception after trying to bind to all ports in the 0 - 65535 range:
> {noformat}
> java.lang.IllegalArgumentException: port out of range:65536
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185)
> at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
> at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62)
> at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:311)
> at org.jgroups.protocols.UDP.start(UDP.java:216)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:547)
> at org.jgroups.JChannel.connect(JChannel.java:282)
> at org.jgroups.JChannel.connect(JChannel.java:273)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3670) Flag modules to be loaded in a distinct classloader context
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-3670?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-3670:
-----------------------------------
What is really being asked here is one of two things:
* Allow absolute paths for resource roots in jboss-deployment-structure.xml
* Allow a new kind of class path reference wherein the classes are duplicated rather than referenced
Other application servers work in this mode (copying classes for each deployment), so it is an aid to migration to be able to use the same behavior, even if it is very suboptimal in other respects.
That said I think the first solution is the simplest.
> Flag modules to be loaded in a distinct classloader context
> -----------------------------------------------------------
>
> Key: WFLY-3670
> URL: https://issues.jboss.org/browse/WFLY-3670
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Wolf-Dieter Fink
> Assignee: Jason Greene
>
> For some use-cases it will be helpful to have a module in a separate classloader (as copy) if it is used from different applications.
> An example is if the module includes classes which follow the singleton pattern but the singleton should be per application instead of instance wide.
> There are two possiblities to flag that
> - within the module.xml
> - within the module reference MAIFEST or jboss-deployment-structure.xml
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JGRP-1864) UDP unable to bind to ephemeral port: port out of range:65536
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/JGRP-1864?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on JGRP-1864:
------------------------------------
In this case, I think the problem was the open files limit was too low.
But I can't find the real failure message in the logs: all I have is the irrelevant "port out of range:" message.
> UDP unable to bind to ephemeral port: port out of range:65536
> -------------------------------------------------------------
>
> Key: JGRP-1864
> URL: https://issues.jboss.org/browse/JGRP-1864
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.4.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> It looks like {{UDP.createEphemeralDatagramSocket()}} swallows any errors it gets while creating the socket, and throws this exception after trying to bind to all ports in the 0 - 65535 range:
> {noformat}
> java.lang.IllegalArgumentException: port out of range:65536
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185)
> at java.net.DatagramSocket.<init>(DatagramSocket.java:284)
> at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62)
> at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:311)
> at org.jgroups.protocols.UDP.start(UDP.java:216)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:547)
> at org.jgroups.JChannel.connect(JChannel.java:282)
> at org.jgroups.JChannel.connect(JChannel.java:273)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3607) jsr356: OnError always called on page reload
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3607?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3607:
------------------------------
Description:
When I reload (F5) with Chrome, any jsr356's Handler will be called with
{noformat}
11:24:30,815 ERROR [org.atmosphere.container.JSR356Endpoint] (default I/O-3) : java.nio.channels.ClosedChannelException
at io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:260)
at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:20)
at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:632)
at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:618)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
{noformat}
Tomcat and Jetty won't invoke onError, so I'm curious to learn why Wildfly call onError.
was:
When I reload (F5) with Chrome, any jsr356's Handler will be called with
{noformat}
11:24:30,815 ERROR [org.atmosphere.container.JSR356Endpoint] (default I/O-3) : java.nio.channels.ClosedChannelException
at io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:260)
at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:20)
at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:632)
at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:618)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
{noformal}
Tomcat and Jetty won't invoke onError, so I'm curious to learn why Wildfly call onError.
> jsr356: OnError always called on page reload
> --------------------------------------------
>
> Key: WFLY-3607
> URL: https://issues.jboss.org/browse/WFLY-3607
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Jeanfrancois Arcand
> Assignee: Stuart Douglas
> Priority: Minor
>
> When I reload (F5) with Chrome, any jsr356's Handler will be called with
> {noformat}
> 11:24:30,815 ERROR [org.atmosphere.container.JSR356Endpoint] (default I/O-3) : java.nio.channels.ClosedChannelException
> at io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:260)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:20)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:632)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:618)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> {noformat}
> Tomcat and Jetty won't invoke onError, so I'm curious to learn why Wildfly call onError.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3607) jsr356: OnError always called on page reload
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3607?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-3607:
---------------------------------
Assignee: Stuart Douglas (was: Jason Greene)
> jsr356: OnError always called on page reload
> --------------------------------------------
>
> Key: WFLY-3607
> URL: https://issues.jboss.org/browse/WFLY-3607
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Jeanfrancois Arcand
> Assignee: Stuart Douglas
> Priority: Minor
>
> When I reload (F5) with Chrome, any jsr356's Handler will be called with
> {noformat}
> 11:24:30,815 ERROR [org.atmosphere.container.JSR356Endpoint] (default I/O-3) : java.nio.channels.ClosedChannelException
> at io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:260)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:20)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:632)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:618)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> {noformal}
> Tomcat and Jetty won't invoke onError, so I'm curious to learn why Wildfly call onError.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months