[JBoss JIRA] (JBJCA-1334) Add DataSource to ManagementRepository only after deployed successfully
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1334?page=com.atlassian.jira.plugin... ]
Lin Gao commented on JBJCA-1334:
--------------------------------
This Jira is created by cloning the WFLY-7214.
The reason for the problem is that {{AbstractDsDeployer}} [added the DataSource into ManagementRepository|https://github.com/ironjacamar/ironjacamar/blob/1.3/...] before it knows that the DataSource deployment will succeed. Move the addition a little late will solve the problem.
> Add DataSource to ManagementRepository only after deployed successfully
> -----------------------------------------------------------------------
>
> Key: JBJCA-1334
> URL: https://issues.jboss.org/browse/JBJCA-1334
> Project: IronJacamar
> Issue Type: Bug
> Components: Deployer
> Reporter: Lin Gao
> Assignee: Jesper Pedersen
>
> When a data-source was failed to be added either because of missing connection-properties:
> {code:}
> /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2)
> {code}
> or missing of connection-url:
> {code:}
> /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2)
> {code}
> , it can be added by correcting the information, like:
> {code:}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test")
> {"outcome" => "success"}
> {code}
> But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBJCA-1334) Add DataSource to ManagementRepository only after deployed successfully
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1334?page=com.atlassian.jira.plugin... ]
Lin Gao moved WFLY-7237 to JBJCA-1334:
--------------------------------------
Project: IronJacamar (was: WildFly)
Key: JBJCA-1334 (was: WFLY-7237)
Workflow: classic default workflow (was: GIT Pull Request workflow )
Component/s: Deployer
(was: JCA)
> Add DataSource to ManagementRepository only after deployed successfully
> -----------------------------------------------------------------------
>
> Key: JBJCA-1334
> URL: https://issues.jboss.org/browse/JBJCA-1334
> Project: IronJacamar
> Issue Type: Bug
> Components: Deployer
> Reporter: Lin Gao
> Assignee: Jesper Pedersen
>
> When a data-source was failed to be added either because of missing connection-properties:
> {code:}
> /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2)
> {code}
> or missing of connection-url:
> {code:}
> /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2)
> {code}
> , it can be added by correcting the information, like:
> {code:}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test")
> {"outcome" => "success"}
> {code}
> But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7237) Add DataSource to ManagementRepository only after deployed successfully
by Lin Gao (JIRA)
Lin Gao created WFLY-7237:
-----------------------------
Summary: Add DataSource to ManagementRepository only after deployed successfully
Key: WFLY-7237
URL: https://issues.jboss.org/browse/WFLY-7237
Project: WildFly
Issue Type: Bug
Components: JCA
Reporter: Lin Gao
Assignee: Jesper Pedersen
When a data-source was failed to be added either because of missing connection-properties:
{code:}
/subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2)
{code}
or missing of connection-url:
{code:}
/subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2)
{code}
, it can be added by correcting the information, like:
{code:}
[standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test")
{"outcome" => "success"}
{code}
But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7236) DatasourceNonCcmTestCase fails with security manager
by Jan Tymel (JIRA)
Jan Tymel created WFLY-7236:
-------------------------------
Summary: DatasourceNonCcmTestCase fails with security manager
Key: WFLY-7236
URL: https://issues.jboss.org/browse/WFLY-7236
Project: WildFly
Issue Type: Bug
Components: Test Suite
Reporter: Jan Tymel
Assignee: Jan Tymel
*org.jboss.as.test.integration.jca.datasource.DatasourceNonCcmTestCase#testJTADS*
*org.jboss.as.test.integration.jca.datasource.DatasourceNonCcmTestCase#testNonJTADS*
{{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.jca.datasource.DatasourceNonCcmTestCase -Dsecurity.manager}}
{code}
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/dummy.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.dummy.jar:main" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:85)
at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:112)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:120)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:64)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:139)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:114)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
... 146 more
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7235) InfinispanResourceRefTestCase fails with security manager
by Jan Tymel (JIRA)
Jan Tymel created WFLY-7235:
-------------------------------
Summary: InfinispanResourceRefTestCase fails with security manager
Key: WFLY-7235
URL: https://issues.jboss.org/browse/WFLY-7235
Project: WildFly
Issue Type: Bug
Components: Test Suite
Reporter: Jan Tymel
Assignee: Jan Tymel
*org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase#test*
{{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase -Dsecurity.manager}}
{code}
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/infinispan-resource-ref.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.infinispan-resource-ref.war:main" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1442)
at org.infinispan.commons.util.Util.getClassLoaders(Util.java:127)
at org.infinispan.commons.util.Util.loadClassStrict(Util.java:163)
at org.infinispan.commons.util.ReflectionUtil.getClassForName(ReflectionUtil.java:319)
at org.infinispan.commons.util.ReflectionUtil.toClassArray(ReflectionUtil.java:313)
at org.infinispan.factories.AbstractComponentRegistry$Component.buildInjectionMethodsList(AbstractComponentRegistry.java:810)
at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:213)
at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:193)
at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:171)
at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:163)
at org.infinispan.factories.ComponentRegistry.<init>(ComponentRegistry.java:79)
... 210 more
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7226) Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7226?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas commented on WFLY-7226:
------------------------------------
Hi [~ivassile],
realm-map for mapped-regex-realm-mapper is an Object attribute. It can be set in CLI command like this:
{code}
/subsystem=elytron/mapped-regex-realm-mapper=someName:add(pattern="(.?)",realm-map={a=b,c=d})
{code}
However the point of this issue is to provide users some understandable log for cases when realm-map attribute is missing (see CLI command in Steps to Reproduce). Currently it only throws mentioned above exception.
Try to use following command:
{code}
/subsystem=elytron/mapped-regex-realm-mapper=someName:add(realm-map={a=b,c=d})
{code}
it will result to exception with clear failure-description that pattern may not be null:
{code}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0155: pattern may not be null",
"rolled-back" => true
}
{code}
The same should happen for missing required realm-map attribute.
> Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7226
> URL: https://issues.jboss.org/browse/WFLY-7226
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
>
> In case when mapped-regex-realm-mapper is added through CLI and realm-map attribute is not used then IllegalArgumentException is thrown to server log instead of some CLI failure message like "realm-map may not be null".
> Expcetion in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("mapped-regex-realm-mapper" => "MappedRealmMapper")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:139)
> at org.jboss.dmr.ModelNode.keys(ModelNode.java:1378)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$MappedRegexRealmMapperAddHandler.performRuntime(RealmMapperDefinitions.java:221)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7224) Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7224?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev edited comment on WFLY-7224 at 9/29/16 12:18 AM:
---------------------------------------------------------------
Hi [~honza889]. I'm proposing the following fix [1] for this issue. Please check if the fix is correct and let me know what needs to be modified in order to complete it and submit PR. This change will also resolve https://issues.jboss.org/browse/WFLY-7225.
[1] https://github.com/ivassile/elytron-subsystem/commit/e911c17126b33614b408...
was (Author: ivassile):
Hi [~honza889]. I'm proposing the following fix [1] for this issue. Please check if the fix is correct and let me know what needs to be modified in order to complete it and submit PR. This change will also resolve https://issues.jboss.org/browse/WFLY-7225.
[1] https://github.com/ivassile/elytron-subsystem/commit/798829eec0a636b0e6e8...
> Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7224
> URL: https://issues.jboss.org/browse/WFLY-7224
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> Elytron subsystem allows to add realm mapper (e.g. simple-regex-realm-mapper) with pattern which does not include a capture group. In case when this realm mapper is used in add operation for security domain through CLI then operation fails with incomprehensible log:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},
> "rolled-back" => true
> }
> {code}
> Exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: 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: java.lang.IllegalArgumentException: ELY01065: Pattern requires a capture group
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64)
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> {code}
> The same happens for mapped-regex-realm-mapper.
> Point here is that we allow to successfully add wrong realm mapper (without capture group) but we check whether it is wrong later in security domain. This check should be done during adding wrong realm mapper to avoid following incomprehensible CLI log and exception in server log.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7224) Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7224?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev edited comment on WFLY-7224 at 9/29/16 12:17 AM:
---------------------------------------------------------------
[~honza889] Sent PR [1] which is easier to review.
[1] https://github.com/wildfly-security/elytron-subsystem/pull/244
was (Author: ivassile):
[~honza889] Sent PR [1] which is easier to review.
[1] https://github.com/wildfly-security/elytron-subsystem/pull/243
> Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7224
> URL: https://issues.jboss.org/browse/WFLY-7224
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> Elytron subsystem allows to add realm mapper (e.g. simple-regex-realm-mapper) with pattern which does not include a capture group. In case when this realm mapper is used in add operation for security domain through CLI then operation fails with incomprehensible log:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},
> "rolled-back" => true
> }
> {code}
> Exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: 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: java.lang.IllegalArgumentException: ELY01065: Pattern requires a capture group
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64)
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> {code}
> The same happens for mapped-regex-realm-mapper.
> Point here is that we allow to successfully add wrong realm mapper (without capture group) but we check whether it is wrong later in security domain. This check should be done during adding wrong realm mapper to avoid following incomprehensible CLI log and exception in server log.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2102) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
by 俐佳 张 (JIRA)
[ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.... ]
俐佳 张 edited comment on JGRP-2102 at 9/28/16 11:31 PM:
------------------------------------------------------
but bind_interface is http://www.jgroups.org/schema/jgroups-4.0.xsd. I checked the code 4.0 beta, there's no fix for the issue. I can see the fixed version is 3.6.12 in the ticket do you mean that issue is fixed from this version.
was (Author: kathzhan):
but bind_interface is http://www.jgroups.org/schema/jgroups-4.0.xsd. I checked the code 4.0 beta, there's the fix for the issue. I can see the fixed version is 3.6.12 in the ticket do you mean that issue is fixed from this version.
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
> --------------------------------------------------------------------
>
> Key: JGRP-2102
> URL: https://issues.jboss.org/browse/JGRP-2102
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Environment: [root@wtc2k01v27 ~] CLONE # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 2606:ae00:e200:3f::83/128 scope global
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff
> inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0
> inet6 2606:ae00:e200:3f::28/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::250:56ff:feab:2aea/64 scope link
> valid_lft forever preferred_lft forever
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1
> inet6 fe80::250:56ff:feab:d612/64 scope link
> valid_lft forever preferred_lft forever
> There're eth0 and eth1 exists in the environment
> Reporter: 俐佳 张
> Assignee: Bela Ban
> Fix For: 3.6.12
>
> Attachments: jgroups-udp.xml
>
>
> Error happens while
> Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
> at java.lang.reflect.Method.invoke(Method.java:620)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
> ... 26 more
> Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
> at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
> at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
> at org.jgroups.JChannel.init(JChannel.java:854)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jgroups.JChannel.<init>(JChannel.java:129)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404)
> ... 39 more
> Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
> ... 48 more
> Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3
> at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132)
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time
> but it couldn't get the eth0 link local address but return eth1 link local address
> This code return the first address that match, it should return with eth0
> jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java
> public static InetAddress getAddress(AddressScope scope) ----> scope is LINK_LOCAL
> throws SocketException
> {
> InetAddress address = null;
> Enumeration intfs = NetworkInterface.getNetworkInterfaces();
> while (intfs.hasMoreElements()) {
> NetworkInterface intf = (NetworkInterface)intfs.nextElement();
> try {
> if (intf.isUp()) {
> address = getAddress(intf, scope); -------> It will return the first LINK_LOCAL address from NICs list
> if (address != null)
> return address;
> }
> }
> catch (SocketException e) {
> }
> }
> return null;
> }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2102) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
by 俐佳 张 (JIRA)
[ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.... ]
俐佳 张 commented on JGRP-2102:
----------------------------
sorry I double check the code of 4.0 Beta, there's no fix still. but I really think that is the bug in jgroup side.
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
> --------------------------------------------------------------------
>
> Key: JGRP-2102
> URL: https://issues.jboss.org/browse/JGRP-2102
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Environment: [root@wtc2k01v27 ~] CLONE # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 2606:ae00:e200:3f::83/128 scope global
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff
> inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0
> inet6 2606:ae00:e200:3f::28/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::250:56ff:feab:2aea/64 scope link
> valid_lft forever preferred_lft forever
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1
> inet6 fe80::250:56ff:feab:d612/64 scope link
> valid_lft forever preferred_lft forever
> There're eth0 and eth1 exists in the environment
> Reporter: 俐佳 张
> Assignee: Bela Ban
> Fix For: 3.6.12
>
> Attachments: jgroups-udp.xml
>
>
> Error happens while
> Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
> at java.lang.reflect.Method.invoke(Method.java:620)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
> ... 26 more
> Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
> at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
> at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
> at org.jgroups.JChannel.init(JChannel.java:854)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jgroups.JChannel.<init>(JChannel.java:129)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404)
> ... 39 more
> Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
> ... 48 more
> Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3
> at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132)
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time
> but it couldn't get the eth0 link local address but return eth1 link local address
> This code return the first address that match, it should return with eth0
> jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java
> public static InetAddress getAddress(AddressScope scope) ----> scope is LINK_LOCAL
> throws SocketException
> {
> InetAddress address = null;
> Enumeration intfs = NetworkInterface.getNetworkInterfaces();
> while (intfs.hasMoreElements()) {
> NetworkInterface intf = (NetworkInterface)intfs.nextElement();
> try {
> if (intf.isUp()) {
> address = getAddress(intf, scope); -------> It will return the first LINK_LOCAL address from NICs list
> if (address != null)
> return address;
> }
> }
> catch (SocketException e) {
> }
> }
> return null;
> }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months