[JBoss JIRA] (JGRP-2146) UDP: multiple unicast and multicast receiver threads
by Bela Ban (JIRA)
Bela Ban created JGRP-2146:
------------------------------
Summary: UDP: multiple unicast and multicast receiver threads
Key: JGRP-2146
URL: https://issues.jboss.org/browse/JGRP-2146
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.0
By default UDP has one thread which reads from the DatagramSocket for unicast datagram packets and another one for reading packets from the MulticastSocket.
Because each thread deserializes the received packet into a {{Message}} or {{MessageBatch}}, if a lot of packets are received, this may slow things down.
The new attributes {{ucast_receiver_threads}} (default:1) and {{mcast_receiver_threads}} (default:1) in UDP can create multiple unicast- or multicast- receiver threads. Note that all threads of the same type compete for the lock on the DatagramSocket or MulticastSocket respectively, so setting these attributes to high values is probably detrimental as context switching will increase.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7300) OperationHandlers that register DeploymentProcessor should do it only on boot
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-7300?page=com.atlassian.jira.plugin.... ]
Thomas Diesler edited comment on WFLY-7300 at 12/12/16 7:00 AM:
----------------------------------------------------------------
The commit associated with https://github.com/wildfly/wildfly/pull/9445 breaks wildfly-camel integration.
{code}
12:32:16,285 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit.arquillian-service.INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit.arquillian-service.INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "arquillian-service"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
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: java.lang.NullPointerException
at org.wildfly.extension.batch.jberet.deployment.BatchDeploymentResourceProcessor.deploy(BatchDeploymentResourceProcessor.java:66)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
... 5 more
{code}
It seems that arbitrary deployments can cause an NPE in BatchDeploymentResourceProcessor although they are not relevant to the batch subsystem.
CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/1531
was (Author: thomas.diesler):
The commit associated with https://github.com/wildfly/wildfly/pull/9445 breaks wildfly-camel integration.
{code}
12:32:16,285 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit.arquillian-service.INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit.arquillian-service.INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "arquillian-service"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
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: java.lang.NullPointerException
at org.wildfly.extension.batch.jberet.deployment.BatchDeploymentResourceProcessor.deploy(BatchDeploymentResourceProcessor.java:66)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
... 5 more
{code}
It seems that arbitrary deployments can cause an NPE in BatchDeploymentResourceProcessor although they are not relevant to the batch subsystem
> OperationHandlers that register DeploymentProcessor should do it only on boot
> -----------------------------------------------------------------------------
>
> Key: WFLY-7300
> URL: https://issues.jboss.org/browse/WFLY-7300
> Project: WildFly
> Issue Type: Bug
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Fix For: 11.0.0.Alpha1
>
>
> Registering a DeploymentProcessor is a boot only operation. Thus instead of extends AbstractAddStepHandler they should extend AbstractBoottimeAddStepHandler
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7300) OperationHandlers that register DeploymentProcessor should do it only on boot
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-7300?page=com.atlassian.jira.plugin.... ]
Thomas Diesler edited comment on WFLY-7300 at 12/12/16 6:58 AM:
----------------------------------------------------------------
The commit associated with https://github.com/wildfly/wildfly/pull/9445 breaks wildfly-camel integration.
{code}
12:32:16,285 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit.arquillian-service.INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit.arquillian-service.INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "arquillian-service"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
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: java.lang.NullPointerException
at org.wildfly.extension.batch.jberet.deployment.BatchDeploymentResourceProcessor.deploy(BatchDeploymentResourceProcessor.java:66)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
... 5 more
{code}
It seems that arbitrary deployments can cause an NPE in BatchDeploymentResourceProcessor although they are not relevant to the batch subsystem
was (Author: thomas.diesler):
The commit associated with https://github.com/wildfly/wildfly/pull/9445 breaks wildfly-camel integration.
```
12:32:16,285 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit.arquillian-service.INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit.arquillian-service.INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "arquillian-service"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
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: java.lang.NullPointerException
at org.wildfly.extension.batch.jberet.deployment.BatchDeploymentResourceProcessor.deploy(BatchDeploymentResourceProcessor.java:66)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
... 5 more
```
It seems that arbitrary deployments can cause an NPE in BatchDeploymentResourceProcessor although they are not relevant to the batch subsystem
> OperationHandlers that register DeploymentProcessor should do it only on boot
> -----------------------------------------------------------------------------
>
> Key: WFLY-7300
> URL: https://issues.jboss.org/browse/WFLY-7300
> Project: WildFly
> Issue Type: Bug
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Fix For: 11.0.0.Alpha1
>
>
> Registering a DeploymentProcessor is a boot only operation. Thus instead of extends AbstractAddStepHandler they should extend AbstractBoottimeAddStepHandler
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7300) OperationHandlers that register DeploymentProcessor should do it only on boot
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-7300?page=com.atlassian.jira.plugin.... ]
Thomas Diesler reopened WFLY-7300:
----------------------------------
The commit associated with https://github.com/wildfly/wildfly/pull/9445 breaks wildfly-camel integration.
```
12:32:16,285 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit.arquillian-service.INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit.arquillian-service.INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "arquillian-service"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
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: java.lang.NullPointerException
at org.wildfly.extension.batch.jberet.deployment.BatchDeploymentResourceProcessor.deploy(BatchDeploymentResourceProcessor.java:66)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
... 5 more
```
It seems that arbitrary deployments can cause an NPE in BatchDeploymentResourceProcessor although they are not relevant to the batch subsystem
> OperationHandlers that register DeploymentProcessor should do it only on boot
> -----------------------------------------------------------------------------
>
> Key: WFLY-7300
> URL: https://issues.jboss.org/browse/WFLY-7300
> Project: WildFly
> Issue Type: Bug
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Fix For: 11.0.0.Alpha1
>
>
> Registering a DeploymentProcessor is a boot only operation. Thus instead of extends AbstractAddStepHandler they should extend AbstractBoottimeAddStepHandler
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7781) username-load attribute of legacy LDAP Realm stop to work
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7781?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7781:
-------------------------------
Steps to Reproduce:
1. Start LDAP server with following ldif:
{code}
dn: ou=People,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: People
dn: uid=jduke,ou=People,dc=jboss,dc=org
objectclass: top
objectclass: person
objectclass: inetOrgPerson
uid: jduke
cn: Java Duke
sn: Duke
userPassword: Password
{code}
2. Add outbound connection to standalone.xml
{code}
<outbound-connections>
<ldap search-dn="uid=admin,ou=system" name="ldap-connection" search-credential="secret" url="ldap://localhost:10389"/>
</outbound-connections>
{code}
3. Add ldap security-realm
{code}
<security-realm name="ldap-realm">
<authentication>
<ldap connection="ldap-connection" base-dn="ou=People,dc=jboss,dc=org" username-load="sn">
<advanced-filter filter="(uid={0})"/>
</ldap>
</authentication>
</security-realm>
{code}
4. Set ldap-realm for http-interface
{code}
<management-interfaces>
<http-interface security-realm="ldap-realm">
<http-upgrade enabled="true"/>
<socket-binding http="management-http"/>
</http-interface>
</management-interfaces>
{code}
5. start Application Server and run CLI command
{code}
./jboss-cli.sh -c -u=jduke -p=Password ':whoami'
{
"outcome" => "success",
"result" => {"identity" => {"username" => "jduke"}}
}
{code}
In correct behavior username "Duke" should be assigned.
was:
1. Start LDAP server with following ldif:
{code}
dn: ou=People,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: People
dn: uid=jduke,ou=People,dc=jboss,dc=org
objectclass: top
objectclass: person
objectclass: inetOrgPerson
uid: jduke
cn: Java Duke
sn: Duke
userPassword: Password
{code}
2. Add outbound connection to standalone.xml
{code}
<outbound-connections>
<ldap search-dn="uid=admin,ou=system" name="ldap-connection" search-credential="secret" url="ldap://localhost:10389"/>
</outbound-connections>
{code}
3. Add ldap security-realm
{code}
<security-realm name="ldap-realm">
<authentication>
<ldap connection="ldap-connection" base-dn="ou=People,dc=jboss,dc=org" username-load="sn">
<advanced-filter filter="(uid={0})"/>
</ldap>
</authentication>
</security-realm>
{code}
4. Set ldap-realm for http-interface
{code}
<management-interfaces>
<http-interface security-realm="ldap-realm">
<http-upgrade enabled="true"/>
<socket-binding http="management-http"/>
</http-interface>
</management-interfaces>
{code}
5. start Application Server and run CLI command
{code}
./jboss-cli.sh -c -u=jduke -p=Password ':whoami'
{
"outcome" => "success",
"result" => {"identity" => {"username" => "jduke"}}
}
{code}
In correct behavior (in EAP 7.0.x) username "Duke" should be assigned.
> username-load attribute of legacy LDAP Realm stop to work
> ---------------------------------------------------------
>
> Key: WFLY-7781
> URL: https://issues.jboss.org/browse/WFLY-7781
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> {{username-load}} attribute of legacy LDAP Realm stop to work. This attribute is used for assigning username from some LDAP entry attribute. In current behavior username passed in credential is used as username even if username-load attribute is configured.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7781) username-load attribute of legacy LDAP Realm stop to work
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7781?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7781:
-------------------------------
Description: {{username-load}} attribute of legacy LDAP Realm stop to work. This attribute is used for assigning username from some LDAP entry attribute. In current behavior username passed in credential is used as username even if username-load attribute is configured. (was: {{username-load}} attribute of legacy LDAP Realm stop to work in EAP 7.1.0.DR9. This attribute is used for assigning username from some LDAP entry attribute. In current behavior in EAP 7.1.0.DR9 username passed in credential is used as username even if username-load attribute is configured.
Due to regression we request blocker. Taking EAP 7.0.x configuration and put it into EAP 7.1.x will causes that username-load feature stop to work.)
Summary: username-load attribute of legacy LDAP Realm stop to work (was: Regression in EAP 7.1.0.DR9: username-load attribute of legacy LDAP Realm stop to work)
> username-load attribute of legacy LDAP Realm stop to work
> ---------------------------------------------------------
>
> Key: WFLY-7781
> URL: https://issues.jboss.org/browse/WFLY-7781
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> {{username-load}} attribute of legacy LDAP Realm stop to work. This attribute is used for assigning username from some LDAP entry attribute. In current behavior username passed in credential is used as username even if username-load attribute is configured.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months