[JBoss JIRA] (WFLY-6636) WELD-001408: Unsatisfied dependencies on hot deploy of app using module-alias as dependency
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFLY-6636?page=com.atlassian.jira.plugin.... ]
Tomas Hofman commented on WFLY-6636:
------------------------------------
To me the first deployment always works, not matter if hot deployment or archive, and subsequent redeployments always fail, until the server is reloaded.
I think it's caused by the fact that ModuleLoader doesn't remove it's module entry for "deployment.ejb1" correctly, and this module entry then interferes with subsequent deployments. See MODULES-252 for details.
> WELD-001408: Unsatisfied dependencies on hot deploy of app using module-alias as dependency
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-6636
> URL: https://issues.jboss.org/browse/WFLY-6636
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Tomas Hofman
> Attachments: test.ear
>
>
> If a sub deployment uses another sub deployment's module-alias as a dependency, it will deploy successfully, but if hot deployed, it will fail with the error below. Attached reproducer.
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
> <ear-subdeployments-isolated>true</ear-subdeployments-isolated>
> <sub-deployment name="ejb1.jar">
> <module-alias name="deployment.ejb1"/>
> </sub-deployment>
> <sub-deployment name="ejb2.jar">
> <dependencies>
> <!-- works
> <module name="deployment.test.ear.ejb1.jar" slot="main"/>
> -->
> <!-- fails with WELD-001408: Unsatisfied dependencies for type TestEJB1 with qualifiers @Default on redeploy / hot deploy -->
> <module name="deployment.ejb1" slot="main"/>
> </dependencies>
> </sub-deployment>
> </jboss-deployment-structure>
> {code}
> {code}
> 10:43:42,140 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."test.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.ear".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type TestEJB1 with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private test.TestEJB2.test1
> at test.TestEJB2.test1(TestEJB2.java:0)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 10:43:42,144 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.ear\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.ear\".WeldStartService: Failed to start service
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type TestEJB1 with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private test.TestEJB2.test1
> at test.TestEJB2.test1(TestEJB2.java:0)
> "}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (JGRP-2073) RELAY with pbcast.NAKACK2 instead of pbcast.NAKACK in Stack is not functional
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2073?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2073:
---------------------------
Summary: RELAY with pbcast.NAKACK2 instead of pbcast.NAKACK in Stack is not functional (was: RELAY with pbcast.NAKACK2 instead of pbcast.NAKACK in Stack is not functiona)
> RELAY with pbcast.NAKACK2 instead of pbcast.NAKACK in Stack is not functional
> -----------------------------------------------------------------------------
>
> Key: JGRP-2073
> URL: https://issues.jboss.org/browse/JGRP-2073
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3, 3.4.3, 3.5, 3.6, 3.6.8, 3.6.9
> Environment: tested with windows7 64 bit; oracle java version 1.8.0_60 64bit
> Reporter: Roman Fischer
> Assignee: Bela Ban
>
> I have tested with the RelayDemo as the Description in the jgroups manual together with the udp.xml from the 3.6.9 jgroups Version.
> At the Moment if the bridge-cluster is aktiv, the system sent continuously null messages to all Members.
> if we replace pbcast.NAKACK2 with pbcast.NAKACK the demo is ok.
> So i have seen it is planned to remove NAKACK in the Future - i create this issue.
> Thanks for the nice software!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (JGRP-2073) RELAY with pbcast.NAKACK2 instead of pbcast.NAKACK in Stack is not functiona
by Roman Fischer (JIRA)
Roman Fischer created JGRP-2073:
-----------------------------------
Summary: RELAY with pbcast.NAKACK2 instead of pbcast.NAKACK in Stack is not functiona
Key: JGRP-2073
URL: https://issues.jboss.org/browse/JGRP-2073
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.9, 3.6.8, 3.6, 3.5, 3.4.3, 3.3
Environment: tested with windows7 64 bit; oracle java version 1.8.0_60 64bit
Reporter: Roman Fischer
Assignee: Bela Ban
I have tested with the RelayDemo as the Description in the jgroups manual together with the udp.xml from the 3.6.9 jgroups Version.
At the Moment if the bridge-cluster is aktiv, the system sent continuously null messages to all Members.
if we replace pbcast.NAKACK2 with pbcast.NAKACK the demo is ok.
So i have seen it is planned to remove NAKACK in the Future - i create this issue.
Thanks for the nice software!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (WFLY-6664) Clarify the differences between build/ and dist/ directories
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-6664?page=com.atlassian.jira.plugin.... ]
Ingo Weiss moved JBEAP-4794 to WFLY-6664:
-----------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6664 (was: JBEAP-4794)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Build System
(was: Build System)
Target Release: (was: 7.backlog.GA)
Affects Version/s: (was: 7.0.0.GA)
(was: 7.0.1.CR1)
> Clarify the differences between build/ and dist/ directories
> ------------------------------------------------------------
>
> Key: WFLY-6664
> URL: https://issues.jboss.org/browse/WFLY-6664
> Project: WildFly
> Issue Type: Enhancement
> Components: Build System
> Reporter: Ingo Weiss
> Assignee: Ingo Weiss
> Priority: Trivial
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> The {{build/}} and {{dist/}} directories are quite different and this need to be clarified.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (JGRP-2072) UFC and MFC headers get mixed up
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2072?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2072:
--------------------------------
OK, I'll change that manually
> UFC and MFC headers get mixed up
> --------------------------------
>
> Key: JGRP-2072
> URL: https://issues.jboss.org/browse/JGRP-2072
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.9
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.6.10, 4.0
>
>
> {noformat}
> 11:24:19,178 TRACE (OOB-10,NodeD-30623:[]) [MFC] NodeA-6644 used 4969 credits, 396763 remaining
> 11:24:19,238 TRACE (OOB-10,NodeD-30623:[]) [MFC] sending 603237 credits to NodeA-6644
> 11:24:19,238 TRACE (OOB-10,NodeD-30623:[]) [UDP] NodeD-30623: sending msg to NodeA-6644, src=NodeD-30623, headers are MFC: REPLENISH, UNICAST3: DATA, seqno=8825, TP: [cluster_name=default]
> 11:24:19,246 TRACE (INT-1,NodeA-6644:[]) [UDP] NodeA-6644: received [dst: NodeA-6644, src: NodeD-30623 (3 headers), size=8 bytes, flags=OOB|DONT_BUNDLE|INTERNAL], headers are UFC: REPLENISH, UNICAST3: DATA, seqno=8825, TP: [cluster_name=default]
> 11:24:19,246 TRACE (INT-1,NodeA-6644:[]) [UFC] received 603237 credits from NodeD-30623, old credits: 938772, new credits: 1000000
> {noformat}
> {noformat}
> 15:20:14,596 TRACE (OOB-44,NodeC-64981:[]) [UFC] NodeA-12977 used 2305 credits, 798175 remaining
> 15:20:14,614 TRACE (OOB-44,NodeC-64981:[]) [UFC] sending 1201825 credits to NodeA-12977
> 15:20:14,614 TRACE (OOB-44,NodeC-64981:[]) [UDP] NodeC-64981: sending msg to NodeA-12977, src=NodeC-64981, headers are UFC: REPLENISH, UNICAST3: DATA, seqno=34854, TP: [cluster_name=default]
> 15:20:14,629 TRACE (INT-1,NodeA-12977:[]) [UDP] NodeA-12977: received [dst: NodeA-12977, src: NodeC-64981 (3 headers), size=8 bytes, flags=OOB|DONT_BUNDLE|INTERNAL], headers are MFC: REPLENISH, UNICAST3: DATA, seqno=34854, TP: [cluster_name=default]
> 15:20:14,629 TRACE (INT-1,NodeA-12977:[]) [UFC] NodeC-64981 used 8 credits, 1859662 remaining
> 15:20:14,629 TRACE (INT-1,NodeA-12977:[]) [MFC] received 1201825 credits from NodeC-64981, new credits for NodeC-64981: 2000000, min_credits=793978
> {noformat}
> UFC/MFC expect their messages to be reliable, so they don't repeat {{REPLENISH}} messages, and the only way to replenish the credits is to send a {{CREDIT_REQUEST}} message. But UFC/MFC only send a credit request after all the threads trying to send a request or response to the affected destination block for {{max_block_time}}.
> I was able to reproduce the problem with an Infinispan [micro-benchmark|https://github.com/danberindei/infinispan-microbenchmarks]: a cluster of 4 nodes, a replicated cache, 400 threads writing to the cache. It happens both with JGroups 3.6.9.Final and the latest master.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (JGRP-2072) UFC and MFC headers get mixed up
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/JGRP-2072?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on JGRP-2072:
------------------------------------
I added a new commit to my pull request, reducing the default {{max_block_time}} to 500ms. I would like to reduce it even further, but I think that would need some cooperation from {{UNICAST3}} to retransmit dropped messages sooner.
> UFC and MFC headers get mixed up
> --------------------------------
>
> Key: JGRP-2072
> URL: https://issues.jboss.org/browse/JGRP-2072
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.9
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.6.10, 4.0
>
>
> {noformat}
> 11:24:19,178 TRACE (OOB-10,NodeD-30623:[]) [MFC] NodeA-6644 used 4969 credits, 396763 remaining
> 11:24:19,238 TRACE (OOB-10,NodeD-30623:[]) [MFC] sending 603237 credits to NodeA-6644
> 11:24:19,238 TRACE (OOB-10,NodeD-30623:[]) [UDP] NodeD-30623: sending msg to NodeA-6644, src=NodeD-30623, headers are MFC: REPLENISH, UNICAST3: DATA, seqno=8825, TP: [cluster_name=default]
> 11:24:19,246 TRACE (INT-1,NodeA-6644:[]) [UDP] NodeA-6644: received [dst: NodeA-6644, src: NodeD-30623 (3 headers), size=8 bytes, flags=OOB|DONT_BUNDLE|INTERNAL], headers are UFC: REPLENISH, UNICAST3: DATA, seqno=8825, TP: [cluster_name=default]
> 11:24:19,246 TRACE (INT-1,NodeA-6644:[]) [UFC] received 603237 credits from NodeD-30623, old credits: 938772, new credits: 1000000
> {noformat}
> {noformat}
> 15:20:14,596 TRACE (OOB-44,NodeC-64981:[]) [UFC] NodeA-12977 used 2305 credits, 798175 remaining
> 15:20:14,614 TRACE (OOB-44,NodeC-64981:[]) [UFC] sending 1201825 credits to NodeA-12977
> 15:20:14,614 TRACE (OOB-44,NodeC-64981:[]) [UDP] NodeC-64981: sending msg to NodeA-12977, src=NodeC-64981, headers are UFC: REPLENISH, UNICAST3: DATA, seqno=34854, TP: [cluster_name=default]
> 15:20:14,629 TRACE (INT-1,NodeA-12977:[]) [UDP] NodeA-12977: received [dst: NodeA-12977, src: NodeC-64981 (3 headers), size=8 bytes, flags=OOB|DONT_BUNDLE|INTERNAL], headers are MFC: REPLENISH, UNICAST3: DATA, seqno=34854, TP: [cluster_name=default]
> 15:20:14,629 TRACE (INT-1,NodeA-12977:[]) [UFC] NodeC-64981 used 8 credits, 1859662 remaining
> 15:20:14,629 TRACE (INT-1,NodeA-12977:[]) [MFC] received 1201825 credits from NodeC-64981, new credits for NodeC-64981: 2000000, min_credits=793978
> {noformat}
> UFC/MFC expect their messages to be reliable, so they don't repeat {{REPLENISH}} messages, and the only way to replenish the credits is to send a {{CREDIT_REQUEST}} message. But UFC/MFC only send a credit request after all the threads trying to send a request or response to the affected destination block for {{max_block_time}}.
> I was able to reproduce the problem with an Infinispan [micro-benchmark|https://github.com/danberindei/infinispan-microbenchmarks]: a cluster of 4 nodes, a replicated cache, 400 threads writing to the cache. It happens both with JGroups 3.6.9.Final and the latest master.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (JGRP-2072) UFC and MFC headers get mixed up
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/JGRP-2072?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on JGRP-2072:
------------------------------------
I don't know how I missed the fact that the {{prot_id}} is now stored in the {{Header}}... that definitely explains why my fix works.
IMO replenish/credit request messages are pretty rare, so {{FlowControl}} could just create new instances every time, and even put the number of credits inside the headers instead of the message buffer.
> UFC and MFC headers get mixed up
> --------------------------------
>
> Key: JGRP-2072
> URL: https://issues.jboss.org/browse/JGRP-2072
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.9
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.6.10, 4.0
>
>
> {noformat}
> 11:24:19,178 TRACE (OOB-10,NodeD-30623:[]) [MFC] NodeA-6644 used 4969 credits, 396763 remaining
> 11:24:19,238 TRACE (OOB-10,NodeD-30623:[]) [MFC] sending 603237 credits to NodeA-6644
> 11:24:19,238 TRACE (OOB-10,NodeD-30623:[]) [UDP] NodeD-30623: sending msg to NodeA-6644, src=NodeD-30623, headers are MFC: REPLENISH, UNICAST3: DATA, seqno=8825, TP: [cluster_name=default]
> 11:24:19,246 TRACE (INT-1,NodeA-6644:[]) [UDP] NodeA-6644: received [dst: NodeA-6644, src: NodeD-30623 (3 headers), size=8 bytes, flags=OOB|DONT_BUNDLE|INTERNAL], headers are UFC: REPLENISH, UNICAST3: DATA, seqno=8825, TP: [cluster_name=default]
> 11:24:19,246 TRACE (INT-1,NodeA-6644:[]) [UFC] received 603237 credits from NodeD-30623, old credits: 938772, new credits: 1000000
> {noformat}
> {noformat}
> 15:20:14,596 TRACE (OOB-44,NodeC-64981:[]) [UFC] NodeA-12977 used 2305 credits, 798175 remaining
> 15:20:14,614 TRACE (OOB-44,NodeC-64981:[]) [UFC] sending 1201825 credits to NodeA-12977
> 15:20:14,614 TRACE (OOB-44,NodeC-64981:[]) [UDP] NodeC-64981: sending msg to NodeA-12977, src=NodeC-64981, headers are UFC: REPLENISH, UNICAST3: DATA, seqno=34854, TP: [cluster_name=default]
> 15:20:14,629 TRACE (INT-1,NodeA-12977:[]) [UDP] NodeA-12977: received [dst: NodeA-12977, src: NodeC-64981 (3 headers), size=8 bytes, flags=OOB|DONT_BUNDLE|INTERNAL], headers are MFC: REPLENISH, UNICAST3: DATA, seqno=34854, TP: [cluster_name=default]
> 15:20:14,629 TRACE (INT-1,NodeA-12977:[]) [UFC] NodeC-64981 used 8 credits, 1859662 remaining
> 15:20:14,629 TRACE (INT-1,NodeA-12977:[]) [MFC] received 1201825 credits from NodeC-64981, new credits for NodeC-64981: 2000000, min_credits=793978
> {noformat}
> UFC/MFC expect their messages to be reliable, so they don't repeat {{REPLENISH}} messages, and the only way to replenish the credits is to send a {{CREDIT_REQUEST}} message. But UFC/MFC only send a credit request after all the threads trying to send a request or response to the affected destination block for {{max_block_time}}.
> I was able to reproduce the problem with an Infinispan [micro-benchmark|https://github.com/danberindei/infinispan-microbenchmarks]: a cluster of 4 nodes, a replicated cache, 400 threads writing to the cache. It happens both with JGroups 3.6.9.Final and the latest master.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months