[JBoss JIRA] (JGRP-1827) Forked channel requires udp.xml file
by Jim Thomas (JIRA)
[ https://issues.jboss.org/browse/JGRP-1827?page=com.atlassian.jira.plugin.... ]
Jim Thomas commented on JGRP-1827:
----------------------------------
That didn't fix it for me (or at least not entirely) -- I still get the same udp.xml not found exception from the original comment. If you look at the call stack for the exception you can see that we are in the JChannel (super) default constructor and have not yet gotten to the point where we make an instance of FORK using getFork in the ForkChannel constructor. If I have a valid udp.xml, but one that does not contain a FORK protocol in it, then the fork channel is created and works. A bit scary though.
>From my look at the code it seems to me that ForkChannel should not be using the default constructor for the parent JChannel. Not sure if one of the other JChannel constructors is appropriate or if a new one must be added.
> Forked channel requires udp.xml file
> ------------------------------------
>
> Key: JGRP-1827
> URL: https://issues.jboss.org/browse/JGRP-1827
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.1
> Environment: Android
> Reporter: Jim Thomas
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.4, 3.5
>
> Attachments: bla2.java, fork-stacks.xml, main.xml
>
>
> An exception is thrown when creating a fork channel if the stack file name is something other than udp.xml (in my case main.xml):
> final JChannel mainChannel = new JChannel("main.xml");
> final ForkChannel mbChannel = new ForkChannel(mainChannel,
> "main", "fork-mb");
> 4-09 17:33:38.270: W/System.err(5478): java.io.FileNotFoundException: JGRP000003: file "udp.xml" not found
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.conf.ConfiguratorFactory.getXmlConfigurator(ConfiguratorFactory.java:211)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.conf.ConfiguratorFactory.getStackConfigurator(ConfiguratorFactory.java:102)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.JChannel.<init>(JChannel.java:172)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.JChannel.<init>(JChannel.java:123)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.fork.ForkChannel.<init>(ForkChannel.java:75)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.fork.ForkChannel.<init>(ForkChannel.java:118)
> 04-09 17:33:38.270: W/System.err(5478): at com.novawurks.jgroupstest.JGroupsTestActivity$JGroupsSetupThread.run(JGroupsTestActivity.java:119)
> If I have the stack named udp.xml then the exception is not thrown and everything works as expected. If I make a copy of main.xml named udp.xml (so both files are present) the exception is not thrown and everything works as expected.
> Contents of main.xml / udp.xml :
> {code:xml}
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:org:jgroups"
> xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.3.xsd" >
> <UDP
> enable_diagnostics="true"
> ip_mcast="true"
> ip_ttl="${jgroups.udp.ip_ttl:8}"
> loopback="true"
> max_bundle_size="1400"
> max_bundle_timeout="5"
> mcast_port="${jgroups.udp.mcast_port:45588}"
> mcast_recv_buf_size="200K"
> mcast_send_buf_size="200K"
> oob_thread_pool.enabled="true"
> oob_thread_pool.keep_alive_time="5000"
> oob_thread_pool.max_threads="8"
> oob_thread_pool.min_threads="1"
> oob_thread_pool.queue_enabled="false"
> oob_thread_pool.queue_max_size="100"
> oob_thread_pool.rejection_policy="discard"
> thread_naming_pattern="cl"
> thread_pool.enabled="true"
> thread_pool.keep_alive_time="5000"
> thread_pool.max_threads="8"
> thread_pool.min_threads="2"
> thread_pool.queue_enabled="true"
> thread_pool.queue_max_size="10000"
> thread_pool.rejection_policy="discard"
> timer.keep_alive_time="3000"
> timer.max_threads="10"
> timer.min_threads="4"
> timer.queue_max_size="500"
> timer_type="new3"
> tos="8"
> ucast_recv_buf_size="200K"
> ucast_send_buf_size="200K" />
> <PING />
> <MERGE2
> max_interval="30000"
> min_interval="10000" />
> <FD_SOCK />
> <FD_ALL />
> <VERIFY_SUSPECT timeout="1500" />
> <BARRIER />
> <pbcast.NAKACK2
> discard_delivered_msgs="true"
> max_msg_batch_size="500"
> use_mcast_xmit="false"
> xmit_interval="500"
> xmit_table_max_compaction_time="30000"
> xmit_table_msgs_per_row="2000"
> xmit_table_num_rows="100" />
> <UNICAST3
> conn_expiry_timeout="0"
> max_msg_batch_size="500"
> xmit_interval="500"
> xmit_table_max_compaction_time="60000"
> xmit_table_msgs_per_row="2000"
> xmit_table_num_rows="100" />
> <pbcast.STABLE
> desired_avg_gossip="50000"
> max_bytes="4M"
> stability_delay="1000" />
> <pbcast.GMS
> join_timeout="3000"
> print_local_addr="true"
> view_bundling="true" />
> <UFC
> max_credits="2M"
> min_threshold="0.4" />
> <MFC
> max_credits="2M"
> min_threshold="0.4" />
> <FRAG frag_size="1000" />
> <pbcast.STATE_TRANSFER />
> <FORK>
> <fork-stack id="main" >
> <config>
> <CENTRAL_LOCK num_backups="2" />
> </config>
> </fork-stack>
> <fork-stack id="lock" >
> <config>
> <CENTRAL_LOCK num_backups="2" />
> <STATS />
> </config>
> </fork-stack>
> </FORK>
> </config>
> {code}
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-3220) ARJUNA016009 ArrayIndexOutOfBoundsException during periodic recovery on EJBTransactionRecoveryService
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3220?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3220:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1035216|https://bugzilla.redhat.com/show_bug.cgi?id=1035216] from MODIFIED to ON_QA
> ARJUNA016009 ArrayIndexOutOfBoundsException during periodic recovery on EJBTransactionRecoveryService
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3220
> URL: https://issues.jboss.org/browse/WFLY-3220
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Masafumi Miura
> Assignee: Masafumi Miura
> Fix For: 8.1.0.CR1
>
> Attachments: WFLY-3220-byteman-script.btm
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1035216 is also reproducible in wildfly.
> {code}
> WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.ArrayIndexOutOfBoundsException: 0
> at org.jboss.as.ejb3.remote.EJBTransactionRecoveryService.getXAResources(EJBTransactionRecoveryService.java:114)
> at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:516) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> {code}
> I think the line 111 "new XAResource\[receiverContexts.size()\]" should be placed inside synchronized block.
> {code:java|title=ejb3/src/main/java/org/jboss/as/ejb3/remote/EJBTransactionRecoveryService.java}
> 109 @Override
> 110 public XAResource[] getXAResources() {
> 111 final XAResource[] xaResources = new XAResource[receiverContexts.size()];
> 112 synchronized (receiverContexts) {
> 113 for (int i = 0; i < receiverContexts.size(); i++) {
> 114 xaResources[i] = EJBClientManagedTransactionContext.getEJBXAResourceForRecovery(receiverContexts.get(i), arjunaTxCoreEnvironmentBean.getValue().getNodeIdentifier());
> 115 }
> 116 }
> 117 return xaResources;
> 118 }
> ...
> 124 @Override
> 125 public void receiverRegistered(final EJBReceiverContext receiverContext) {
> 126 this.receiverContexts.add(receiverContext);
> 127 }
> {code}
> I think this "java.lang.ArrayIndexOutOfBoundsException: 0" will happen in the following scenario:
> # receiverContexts.size() = 0 at the line 111
> xaResources is created with new XAResource\[0\]
> # receiverRegistered method is called from other thread between the line 111 and 112
> Now receiverContexts.size() = 1
> # As receiverContexts.size() = 1, for-loop is executed
> Then "xaResources\[0\] = ..." will get ArrayIndexOutOfBoundsException at the line 114 because xaResources is empty array.
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-3228) ApplyRemoteMasterDomainHandler should use values sent from DC for root resource
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3228?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3228:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1085122|https://bugzilla.redhat.com/show_bug.cgi?id=1085122] from MODIFIED to ON_QA
> ApplyRemoteMasterDomainHandler should use values sent from DC for root resource
> -------------------------------------------------------------------------------
>
> Key: WFLY-3228
> URL: https://issues.jboss.org/browse/WFLY-3228
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Final
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 8.1.0.CR1
>
>
> This is needed to keep the slave copy of the resource model actually the same, and popped up during mixed domain testing of EAP with a 6.2.0 slave.
> Connect directly to to 6.1.1 slave - gets domain version from master
> {code}
> [domain@localhost:19999 /] :read-resource
> {
> "outcome" => "success",
> "result" => {
> "deployment" => undefined,
> "deployment-overlay" => undefined,
> "management-major-version" => 1,
> "management-micro-version" => 0,
> "management-minor-version" => 6,
> "name" => "Unnamed Domain",
> "namespaces" => [],
> "path" => undefined,
> "product-name" => "EAP",
> "product-version" => "6.3.0.Alpha3",
> "profile" => undefined,
> "release-codename" => "Janus",
> "release-version" => "7.4.0.Final-redhat-SNAPSHOT",
> {code}
> Connect directly to 6.2.0 slave - does not get domain version from master
> {code}
> [domain@localhost:19999 /] :read-resource
> {
> "outcome" => "success",
> "result" => {
> "management-major-version" => 1,
> "management-micro-version" => 0,
> "management-minor-version" => 5,
> "name" => "Unnamed Domain",
> "namespaces" => [],
> "product-name" => "EAP",
> "product-version" => "6.2.0.GA",
> "release-codename" => "Janus",
> "release-version" => "7.3.0.Final-redhat-14",
> {code}
> The 6.2.0 slave should look the same as the 6.1.1 slave for these attributes.
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3048?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3048:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1043667|https://bugzilla.redhat.com/show_bug.cgi?id=1043667] from MODIFIED to ON_QA
> "Local" authentication fails when LDAP is used for ManagementRealm
> ------------------------------------------------------------------
>
> Key: WFLY-3048
> URL: https://issues.jboss.org/browse/WFLY-3048
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 8.0.0.Final
> Environment: Ubuntu 13.04, Xeon-based VPS
> Reporter: Matt Jensen
> Assignee: Darran Lofthouse
> Fix For: 8.1.0.CR1
>
>
> When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working.
> I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows:
> <security-realm name="ManagementRealm">
> <authentication>
> <local default-user="$local" />
> <ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false">
> ...
> </ldap>
> </authentication>
> <authorization map-groups-to-roles="false">
> <ldap connection="...">
> ...
> </ldap>
> </authorization>
> </security-realm>
> I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command.
> The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm.
> If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password.
> I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password.
> The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up.
> The documentation specifically mentions that <local/> should work along with <ldap/> here:
> https://docs.jboss.org/author/display/WFLY8/Security+Realms
--
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
10 years, 5 months