February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCLUSTER-162) Add a brief AS clustering overview

by Brian Stansberry (JIRA)

Add a brief AS clustering overview ---------------------------------- Key: JBCLUSTER-162 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-162 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q2Y7 To appear after the JBC material, before EJB3. Some contents: 1) Reiterate locations of config files. 2) Configuration startup switches; -b -g -u etc. 3) Multiplexer discussion. -- 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

19 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-136) Set up project in SVN

by Brian Stansberry (JIRA)

Set up project in SVN --------------------- Key: JBCLUSTER-136 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-136 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q3Y6 Determine where in the repository the project should reside, layout project structure, etc. -- 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

19 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1254) Support UserContexts properly

by Chris Laprun (JIRA)

Support UserContexts properly ----------------------------- Key: JBPORTAL-1254 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1254 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal WSRP Affects Versions: 2.6.Alpha2 Reporter: Chris Laprun Assigned To: Chris Laprun Fix For: 2.6 Final Convert portal identity to WSRP UserContext and back. -- 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

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1020) Replace direct uses of Log4J by JBoss logging.

by Chris Laprun (JIRA)

Replace direct uses of Log4J by JBoss logging. ---------------------------------------------- Key: JBPORTAL-1020 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1020 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.4 Final, 2.2 Branch Reporter: Chris Laprun Priority: Minor Fix For: 2.6.Alpha1 -- 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

19 years, 3 months

3
3
0 / 0

[JBoss JIRA] Created: (JBRULES-664) upgrade GWT version

by Michael Neale (JIRA)

upgrade GWT version ------------------- Key: JBRULES-664 URL: http://jira.jboss.com/jira/browse/JBRULES-664 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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

19 years, 3 months

2
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-848) Implement putFromExternalRead()

by Manik Surtani (JIRA)

Implement putFromExternalRead() ------------------------------- Key: JBCACHE-848 URL: http://jira.jboss.com/jira/browse/JBCACHE-848 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0.GA This is to supercede putFailFast() in JBC 1.x as well as the Option.FAIL_SILENTLY option, for Hibernate to use when doing a DB read and putting the contents into the cache. See forum link for details of 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

19 years, 3 months

2
6
0 / 0

[JBoss JIRA] Created: (JGRP-372) TCP with SSL

by Bela Ban (JIRA)

TCP with SSL ------------ Key: JGRP-372 URL: http://jira.jboss.com/jira/browse/JGRP-372 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4.1 Attachments: tcp_ssl.jar >From Hal Hildebrand: Here's the straight TCP version, as I am still working on the handshake implementation for the TCP_NIO_SSL protocol. This protocol stack element provides security and authentication (using client side authentication) for a JGroups TCP stack. Like the NIO version, this required four minor modifications in the ConnectionTable class. These modifications allow one to subclass to create a connection table which uses SSL for the connections. Finally, there is a new protocol stack element, TCP_SSL, which one can add to a stack to make use of it. As with my previous request, it would be nice to have the changes to ConnectionTable make it into the mainline, as I currently have to overwrite the original class to easily implement this. The mods are simple and innocuous (marked with "HSH"). Right now, the TCP_SSL needs to be configured with an SSLContext. I didn't bother with integrating with the normal JGroups mechanism using properties from the configuration because I consider it inherently insecure to ensconce my passwords in configuration files, but the changes to enable this are straight forward. Currently, to configure the factory for the protocol layer, do something like the following before connecting your channel: // Construct your Jchannel JChannel jchannel = ... // Access your protocol stack ProtocolStack protocolStack = jchannel.getProtocolStack(); // Retrieve the TCP_SSL protocol layer TCP_SSL protocol = (TCP_SSL) protocolStack.findProtocol("TCP_SSL"); // Create your SSLContext SSLContext sslContext = .... // Set up the protocol protocol.setSslContext(sslContext); // Connect your channel jchannel.connnect("my-group"); Cheers. -- 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

19 years, 3 months

3
9
0 / 0

[JBoss JIRA] Created: (JGRP-423) SEQUENCER changes

by Bela Ban (JIRA)

SEQUENCER changes ----------------- Key: JGRP-423 URL: http://jira.jboss.com/jira/browse/JGRP-423 Project: JGroups Issue Type: Task Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 Attachments: cluster-jgroups-config.xml.nopool, SEQUENCER.java, SEQUENCER.java.diff [email from Matthieu Bentot] Hi, Sorry for the late answer. Bela Ban wrote: > Hi Matthieu, > > Matthieu Bentot wrote: > > Hi all, > > > > First off, I wanted to thank everybody for the great job on > > JGroups, which has been very useful to us. > > > > Attached are a few changes we've made (all up to date as of 2.4): - > > TAG (new) is a very simple layer that adds a tag to messages going > > down the stack and prints them on the way up. I found it useful for > > debugging purposes. > > I'll add it if you add javadoc that explains what it does > > > - IDLE (new) simply broadcasts a message with a special tag if > > nothing has been sent in a configurable interval. We had an issue > > with NAKACK where a node would be waiting for an answer to a > > message while the recipient was waiting for the end of a message. > > This may have been resolved since then :-) > > I don't see the point of this. If you discovered a bug, we should fix > ths bug and not add a new protocol. Maybe you ran into the "Last > Message dropped in NAKACK" issue (JGroups/doc/design/varia2.txt) > issue ? This is a matter of changing the timeout in STABLE. You're right of course. It was more of an issue of nodes hanging for a few seconds every so often, really, and that was back in th 2.2 days. I'll try without it with a newer version and to change the timouts. > > - SEQUENCER (update) had a java synchronization issue that was > > causing a deadlock when using a threadless stack (like we do). > > Can you send me a patch against CVS head ? You changed the format, so > I couldn't really see what the changes were all about... > > > Finally, I added a way to bypass ordering, in the form of an empty > > internal header (SEQUENCER.UNORDERED_HEADER). By adding this header > > to a message, an application can tell the SEQUENCER layer that the > > message is not subject to ordering. > > I'd prefer you to use Message.OOB (msg.setFlag(Message.OOB), > msg.isFlagSet(Message.OOB)), that's the right mechanism to bypass > ordering on a per-message basis. > > > This is useful to us because (part of) our application is a > > distributed persistent transactional database; most of the traffic > > is protected by transactions, for which we can avoid the > > performance penalty using this mechanism (I was originally using > > CAUSAL for that reason, even though a total ordering was the > > correct choice). > > Yes, I agree this is useful, but the impl should use the OOB flag > rather than adding a header. Can you change this and re-submit ? Ah, yes, that's much better than the dodgy hack :-). I'm a bit unclear about whether the layer should clear the OOB flag or not before passing down. This version does. I'm not sure a diff will help because I had to change the structure a bit to fix the synchronization issue. The other change I made was to stop sending on a view change until the new coordinator signals that all the members are in the view. This avoids losing messages on startup when nodes join too fast, and then some messages get discarded because the nodes can't decide whether they belong to a view they were in. I also took the opportunity to parameterize the collections. The attached diff is against cvs current. I tried it a few times and it seems to work fine. > > There is another change that will be coming soon (as soon as I get > > it ported to 2.4, unless you want it against 2.3SP1 :-), but it's a > > bit problematic. Simply put, it allows JGroups to use pools for use > > messages and message fragments. > > The experts say we don't need pools anymore, especially in JDK5 where > the VM maintains internal pools anyway. What's your motivation ? > Performance ? Did you mesure a performance increase using pools for > messages ? Yes, I know. However, AFAIK, the experts say that because, with modern GCs, allocation and deallocation are faster on the heap (in the new generation), with the drawback of having a slight pause every so often which is not noticeable anyway in the case of webapps (and most desktop apps). Also pools tend to hog the tenured space even when they're not actually used. I think the situation is bit different in this case because: - the pool is constantly in use; - we're allocating arrays, for which allocation from a pool is much faster, since it doesn't need to initialize them to 0s; - GC pauses are not negligible, because (if the app is high throughput or low-latency) it can cause the other nodes to hold too. So if you pause, say, .5s every 10s, and you got 4 nodes, the cluster can be idling a fifth of the time. If have no real numbers here, and of course good multithreading can help, but you get the idea. Anyway, I ran the JGroups perf bench to compare. 4 nodes transmitting 2GB on 4*Sun v40z, each with 4 opterons, on a dedicated Gig-E LAN (only traffic is JGroups). Sun 1.5.0_10-b03 JVM with 1GB of memory. I attached the non-pooled config. I get the following results (that's the average of the 3 medians of 5 runs). Keep in mind that this is 2.3SP1. size no pool pool 1k 16.2MB/s 15.4MB/s 10k 23.3MB/s 28.8MB/s 100k 26.6MB/s 41.6MB/s 1M 24.9MB/s 42.8MB/s It's worth noting that this config is quite ideal for the GC (few long time references to move out of the new generation, parallel GC on a separate proc). The 1k test uses no pooling (the messages are not fragmented). The 10k one only uses the fragment pool (explaining the lower gain). If the message pool threshold is lowered to include them, it's about 32MB/s. As I mentioned, because of the Message API, it is required to maintain 2 pools, one for fragments, one for messages. This is ungainly and inefficient. If Message didn't expose its internal array, the message pool could go away, and pooling would be more efficient for small messages. It would also save one extra copy. Oh, yeah, cvs seems to be missing the following annotations: org.jgroups.annotations.GuardedBy and import org.jgroups.annotations.Immutable. Regards, Matthieu -- 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

19 years, 3 months

1
5
0 / 0

[JBoss JIRA] Created: (JGRP-421) Investigate correctness of SEQUENCER

by Bela Ban (JIRA)

Investigate correctness of SEQUENCER ------------------------------------ Key: JGRP-421 URL: http://jira.jboss.com/jira/browse/JGRP-421 Project: JGroups Issue Type: Task Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 In the current implementation, each member assigns the seqno. IMO, this should only be done by the coord ! E.g.: - Member forwards msg to coord - Coord assigns seqno and multicasts message to all members - Each member delivers message in order of seqnos, thereby establishing total ordering -- 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

19 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-369) ViewAccepted is not received as expected.

by ￘yvind Eikeland (JIRA)

ViewAccepted is not received as expected. ----------------------------------------- Key: JGRP-369 URL: http://jira.jboss.com/jira/browse/JGRP-369 Project: JGroups Issue Type: Bug Affects Versions: 2.4 Environment: Windows XP. java version "1.6.0-rc" Java(TM) SE Runtime Environment (build 1.6.0-rc-b104) Java HotSpot(TM) Client VM (build 1.6.0-rc-b104, mixed mode, sharing) Version: 2.4.0 CVS: $Id: Version.java,v 1.42 2006/10/31 12:45:32 belaban Exp $ History: (see doc/history.txt for details) Reporter: ￘yvind Eikeland Assigned To: Bela Ban Hi, We're evaluating JGroups and find its functionality very useful so far. We have built an application using State transfer using JChannel.getState() and message sending using PushPullAdapter.send(). We depend on viewAccepted messages to be securely sent and received. I've discovered behaviour that seems like a bug - please advise if we can configure the protocol stack differently to avoid this issue. I've reproduced the behaviour using org.jgroups.demos.Draw application. It happens almost every time. You should be able to do the same. 1. start 3 clients in different dos shells. (java -classpath %CP% org.jgroups.demos.Draw) 2. stop the coordinator client using the "Leave" button in the GUI. Do not kill the VM. A viewAccepted message is sent to the other two apps. A new coordinator is elected by Jgroups. 3. start the first client again. A viewAccepted message is received by all clients 4. kill the coordinator client (kill the VM). I guess this is the same behaviour as if the network was partitioned. Now, only suspect messages are coming through - indefinetely (Draw does not print those messages). A view accepted is not received. If you skip step 2 and 3 above, and only do 1 and 4, a viewAccepted message is sent and it all works. I edited ExtendedReceiverAdapter to print this message for convenience: public void suspect(Address suspected_mbr) { System.out.println("Received suspect: " + suspected_mbr.toString()); } Question: - is this a bug, or is it something wrong with the protocol setup, that we can change to make this work? C:\data\mars\3rdparty\JGroups-2.4.0.src>java -classpath %CP% org.jgroups.demos.D raw log4j:WARN No appenders could be found for logger (org.jgroups.JChannel). log4j:WARN Please initialize the log4j system properly. ------------------------------------------------------- GMS: address is 192.168.2.128:2143 ------------------------------------------------------- ** View=[192.168.2.128:2136|4] [192.168.2.128:2136, 192.168.2.128:2139, 192.168. 2.128:2143] Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 -- 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

19 years, 3 months

4
10
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 February 2007