July 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-1332) MuxRpcDispatcher: use of topics disturbs invocations

by Benoit Leblanc (JIRA)

MuxRpcDispatcher: use of topics disturbs invocations ---------------------------------------------------- Key: JGRP-1332 URL: https://issues.jboss.org/browse/JGRP-1332 Project: JGroups Issue Type: Bug Affects Versions: 2.12.1 Reporter: Benoit Leblanc Assignee: Bela Ban Scenario 1 : Let's A and B be 2 jgroups members connected to the same channels "rpc". Member A uses an MuxRpcDispatcher with topic id 1 and Member B uses an MuxRpcDispatcher with different topic id, 2 for example. Channel configuration file is « udp.xml ». When Member A sends a multicast rpc call (mode = GET_ALL) with no filter (null), I observed that server object on member B was invoked although it doesn't have the same topic as caller from member A. To better observe invocations, I deployed the attached sample program (Launcher.java) on different machine (member A hosted by 192.168.46.36 and member B hosted by 192.168.46.38) and disable local invocation on channel ( channel.setOpt(Channel.LOCAL, false);). I also use a kind of jgroups sniffer (on host of member B) that logs members exchange. See enclosed file RpcTopic-1ToTopic_2_NoMuxUpHandler.log). Note that topic should be different, so you need to modify sample code before execution on member A or B. Scenario 2: roughly, the same as the previous one. Just set an UpHandler to the channel : channel.setUpHandler(new MuxUpHandler()); I observed that: - Object server on member B wasn't invoked (expected behavior). - Member B didn't respond at all. May be it should send back an ack. See RpcTopic-1ToTopic_2_WithMuxUpHandler.log file. - The invoker (or caller) runs until the timeout kicks in. Or block for ever if timeout = 0. Execution shouldn't runs out "immediately" ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

5
13
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, 7 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, 7 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, 7 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, 7 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, 7 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, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-998) AUTH / FixedMembershipToken: pattern matching and match against logical names

by Bela Ban (JIRA)

AUTH / FixedMembershipToken: pattern matching and match against logical names ----------------------------------------------------------------------------- Key: JGRP-998 URL: https://jira.jboss.org/jira/browse/JGRP-998 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 #1 Use pattern matching to match hosts against senders, using regular expressions. #2 Provide matching of logical names in addition to physical addresses -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

3
6
0 / 0

[JBoss JIRA] Created: (JGRP-1337) ConnectionMap: getConnection() can be a bottleneck

by Bela Ban (JIRA)

ConnectionMap: getConnection() can be a bottleneck -------------------------------------------------- Key: JGRP-1337 URL: https://issues.jboss.org/browse/JGRP-1337 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 3.1 When multiple threads call TcpConnectionMap.Mapper.getConnection() to different target addresses, and some of those addresses are down, then the threads unnecessarily compete for the same lock, therefore socket creations to targets which are up might get delayed by socket creations to targets which are down. SOLUTION: move the actual creation of a socket out of the lock scope NOTE: getConnection() may not even need to acquire the lock as the calling code already acquired it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

3
2
0 / 0

[JBoss JIRA] Created: (JGRP-1316) MPING doesn't always bind to correct interface address

by Daniel Noguerol (JIRA)

MPING doesn't always bind to correct interface address ------------------------------------------------------ Key: JGRP-1316 URL: https://issues.jboss.org/browse/JGRP-1316 Project: JGroups Issue Type: Bug Affects Versions: 2.12.1 Reporter: Daniel Noguerol Assignee: Bela Ban MPING's bindToInterfaces method doesn't take the stack type into consideration. It iterates through all interfaces and addresses but binds to the first address on each interface -- which may not be the correct one based on Util.getIpStackType(). See Workaround Description for workaround solution that worked for me. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

4
4
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 July 2011