[JBoss JIRA] (WFLY-4799) cancelled ejb timers persist in data/timer-service-data
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-4799?page=com.atlassian.jira.plugin.... ]
jaikiran pai reassigned WFLY-4799:
----------------------------------
Assignee: jaikiran pai
> cancelled ejb timers persist in data/timer-service-data
> -------------------------------------------------------
>
> Key: WFLY-4799
> URL: https://issues.jboss.org/browse/WFLY-4799
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.CR2
> Environment: linux 4.0.4-303.fc22.x86_64, java jdk1.8.0_45 and wildfly-9.0.0.CR2
> Reporter: John Whitley
> Assignee: jaikiran pai
> Labels: jboss
> Attachments: timertest.tgz
>
>
> I have a Singleton bean which creates a ejb.timer on deployment. Before doing so it cancels any existing timers previously created by the bean for completeness.
> In wildfly 8 the cancelled timers were removed from data/timer-service-data/'bean'. In wildfly 9 CR2, they stay in data/timer-service-data/'bean' and appear to be re-instated on re-deployment
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (JGRP-1927) RELAY2: Delays during shutdown
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1927?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1927:
--------------------------------
No, RELAY2 won't resend {{m}}. But this can also happen when {{A}} crashes, before {{B}} takes over as site master, so Infinispan has to be prepared to re-invoke a {{REPLICATE}} RPC anyways...
> RELAY2: Delays during shutdown
> ------------------------------
>
> Key: JGRP-1927
> URL: https://issues.jboss.org/browse/JGRP-1927
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.6.2
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.6.4
>
>
> Say we have 2 clusters connected via RELAY2, AB and CD. A is the site master of AB, C is the site master of CD, and A is the coordinator of the bridge cluster.
> When node A is stopped, it first leaves the AB cluster, and then the bridge cluster. When B receives the new B view, it tries to join the bridge cluster. But because RELAY2 hasn't yet finished stopping the relay channel on A, B still sees A as the coordinator of the bridge channel, and sends the JOIN_REQ message to it.
> The bridge channel stops on A before receiving B's join response, so B won't receive any response and will eventually time out. If the user tries to stop node B, it will block waiting for the JChannel lock:
> {noformat}
> "testng@1" prio=5 tid=0x1 nid=NA waiting for monitor entry
> java.lang.Thread.State: BLOCKED
> waiting for Incoming-1,NodeB@2894 to release lock on <0xd26> (a org.jgroups.JChannel)
> at org.jgroups.JChannel.close(JChannel.java:385)
> at org.jgroups.util.Util.close(Util.java:408)
> at org.jgroups.protocols.relay.Relayer$Bridge.stop(Relayer.java:256)
> at org.jgroups.protocols.relay.Relayer.stop(Relayer.java:109)
> at org.jgroups.protocols.relay.RELAY2.stop(RELAY2.java:280)
> at org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:1015)
> at org.jgroups.JChannel.stopStack(JChannel.java:1003)
> at org.jgroups.JChannel.disconnect(JChannel.java:373)
> - locked <0xd54> (a org.jgroups.JChannel)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.stop(JGroupsTransport.java:262)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> "Incoming-1,B@2894" prio=5 tid=0x2f nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> blocks testng@1
> at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:114)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:44)
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1084)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:353)
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
> at org.jgroups.protocols.RSVP.down(RSVP.java:153)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1038)
> at org.jgroups.JChannel.down(JChannel.java:791)
> at org.jgroups.JChannel._connect(JChannel.java:564)
> at org.jgroups.JChannel.connect(JChannel.java:294)
> - locked <0xd26> (a org.jgroups.JChannel)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at org.jgroups.protocols.relay.Relayer$Bridge.start(Relayer.java:250)
> at org.jgroups.protocols.relay.Relayer.start(Relayer.java:86)
> at org.jgroups.protocols.relay.RELAY2.startRelayer(RELAY2.java:681)
> at org.jgroups.protocols.relay.RELAY2.handleView(RELAY2.java:663)
> at org.jgroups.protocols.relay.RELAY2.up(RELAY2.java:416)
> at org.jgroups.protocols.RSVP.up(RSVP.java:201)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:394)
> at org.jgroups.protocols.tom.TOA.up(TOA.java:121)
> at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:732)
> - locked <0xd2e> (a org.jgroups.protocols.pbcast.GMS)
> at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:146)
> {noformat}
>
> Ideally, I'd like B to realize that the coordinator of the bridge cluster has the same site id, and delay sending the join request until C becomes the coordinator. Failing that, maybe {{JChannel.stop}} could interrupt the thread doing the join?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (WFLY-4800) No reload required when add mime-mapping to servlet-container
by Jan Stourac (JIRA)
[ https://issues.jboss.org/browse/WFLY-4800?page=com.atlassian.jira.plugin.... ]
Jan Stourac updated WFLY-4800:
------------------------------
Attachment: simple-web.war
example war file to reproduce bug...
> No reload required when add mime-mapping to servlet-container
> -------------------------------------------------------------
>
> Key: WFLY-4800
> URL: https://issues.jboss.org/browse/WFLY-4800
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Alpha3
> Reporter: Jan Stourac
> Assignee: Stuart Douglas
> Attachments: simple-web.war
>
>
> When mime-mapping is added to servlet container then no reload of server is required, although change takes effect after server restart is performed.
> Expected behaivour is either that change takes effect immediatelly after configuration is changed or that server reload is required in response message and result of the operation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (WFLY-4800) No reload required when add mime-mapping to servlet-container
by Jan Stourac (JIRA)
[ https://issues.jboss.org/browse/WFLY-4800?page=com.atlassian.jira.plugin.... ]
Jan Stourac moved JBEAP-343 to WFLY-4800:
-----------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-4800 (was: JBEAP-343)
Workflow: GIT Pull Request workflow (was: CDW v1)
Affects Version/s: 10.0.0.Alpha3
(was: EAP 7.0.0.DR4)
Component/s: Web (Undertow)
(was: Web (Undertow))
Target Release: (was: EAP 7.0.0.GA)
> No reload required when add mime-mapping to servlet-container
> -------------------------------------------------------------
>
> Key: WFLY-4800
> URL: https://issues.jboss.org/browse/WFLY-4800
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Alpha3
> Reporter: Jan Stourac
> Assignee: Stuart Douglas
>
> When mime-mapping is added to servlet container then no reload of server is required, although change takes effect after server restart is performed.
> Expected behaivour is either that change takes effect immediatelly after configuration is changed or that server reload is required in response message and result of the operation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (JGRP-1927) RELAY2: Delays during shutdown
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/JGRP-1927?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on JGRP-1927:
------------------------------------
Let's say A leaves the relay cluster first, then B tries to send a message {{m}} to the backup site, and then A leaves the local cluster. When B then becomes coordinator of the local cluster and site master, will RELAY2 on B pick up {{m}} and send it to the backup site?
If B resends {{m}}, everything should be fine. But if B doesn't resend {{m}}, we'll eventually get a {{TimeoutException}} in Infinispan and we won't retry, so that wouldn't work for us.
> RELAY2: Delays during shutdown
> ------------------------------
>
> Key: JGRP-1927
> URL: https://issues.jboss.org/browse/JGRP-1927
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.6.2
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.6.4
>
>
> Say we have 2 clusters connected via RELAY2, AB and CD. A is the site master of AB, C is the site master of CD, and A is the coordinator of the bridge cluster.
> When node A is stopped, it first leaves the AB cluster, and then the bridge cluster. When B receives the new B view, it tries to join the bridge cluster. But because RELAY2 hasn't yet finished stopping the relay channel on A, B still sees A as the coordinator of the bridge channel, and sends the JOIN_REQ message to it.
> The bridge channel stops on A before receiving B's join response, so B won't receive any response and will eventually time out. If the user tries to stop node B, it will block waiting for the JChannel lock:
> {noformat}
> "testng@1" prio=5 tid=0x1 nid=NA waiting for monitor entry
> java.lang.Thread.State: BLOCKED
> waiting for Incoming-1,NodeB@2894 to release lock on <0xd26> (a org.jgroups.JChannel)
> at org.jgroups.JChannel.close(JChannel.java:385)
> at org.jgroups.util.Util.close(Util.java:408)
> at org.jgroups.protocols.relay.Relayer$Bridge.stop(Relayer.java:256)
> at org.jgroups.protocols.relay.Relayer.stop(Relayer.java:109)
> at org.jgroups.protocols.relay.RELAY2.stop(RELAY2.java:280)
> at org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:1015)
> at org.jgroups.JChannel.stopStack(JChannel.java:1003)
> at org.jgroups.JChannel.disconnect(JChannel.java:373)
> - locked <0xd54> (a org.jgroups.JChannel)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.stop(JGroupsTransport.java:262)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> "Incoming-1,B@2894" prio=5 tid=0x2f nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> blocks testng@1
> at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:114)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:44)
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1084)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:353)
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
> at org.jgroups.protocols.RSVP.down(RSVP.java:153)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1038)
> at org.jgroups.JChannel.down(JChannel.java:791)
> at org.jgroups.JChannel._connect(JChannel.java:564)
> at org.jgroups.JChannel.connect(JChannel.java:294)
> - locked <0xd26> (a org.jgroups.JChannel)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at org.jgroups.protocols.relay.Relayer$Bridge.start(Relayer.java:250)
> at org.jgroups.protocols.relay.Relayer.start(Relayer.java:86)
> at org.jgroups.protocols.relay.RELAY2.startRelayer(RELAY2.java:681)
> at org.jgroups.protocols.relay.RELAY2.handleView(RELAY2.java:663)
> at org.jgroups.protocols.relay.RELAY2.up(RELAY2.java:416)
> at org.jgroups.protocols.RSVP.up(RSVP.java:201)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:394)
> at org.jgroups.protocols.tom.TOA.up(TOA.java:121)
> at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:732)
> - locked <0xd2e> (a org.jgroups.protocols.pbcast.GMS)
> at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:146)
> {noformat}
>
> Ideally, I'd like B to realize that the coordinator of the bridge cluster has the same site id, and delay sending the join request until C becomes the coordinator. Failing that, maybe {{JChannel.stop}} could interrupt the thread doing the join?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (WFCORE-770) Introduce parameters object for AbstractAddStepHandler
by Kabir Khan (JIRA)
Kabir Khan created WFCORE-770:
---------------------------------
Summary: Introduce parameters object for AbstractAddStepHandler
Key: WFCORE-770
URL: https://issues.jboss.org/browse/WFCORE-770
Project: WildFly Core
Issue Type: Feature Request
Reporter: Kabir Khan
Fix For: 2.0.0.Alpha6
Similar to WFCORE-767, the constructors for AbstractAddStepHandler are getting quite convoluted.
Talking with Brian, we think the existing set of constructors are fine. They cover all the common cases, but make it hard to add more parameters. So we will introduce a Parameters object variant there as well, to support what is already there and to make adding new parameters easier as we go along.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (WFCORE-770) Introduce parameters object for AbstractAddStepHandler
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-770?page=com.atlassian.jira.plugin... ]
Kabir Khan reassigned WFCORE-770:
---------------------------------
Assignee: Kabir Khan
> Introduce parameters object for AbstractAddStepHandler
> ------------------------------------------------------
>
> Key: WFCORE-770
> URL: https://issues.jboss.org/browse/WFCORE-770
> Project: WildFly Core
> Issue Type: Feature Request
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 2.0.0.Alpha6
>
>
> Similar to WFCORE-767, the constructors for AbstractAddStepHandler are getting quite convoluted.
> Talking with Brian, we think the existing set of constructors are fine. They cover all the common cases, but make it hard to add more parameters. So we will introduce a Parameters object variant there as well, to support what is already there and to make adding new parameters easier as we go along.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (WFLY-4778) WebSocket connection failed because of Unexpected response code: 501
by Mike Mike (JIRA)
[ https://issues.jboss.org/browse/WFLY-4778?page=com.atlassian.jira.plugin.... ]
Mike Mike updated WFLY-4778:
----------------------------
Attachment: push-test.zip
I created the reproduce and within get a new strange behavior. The application deployment directly to wildfly works correctly and website starts as expected. Deployment by the eclipse connector works, but website is got stuck with the loading circle. After a while I get an widgetset exception.
However, here is my sample application. Use "mvn install" to build it.
> WebSocket connection failed because of Unexpected response code: 501
> --------------------------------------------------------------------
>
> Key: WFLY-4778
> URL: https://issues.jboss.org/browse/WFLY-4778
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Mike Mike
> Assignee: Stuart Douglas
> Attachments: push-test.zip
>
>
> I am trying to use Wilfly 9 RC with Vaadins Server Push. The Push works but I get always following message in the java script log:
> Vaadin push loaded
> vaadinPush.js:21 WebSocket connection to 'ws://localhost:8080/abc-ui/PUSH/?v-uiId=0&v-csrfToken=9592bfe8-549f-4713-85b4-8ddae0163407&X-Atmosphere-tracking-id=0&X-Atmosphere-Framework=2.0.3.vaadin2-jquery&X-Atmosphere-Transport=websocket&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application/json;%20charset=UTF-8' failed: Error during WebSocket handshake: Unexpected response code: 501
> vaadinPush.js:21 Websocket failed. Downgrading to Comet and resending
> The HTTP 501 (Not Implemented) is really irritating. Which side is implementing and who specifies?
> I found this topic related here: http://atmosphere-framework.2306103.n4.nabble.com/Websocket-Connection-Fa...
> Does anybody know here, if it is a bug in WildFly or atmosphere?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month