June 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1931) Don't drop UNICAST3 message when the window is not created

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1931?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1931: -------------------------------- What's the use case here ? The {{DONT_BUNDLE}} flag should be used sparingly and is actually ignored unless coupled with {{OOB}}. Note that only a few internal JGroups messages use {{DONT_BUNDLE, OOB}}. > Don't drop UNICAST3 message when the window is not created > ----------------------------------------------------------- > > Key: JGRP-1931 > URL: https://issues.jboss.org/browse/JGRP-1931 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.3 > Reporter: Radim Vansa > Assignee: Bela Ban > Fix For: 3.6.4 > > > When an application sends first two (or more) messages in parallel and the the second one is marked as DONT_BUNDLE, usually this one arrives as the first one and is dropped (see https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...). After first message arrives, the connection is properly set up, but we need to wait until retransmission for the message (and other non-OOB) messages to be delivered. > In practice this behaviour should be acceptable, but it causes failures in some time-sensitive tests (particularly in Hibernate ORM 2nd level cache). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1931) Don't drop UNICAST3 message when the window is not created

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1931?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1931: -------------------------------- This is needed to know the lowest seqno of the sender. E.g. if we have sender A and receiver B, and A sends messages 25(first) and 26, and 26 is received first, then we don't know which seqno to use to to create the Table for A. It isn't 26, but we don't know that it's 25 just yet, until we've received 25. We also cannot create each table with seqno 1, as the B might have closed its connection to A and therefore removed the table for A. > Don't drop UNICAST3 message when the window is not created > ----------------------------------------------------------- > > Key: JGRP-1931 > URL: https://issues.jboss.org/browse/JGRP-1931 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.3 > Reporter: Radim Vansa > Assignee: Bela Ban > Fix For: 3.6.4 > > > When an application sends first two (or more) messages in parallel and the the second one is marked as DONT_BUNDLE, usually this one arrives as the first one and is dropped (see https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...). After first message arrives, the connection is properly set up, but we need to wait until retransmission for the message (and other non-OOB) messages to be delivered. > In practice this behaviour should be acceptable, but it causes failures in some time-sensitive tests (particularly in Hibernate ORM 2nd level cache). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1925) support ipv6 in FixedMembershipToken

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1925?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1925. ---------------------------- Resolution: Done [~bbissett] Let me know if this fixes your issue and reopen with a use case if it doesn't. Cheers, > support ipv6 in FixedMembershipToken > ------------------------------------ > > Key: JGRP-1925 > URL: https://issues.jboss.org/browse/JGRP-1925 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.6.3 > Reporter: Robert Bissett > Assignee: Bela Ban > Fix For: 3.6.4 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1925) support ipv6 in FixedMembershipToken

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1925?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1925 at 6/16/15 7:49 AM: --------------------------------------------------------- I fixed this by parsing {{memberList}} into a list of {{InetSocketAddresses}} and comparing the sender of a message to the list. If we have ADDR:0, then ADDR has to match only (not the port), if we have ADDR:PORT, then both have to match. The test is in {{AUTHTest}}. was (Author: belaban): I fixed this by paring `memberList` into a list of `InetSocketAddresses` and comparing the sender of a message to the list. If we have ADDR:0, then ADDR has to match only (not the port), if we have ADDR:PORT, then both have to match. The test is in `AUTHTest`. > support ipv6 in FixedMembershipToken > ------------------------------------ > > Key: JGRP-1925 > URL: https://issues.jboss.org/browse/JGRP-1925 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.6.3 > Reporter: Robert Bissett > Assignee: Bela Ban > Fix For: 3.6.4 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1925) support ipv6 in FixedMembershipToken

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1925?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1925: -------------------------------- I fixed this by paring `memberList` into a list of `InetSocketAddresses` and comparing the sender of a message to the list. If we have ADDR:0, then ADDR has to match only (not the port), if we have ADDR:PORT, then both have to match. The test is in `AUTHTest`. > support ipv6 in FixedMembershipToken > ------------------------------------ > > Key: JGRP-1925 > URL: https://issues.jboss.org/browse/JGRP-1925 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.6.3 > Reporter: Robert Bissett > Assignee: Bela Ban > Fix For: 3.6.4 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4787) Shutdown error in domain mode

by Harald Wellmann (JIRA)

Harald Wellmann created WFLY-4787: ------------------------------------- Summary: Shutdown error in domain mode Key: WFLY-4787 URL: https://issues.jboss.org/browse/WFLY-4787 Project: WildFly Issue Type: Bug Components: Domain Management Affects Versions: 9.0.0.CR2 Environment: Ubuntu 14.04 LTS, Oracle JDK 1.8.0_45 Reporter: Harald Wellmann Assignee: Brian Stansberry h3. Scenario * Download and unpack wildfly-dist-9.0.0.CR2.zip. * Run bin/domain.sh and wait for servers to start. * Hit Ctrl-C. h3. Problem The following error message appears for each configured server: {noformat} [Server:server-one] 13:10:34,966 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 30) WFLYCTL0190: Step handler org.jboss.as.server.operations.ServerDomainProcessShutdownHandler$1@25f7734b for operation {"operation" => "shutdown","address" => [],"operation-id" => -1,"timeout" => -1} at address [] failed handling operation rollback -- org.jboss.msc.service.ServiceNotFoundException: Service service jboss.server.graceful-shutdown-service not found: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.server.graceful-shutdown-service not found [Server:server-one] at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:669) [Server:server-one] at org.jboss.as.controller.OperationContextImpl$OperationContextServiceRegistry.getRequiredService(OperationContextImpl.java:2013) [Server:server-one] at org.jboss.as.server.operations.ServerDomainProcessShutdownHandler$1$1.handleResult(ServerDomainProcessShutdownHandler.java:102) [Server:server-one] at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1401) [Server:server-one] at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1381) [Server:server-one] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1332) [Server:server-one] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1292) [Server:server-one] at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1180) [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:937) [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:885) [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601) [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354) [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330) [Server:server-one] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1183) [Server:server-one] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362) [Server:server-one] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:218) [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:234) [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:174) [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:137) [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:133) [Server:server-one] at java.security.AccessController.doPrivileged(Native Method) [Server:server-one] at javax.security.auth.Subject.doAs(Subject.java:360) [Server:server-one] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81) [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:153) [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:149) [Server:server-one] at java.security.AccessController.doPrivileged(Native Method) [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:149) [Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:298) [Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [Server:server-one] at java.lang.Thread.run(Thread.java:745) [Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320) {noformat} Tried on two different machines, both with Java 7 and Java 8. Also occurs with 9.0.0.CR1. Does not occur with 8.2.0.Final. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-762) Proper descriptions for the profile clone op

by Kabir Khan (JIRA)

Kabir Khan created WFCORE-762: --------------------------------- Summary: Proper descriptions for the profile clone op Key: WFCORE-762 URL: https://issues.jboss.org/browse/WFCORE-762 Project: WildFly Core Issue Type: Feature Request Components: Domain Management Reporter: Kabir Khan Assignee: Kabir Khan Fix For: 2.0.0.Alpha5 [11:52] Heiko Braun: @KabirKhan the clone op still has a foobar description: "description" => "Foobar", @KabirKhan same for the op parameter -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-761) Not possible to overlay non existing file in WAR

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFCORE-761?page=com.atlassian.jira.plugin... ] Bartosz Baranowski updated WFCORE-761: -------------------------------------- Description: It is either bug in how deployments are treated or how overlay/vfs work. Steps to reproduce: 1. deploy undexploded war with jar inside 2. add overlay that will add non existing file in jar Result: exception: Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay WEB-INF/lib/overlayed.jar//META-INF/x/file.txt at WEB-INF/lib/overlayed.jar//META-INF/x/file.txt Caused by: java.io.FileNotFoundException: /content/shell.war/WEB-INF/lib/overlayed.jar/META-INF/x/file.txt"}} at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:67) at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:37) at org.jboss.as.test.integration.deployment.deploymentoverlay.jar.OverlayUtils.setupOverlay(OverlayUtils.java:76) at org.jboss.as.test.integration.deployment.deploymentoverlay.war.OverlayNonExistingResourceTestCase.testOverlay(OverlayNonExistingResourceTestCase.java:67) Expectation: should work. It actually does work, if war is really exploded or 'if(exploded)' part in overlay is removed from overlay processor and everything is handled via: https://github.com/stuartwdouglas/wildfly-core/blob/a75af9118c4062fafb899... was: It is either bug in how deployments are treated or how overlay/vfs work. Steps to reproduce: 1. deploy undexploded war with jar inside 2. add overlay that will add non existing file in jar Result: exception: Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay WEB-INF/lib/overlayed.jar//META-INF/x/file.txt at WEB-INF/lib/overlayed.jar//META-INF/x/file.txt Caused by: java.io.FileNotFoundException: /content/shell.war/WEB-INF/lib/overlayed.jar/META-INF/x/file.txt"}} at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:67) at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:37) at org.jboss.as.test.integration.deployment.deploymentoverlay.jar.OverlayUtils.setupOverlay(OverlayUtils.java:76) at org.jboss.as.test.integration.deployment.deploymentoverlay.war.OverlayNonExistingResourceTestCase.testOverlay(OverlayNonExistingResourceTestCase.java:67) Expectation: should work. It actually does work, if war is really exploded or 'if(exploded)' part in overlay is removed from overlay processor. > Not possible to overlay non existing file in WAR > ------------------------------------------------ > > Key: WFCORE-761 > URL: https://issues.jboss.org/browse/WFCORE-761 > Project: WildFly Core > Issue Type: Feature Request > Reporter: Bartosz Baranowski > Priority: Minor > > It is either bug in how deployments are treated or how overlay/vfs work. > Steps to reproduce: > 1. deploy undexploded war with jar inside > 2. add overlay that will add non existing file in jar > Result: exception: > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay WEB-INF/lib/overlayed.jar//META-INF/x/file.txt at WEB-INF/lib/overlayed.jar//META-INF/x/file.txt > Caused by: java.io.FileNotFoundException: /content/shell.war/WEB-INF/lib/overlayed.jar/META-INF/x/file.txt"}} > at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:67) > at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:37) > at org.jboss.as.test.integration.deployment.deploymentoverlay.jar.OverlayUtils.setupOverlay(OverlayUtils.java:76) > at org.jboss.as.test.integration.deployment.deploymentoverlay.war.OverlayNonExistingResourceTestCase.testOverlay(OverlayNonExistingResourceTestCase.java:67) > Expectation: > should work. It actually does work, if war is really exploded or > 'if(exploded)' part in overlay is removed from overlay processor and everything is handled via: https://github.com/stuartwdouglas/wildfly-core/blob/a75af9118c4062fafb899... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4786) Clustering integration tests fails once -Dnode0 and -Dnode1 are used

by Petr Kremensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-4786?page=com.atlassian.jira.plugin.... ] Petr Kremensky moved JBEAP-323 to WFLY-4786: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-4786 (was: JBEAP-323) Workflow: GIT Pull Request workflow (was: CDW v1) Affects Version/s: 10.0.0.Alpha3 (was: EAP 7.0.0.DR4) Component/s: Clustering Test Suite (was: Clustering) (was: Testsuite) Target Release: (was: EAP 7.0.0.GA) > Clustering integration tests fails once -Dnode0 and -Dnode1 are used > -------------------------------------------------------------------- > > Key: WFLY-4786 > URL: https://issues.jboss.org/browse/WFLY-4786 > Project: WildFly > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: 10.0.0.Alpha3 > Reporter: Petr Kremensky > Assignee: Paul Ferraro > Attachments: results.zip > > > Tests from wildfly-ts-integ-clustering module fails once we change default binding interfaces by -Dnode0 and -Dnode1 properties. > See https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-as-testsuite-... > * build 5 binds to localhost (no -Dnode*) > * build 6 uses -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 > Similar failures were addressed for EAP 6 by https://bugzilla.redhat.com/show_bug.cgi?id=1076015 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4229) Make http status return while deploying configurable

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-4229?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski reassigned WFLY-4229: ---------------------------------------- Assignee: Tomaz Cerar (was: Bartosz Baranowski) > Make http status return while deploying configurable > ---------------------------------------------------- > > Key: WFLY-4229 > URL: https://issues.jboss.org/browse/WFLY-4229 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 9.0.0.Final, 10.0.0.Alpha4 > > > For deployment behind proxies it would be more than welcome to have server return 503 instead of 404 while application is deploying. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2015