[JBoss JIRA] (JGRP-1675) Threads stuck in FlowControl.decrementIfEnoughCredits
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1675:
---------------------------
Attachment: UPerf2.java
The test to see if this blocks or not is Dan's UPerf2 (attached)
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
> Key: JGRP-1675
> URL: https://issues.jboss.org/browse/JGRP-1675
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: jgroups-udp-radim.xml, RemoteGetStressTest.java, UPerf2.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1675) Threads stuck in FlowControl.decrementIfEnoughCredits
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1675:
---------------------------
Attachment: jgroups-udp-radim.xml
Works (= doesn't block) with jgroups-udp.radim.xml. The different is the larger thread pools in Radim's config.
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
> Key: JGRP-1675
> URL: https://issues.jboss.org/browse/JGRP-1675
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: jgroups-udp-radim.xml, RemoteGetStressTest.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2383) resource-adapter id attribute has to match ra name otherwise MDB is not deployed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2383?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2383:
-----------------------------------------------
Ondrej Chaloupka <ochaloup(a)redhat.com> made a comment on [bug 1012044|https://bugzilla.redhat.com/show_bug.cgi?id=1012044]
This was not fixed. When I use the same rar name for archive and id and mdb link then I get exception [1] (I'm working with activemq). The only way how to really load the RAR I have to define names in the following way:
<subsystem xmlns="urn:jboss:domain:ejb3:1.4">
<mdb>
<resource-adapter-ref resource-adapter-name="activemq.rar"/>
<bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
</mdb>
...
<subsystem xmlns="urn:jboss:domain:resource-adapters:1.1">
<resource-adapters>
<resource-adapter id="activemq">
<archive>activemq.rar</archive>
...
which means that archive has to be archive.rar and the id just archive.
[1]
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."jbossts_crashrecovery-jms-mdb_crashrecovery-jms-mdb.jar".component.mdb.CREATE: org.jboss.msc.service.StartException in service jboss.deployment.unit."jbossts_crashrecovery-jms-mdb_crashrecovery-jms-mdb.jar".component.mdb.CREATE: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: java.lang.IllegalStateException: JBAS014331: No resource adapter registered with resource adapter name activemq
at org.jboss.as.ejb3.component.EJBUtilities.createActivationSpecs(EJBUtilities.java:85)
at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentCreateService.createComponent(MessageDrivenComponentCreateService.java:93)
at org.jboss.as.ee.component.BasicComponentCreateService.start(BasicComponentCreateService.java:91)
at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentCreateService.start(MessageDrivenComponentCreateService.java:79)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
... 3 more
> resource-adapter id attribute has to match ra name otherwise MDB is not deployed
> --------------------------------------------------------------------------------
>
> Key: WFLY-2383
> URL: https://issues.jboss.org/browse/WFLY-2383
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Stefano Maestri
> Assignee: Stefano Maestri
>
> The resource-adapter id has to have the same name as the ra archive has. Otherwise the the MDB is not deployed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-1774) Determine if Jandex can be used to optimize CDI + Bean Validation integration for method validation
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-1774?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger commented on WFLY-1774:
---------------------------------------
{quote}This option would allow us to make use of the existing portable extension instead of creating a new one specifically for WildFly.{quote}
The extension would still need to depend on WildFly (CompositeIndex) and/or Jandex APIs and thus not really *portable*. Therefore, it makes much more sense to me to create an extension specific to WildFly.
> Determine if Jandex can be used to optimize CDI + Bean Validation integration for method validation
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-1774
> URL: https://issues.jboss.org/browse/WFLY-1774
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Alpha3
> Reporter: Farah Juma
> Assignee: Farah Juma
>
> For CDI + Bean Validation integration for method validation, we're making use of the Hibernate Validator CDI portable extension. We can try to optimize this portable extension by making use of the Jandex index. In particular, we can:
> 1) Determine if Jandex can be used for subtype retrieval to avoid having to specify @ValidateOnExecution(IMPLICIT)
> 2) Determine if Jandex can be used to speed up constraint metadata retrieval
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-1533) UT015005: Error invoking method requestDestroyed on listener class
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-1533?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger reassigned WFLY-1533:
-------------------------------------
Assignee: Martin Kouba (was: Jozef Hartinger)
> UT015005: Error invoking method requestDestroyed on listener class
> -------------------------------------------------------------------
>
> Key: WFLY-1533
> URL: https://issues.jboss.org/browse/WFLY-1533
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.Alpha2, 8.0.0.Alpha4
> Reporter: Juergen Zimmermann
> Assignee: Martin Kouba
> Attachments: mojarra-2.1.zip, testcase-WFLY-1533.zip, testcase-wildfly-1533.zip
>
>
> I'm using a WildFly snapshot with Undertow 1.0.0.Alpha19 and Weld 2.0.1.Final. I'm getting the following stacktrace:
> 16:55:04,534 ERROR [io.undertow.servlet.request] UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldListener: java.lang.IllegalStateException: UT000010: Session not found MDEkG_Aum5OlXUsjh11kGkh9
> at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:221) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:106) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:25) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:13) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:161) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.servlet.ConversationContextActivator.disassociateConversationContext(ConversationContextActivator.java:162) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:159) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:91) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:196) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:159) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:114) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:90) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2438) Missing/unavailable dependencie jboss.ejb.view-method-security-attributes.foo.bar when deploy ejb type webservice
by Jim Ma (JIRA)
Jim Ma created WFLY-2438:
----------------------------
Summary: Missing/unavailable dependencie jboss.ejb.view-method-security-attributes.foo.bar when deploy ejb type webservice
Key: WFLY-2438
URL: https://issues.jboss.org/browse/WFLY-2438
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: 8.0.0.Beta1
Reporter: Jim Ma
Assignee: Jim Ma
Fix For: 8.0.0.CR1
Exception is thrown when deploy an ejb webservice without the security domain defined :
11:34:18,075 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "WSJarDeploy.jar" was rolled back with the following failure message: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.ws.endpoint.\"WSJar.jar\".WSJar is missing [jboss.ejb.view-method-security-attributes.WSJar_component.WSJar_component.WSJar.\"org.jboss.ws.HelloWsBean\"]"]}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1728) Allow testsuite parallelism to be controlled from build.xml alone
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1728?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1728:
-------------------------------------------
This change will allow QA to run tests with parallelism turned off and so get better test results for JGroups when carrying out EAP testing.
> Allow testsuite parallelism to be controlled from build.xml alone
> -----------------------------------------------------------------
>
> Key: JGRP-1728
> URL: https://issues.jboss.org/browse/JGRP-1728
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> Directives controlling parallel execution of the JGroups testsuite can be specified at two levels: as parameters to the testng ant task (in build.xml), or as attributes of the suite element in the suite definition files (found in the conf/testng directory).
> At present, parallelism directives in the various suite definition files (functional.xml, udp.xml, tcp.xml, etc.) take precedence over any directives specified in testng ant tasks. In fact, the directives passed to runtest in build.xml are (incorrectly) not passed through to the testng ant task, so that parallelism is controlled solely from the suite definition files.
> Making use of parallel execution of test cases when running in the QA lab leads to a higher proportion of test failures, leading to a proliferation of JIRA/bugzilla issues. Therefore it is important that we be able to turn on (turn off) parallel execution of test cases through some simple specification of system properties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1728) Allow testsuite parallelism to be controlled from build.xml alone
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1728?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated JGRP-1728:
--------------------------------------
Git Pull Request: https://github.com/belaban/JGroups/pull/111
> Allow testsuite parallelism to be controlled from build.xml alone
> -----------------------------------------------------------------
>
> Key: JGRP-1728
> URL: https://issues.jboss.org/browse/JGRP-1728
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> Directives controlling parallel execution of the JGroups testsuite can be specified at two levels: as parameters to the testng ant task (in build.xml), or as attributes of the suite element in the suite definition files (found in the conf/testng directory).
> At present, parallelism directives in the various suite definition files (functional.xml, udp.xml, tcp.xml, etc.) take precedence over any directives specified in testng ant tasks. In fact, the directives passed to runtest in build.xml are (incorrectly) not passed through to the testng ant task, so that parallelism is controlled solely from the suite definition files.
> Making use of parallel execution of test cases when running in the QA lab leads to a higher proportion of test failures, leading to a proliferation of JIRA/bugzilla issues. Therefore it is important that we be able to turn on (turn off) parallel execution of test cases through some simple specification of system properties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months