May 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-1343) Remove the cyclical dependency from ejb3/core to org.jboss.jbossas-jboss-as-server

by Dimitris Andreadis (JIRA)

Remove the cyclical dependency from ejb3/core to org.jboss.jbossas-jboss-as-server ---------------------------------------------------------------------------------- Key: EJBTHREE-1343 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1343 Project: EJB 3.0 Issue Type: Task Components: core Reporter: Dimitris Andreadis Assigned To: Carlo de Wolf Priority: Critical Fix For: AS 5.0.0.CR1 ejb3/core -> jboss-as-server dependencies ------------------------------------------------------------ ejb3/core ./org/jboss/ejb3/naming/client/java/javaURLContextFactory.java depends on org.jboss.jbossas:jboss-as-server org.jboss.corba.ORBFactory ------------------------------------------------------------ ejb3/core ./org/jboss/ejb3/naming/client/java/javaURLContextFactory.java depends on org.jboss.jbossas:jboss-as-server org.jboss.naming.client.java.HandleDelegateFactory; ------------------------------------------------------------ ejb3/core ./org/jboss/ejb3/AllowedOperationsInterceptor.java ./org/jboss/ejb3/service/ServiceContainer.java ./org/jboss/ejb3/stateless/StatelessContainer.java depends on org.jboss.jbossas:jboss-as-server org.jboss.ejb.AllowedOperationsAssociation ejb3/core ./org/jboss/ejb3/mdb/MessagingContainer.java depends on org.jboss.jbossas:jboss-as-server org.jboss.jms.jndi.JMSProviderAdapter; org.jboss.jbossas:jboss-as-server ----------------------------------------- ejb3/core ./org/jboss/ejb3/timerservice/jboss/JBossTimerServiceFactory.java ./org/jboss/ejb3/timerservice/TimedObjectInvoker.java depends on org.jboss.jbossas:jboss-as-server org.jboss.ejb.txtimer.EJBTimerService; org.jboss.ejb.txtimer.TimedObjectInvoker ----------------------------------------- ejb3/core ./org/jboss/ejb3/stateful/StatefulLocalProxyFactory.java ./org/jboss/ejb3/stateless/StatelessContainer.java depends on org.jboss.jbossas:jboss-as-server org.jboss.proxy.ejb.handle.StatefulHandleImpl; org.jboss.proxy.ejb.handle.HomeHandleImpl; ------------------------------------------ ejb3/core ./org/jboss/ejb3/AllowedOperationsInterceptor.java ./org/jboss/ejb3/ContainerPlugin.java ./org/jboss/ejb3/service/ServiceContainer.java ./org/jboss/ejb3/stateless/StatelessContainer.java depends on org.jboss.jbossas:jboss-as-server org.jboss.ejb.AllowedOperationsFlags ------------------------------------------- ejb3/core ./org/jboss/ejb3/EJBProxyFactory.java depends on org.jboss.jbossas:jboss-as-server org.jboss.invocation.Invocation -------------------------------------------- ejb3/core ./org/jboss/ejb3/EJBProxyFactory.java depends on org.jboss.jbossas:jboss-as-server org.jboss.ejb.GenericEntityObjectFactory -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

4
9
0 / 0

[JBoss JIRA] Created: (AS7-775) Specify default values for the urn:jboss:domain:transaction object-store

by Scott Stark (JIRA)

Specify default values for the urn:jboss:domain:transaction object-store ------------------------------------------------------------------------ Key: AS7-775 URL: https://issues.jboss.org/browse/AS7-775 Project: Application Server 7 Issue Type: Feature Request Components: Transactions Affects Versions: 7.0.0.Beta3 Reporter: Scott Stark Assignee: Jason Greene I see the tm file stores being created in whatever the working directory of the server happens to be rather than under the jboss.server.data.dir. It appears that in the absence of a configuration like the following: <subsystem xmlns="urn:jboss:domain:transactions:1.0"> ... <object-store relative-to="jboss.server.data.dir" path="."/> </subsystem> that the TransactionSubsystemAdd should be defaulting to a location under the jboss.server.data.dir, but that does not appear to be working. Either the default needs to be added to the configurations, or corrected in the TransactionSubsystemAdd code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

6
5
0 / 0

[JBoss JIRA] Created: (JGRP-1323) MERGE2 not getting all the coordinators from PING

by vivek v (JIRA)

MERGE2 not getting all the coordinators from PING ------------------------------------------------- Key: JGRP-1323 URL: https://issues.jboss.org/browse/JGRP-1323 Project: JGroups Issue Type: Bug Affects Versions: 2.10 Environment: Windows, Linux Reporter: vivek v Assignee: Bela Ban We got 17 nodes in our group. Due to some node up/down the group got divided into two partitions. One partition had only 2 nodes in it and the other had 16. Even after all the nodes were up we never got the merge between the two partitions. Here is what I see from the logs, 1) On Partition 1 (coordinator: manager_192.168.50.22) {noformat} 2011-05-11 01:18:48,980 TRACE [Timer-1,192.168.50.22_group,manager_192.168.50.22:4576] PING - discovery took 5002 ms: responses: 7 total (7 servers (1 coord), 0 clients) 2011-05-11 01:18:48,980 TRACE [Timer-1,192.168.50.22_group,manager_192.168.50.22:4576] MERGE2 - Discovery results: [manager_192.168.50.22:4576]: [manager_192.168.50.22:4576|19] [manager_192.168.50.22:4576, probe_192.168.50.80:4576] [probe_192.168.50.65:4576]: MergeView::[probe_192.168.50.66:4576|30] [probe_192.168.50.66:4576, probe_192.168.50.64:4576, probe_192.168.50.59:4576, probe_192.168.50.58:4576, probe_192.168.50.81:4576, probe_192.168.50.63:4576, probe_192.168.50.80:4576, collector_192.168.50.23:4576, probe_192.168.50.65:4576, probe_192.168.50.62:4576, probe_192.168.50.60:4576, probe_192.168.50.69:4576, probe_192.168.50.68:4576, probe_192.168.50.83:4576, probe_192.168.50.82:4576, probe_192.168.50.61:4576, probe_192.168.50.67:4576], subgroups=[.. .. 011-05-11 01:18:49,034 DEBUG [ViewHandler,192.168.50.22_group,manager_192.168.50.22:4576] GMS - determining merge leader from [probe_192.168.50.68:4576, probe_192.168.50.66:4576, probe_192.168.50.61:4576, manager_192.168.50.22:4576, probe_192.168.50.69:4576, probe_192.168.50.58:4576, probe_192.168.50.65:4576, probe_192.168.50.60:4576, probe_192.168.50.64:4576, probe_192.168.50.81:4576, probe_192.168.50.67:4576, collector_192.168.50.23:4576, probe_192.168.50.63:4576, probe_192.168.50.82:4576, probe_192.168.50.83:4576, probe_192.168.50.62:4576, probe_192.168.50.59:4576] 2011-05-11 01:18:49,036 DEBUG [ViewHandler,192.168.50.22_group,manager_192.168.50.22:4576] GMS - I (manager_192.168.50.22:4576) am not the merge leader, waiting for merge leader (probe_192.168.50.66:4576) to initiate merge {noformat} 2) On Partition 2 (probe_192.168.50.66) {noformat} 2011-05-10 21:03:07,334 TRACE [Timer-1,192.168.50.22_group,probe_192.168.50.66:4576] PING - discovery took 47 ms: responses: 17 total (17 servers (1 coord), 0 clients) 2011-05-10 21:03:07,335 TRACE [Timer-1,192.168.50.22_group,probe_192.168.50.66:4576] MERGE2 - Discovery results: [probe_192.168.50.66:4576]: MergeView::[probe_192.168.50.66:4576|30] [probe_192.168.50.66:4576, probe_192.168.50.64:4576, probe_192.168.50.59:4576, probe_192.168.50.58:4576, probe_192.168.50.81:4576, probe_192.168.50.63:4576, probe_192.168.50.80:4576, collector_192.168.50.23:4576, probe_192.168.50.65:4576, probe_192.168.50.62:4576, probe_192.168.50.60:4576, probe_192.168.50.69:4576, probe_192.168.50.68:4576, probe_192.168.50.83:4576, probe_192.168.50.82:4576, probe_192.168.50.61:4576, probe_192.168.50.67:4576], subgroups=[[.. {noformat} The FIND_INITIAL_MBRS by second coordinator (probe_192.168.50.66) never get the manager in it's list. We are using Tunnel protocol stack with two Gossip Router. Both the coordinators are talking to the same GR. Here is our PING and MERGE configuration, {code:xml} <PING timeout="5000" num_initial_members="3"/> <MERGE2 max_interval="30000" min_interval="10000"/> {code} On coordinator 2 I also see, {noformat} 2011-05-10 21:05:30,959 WARN [OOB-2330,192.168.50.22_group,probe_192.168.50.66:4576] NAKACK - probe_192.168.50.66:4576: dropped message from manager_192.168.50.22:4576 (not in xmit_table), keys are [probe_192.168.50.60:4576, probe_192.168.50.63:4576, ... ... {noformat} MERGE2 seems to rely on DISCOVERY to get initial members, but for some reason the two partitions are getting different results. Could it be because the Partition 1 got only two members in it so it wait for the other members to give its view as well, but Partition 2 has a long list of members so it gets the view from them and doesn't wait for the Partition 1 list. Partition 1 also seem to wait for the merge leader - do we need to do that? In this case the merge leader never comes by and thus, the merge between two subgroup never happen. I'm not sure where the exact problem is, but I'm opening this as bug as we've seen disjoint groups never merging on quite a few occasions. Attached are detailed logs from the two coordinators. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

5
7
0 / 0

[JBoss JIRA] Created: (JGRP-726) GossipRouter: support GET and REGISTER via UDP datagram packets

by Bela Ban (JIRA)

GossipRouter: support GET and REGISTER via UDP datagram packets --------------------------------------------------------------- Key: JGRP-726 URL: http://jira.jboss.com/jira/browse/JGRP-726 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Vladimir Blagojevic Fix For: 2.8 Currently, GossipRouter supports only TCP. If a GossipClient calls register() or getMembers(), then a TCP connection is established and torn down after the request. This is inefficient and leads to many sockets in TIME_WAIT states (which are cleaned up after 2 * MSL seconds). If we (in GossipRouter) add an additional listener, which listens on a UDP port, and provide the same for GossipClient, we would not use precious TCP sockets. Think about: we should separate the transport in GR from the processing logic, so we could support TCP, UDP, HTTP etc. Should we use JGroups (in unicast mode) for this ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

5
6
0 / 0

[JBoss JIRA] Created: (JGRP-1328) LockService and ExecutionService may drop a message if the coordinator goes down while trying to send a request

by William Burns (JIRA)

LockService and ExecutionService may drop a message if the coordinator goes down while trying to send a request --------------------------------------------------------------------------------------------------------------- Key: JGRP-1328 URL: https://issues.jboss.org/browse/JGRP-1328 Project: JGroups Issue Type: Bug Reporter: William Burns Assignee: Bela Ban I was talking with Bela in regards to this and am not sure if this is an issue or not. It may be that the view change will block the msg, but there is still no way the Service knows to now resend to the new coordinator as it is trying to send to the now down coordinator. This is just here to not forget about the issue and so we can revisit it at a later time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

6
7
0 / 0

[JBoss JIRA] Created: (JGRP-1319) GMS: view acks on MergeView are only required from partition coordinators

by Bela Ban (JIRA)

GMS: view acks on MergeView are only required from partition coordinators ------------------------------------------------------------------------- Key: JGRP-1319 URL: https://issues.jboss.org/browse/JGRP-1319 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 2.12.2, 3.1 When we have a merge of {A,B,C} and {X,Y,Z}, and A and X are the partition coordinators, then view acks for the new combined view {A,B,C,X,Y,Z} will not be received from non coordinator B,C, Y and Z. Therefore, as an optimzation, and to avoid spurious warnings, we should get acks for the MergeView only from A and X. A itself will dissemniate the view locally and should only get acks from A,B,C, and X should only get acks from X,Y,Z, too. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

4
4
0 / 0

[JBoss JIRA] Created: (JGRP-1321) ENCRYPT puts 'illegal' chars into UTF-8 String

by Ken Michie (JIRA)

ENCRYPT puts 'illegal' chars into UTF-8 String ---------------------------------------------- Key: JGRP-1321 URL: https://issues.jboss.org/browse/JGRP-1321 Project: JGroups Issue Type: Bug Affects Versions: 2.12, 2.11, 2.10, 2.9, 2.8, 2.7, 2.6 Environment: Sun JVM and IBM JVM are currently incompatible. IBM is fixing, but still this is a problem since it weakens the strength of the key Reporter: Ken Michie Assignee: Bela Ban Priority: Minor Storing any random byte array into a UTF-8 string causes invalid characters to be replaced with hex value FFFD. Since the IBM JVM currently does this incorrectly (differently from the Sun JVM), 2 nodes on different JVMs (IBM and SUN) using ENCRYPT will not be able to communicate because they calculate different MD5 digest values. Main thread: http://old.nabble.com/ENCRYPT-puts-illegal-chars-into-UTF-8-String-seems-... More description of why UTF-8 does this recplacement: http://en.wikipedia.org/wiki/UTF-8 The fix will possibly make older versions of ENCRYPT incompatible since it will change the calculated MD5 digest value. To fix it, ENCRYPT should be changed from this: private void initSymCiphers(String algorithm, SecretKey secret) throws Exception { ... symVersion=new String(digest.digest(), "UTF-8"); ... } To something like this (byteArrayToHexString() copied from http://jkmessenger.googlecode.com/svn-history/r8/trunk/CryptoUtils.java): private void initSymCiphers(String algorithm, SecretKey secret) throws Exception { ... symVersion = byteArrayToHexString(digest.digest()) ... public static String byteArrayToHexString(byte[] b){ StringBuffer sb = new StringBuffer(b.length * 2); for (int i = 0; i < b.length; i++){ int v = b[i] & 0xff; if (v < 16) { sb.append('0'); } sb.append(Integer.toHexString(v)); } return sb.toString().toUpperCase(); } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

4
8
0 / 0

[JBoss JIRA] Created: (JGRP-763) UnicastChannelTest broken

by Bela Ban (JIRA)

UnicastChannelTest broken ------------------------- Key: JGRP-763 URL: http://jira.jboss.com/jira/browse/JGRP-763 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.8 Caused by moving the starting of threads into handleConnect() (in UDP), however, a unicast channel doesn't send down a CONNECT event. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JGRP-705) Unicast JGroups

by Bela Ban (JIRA)

Unicast JGroups --------------- Key: JGRP-705 URL: http://jira.jboss.com/jira/browse/JGRP-705 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.x Investigate use of JGroups for point-to-point communication, as a replacement for java.net{Server}Socket. E.g. Channelch=new JChannel(); ch.connect(null); // null means p2p -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

2
7
0 / 0

[JBoss JIRA] Created: (JGRP-1318) JMX notifications for view changes, connect/disconnect events

by Bela Ban (JIRA)

JMX notifications for view changes, connect/disconnect events ------------------------------------------------------------- Key: JGRP-1318 URL: https://issues.jboss.org/browse/JGRP-1318 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.12.2, 3.1 Emit JMX notifications for various JGroups events, e.g. - view changes - channel connected / disconnected / closed - local address set -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

2
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2011