[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
[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
[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
[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
[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
[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