January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCLUSTER-173) Require JDK 5

by Brian Stansberry (JIRA)

Require JDK 5 ------------- Key: JBCLUSTER-173 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-173 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Bela Ban Fix For: Q2Y7 Require students to use JDK 5. Interface with the training organization to ensure students and training centers are aware of the requirement. -- 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-166) Shorten the Native Webservers section

by Brian Stansberry (JIRA)

Shorten the Native Webservers section ------------------------------------- Key: JBCLUSTER-166 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-166 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q2Y7 Try to shorten the initial introductory stuff. Remove the IIS stuff. Add a slide before the misc workers.properties slides indicating they are there only for reference in the printed material. -- 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: (JBCLUSTER-168) Update configs in JGroups slides and labs to match stacks.xml

by Brian Stansberry (JIRA)

Update configs in JGroups slides and labs to match stacks.xml --------------------------------------------------------------- Key: JBCLUSTER-168 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-168 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Bela Ban Fix For: Q2Y7 Everywhere possible we should use the best configs. Generally, use udp.xml; tcp.xml or tcp-nio.xml if those transports are relevant. -- 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-165) Trim HA-JMS section and combine with clustered services

by Brian Stansberry (JIRA)

Trim HA-JMS section and combine with clustered services ------------------------------------------------------- Key: JBCLUSTER-165 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-165 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Too much general stuff on JMS and JBossMQ, particularly now that JBossMQ details are not too exciting to people. Until we shift to courseware based on JBoss Messaging, we should trim down the HA-JMS section. Move the few (3) truly HA-JMS slides into Clustered Services presentation. Revamp the configuration slide just to emphasize where things are. Keep the HA-JMS lab. -- 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: (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-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: (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-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 January 2007