December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBFORUMS-106) Load it on a server for Beta Testing

by Sohil Shah (JIRA)

Load it on a server for Beta Testing ------------------------------------ Key: JBFORUMS-106 URL: http://jira.jboss.com/jira/browse/JBFORUMS-106 Project: JBoss Forums Issue Type: Task Components: Java Server Faces based UIController layer Affects Versions: 1.0.0 Alpha Reporter: Sohil Shah Assigned To: Sohil Shah Fix For: 1.0.0 Alpha -- 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

17 years, 9 months

2
3
0 / 0

[JBoss JIRA] Updated: (JBFORUMS-85) Identify and Define Training Materials for Portal Training

by Ryszard Kozmik (JIRA)

[ http://jira.jboss.com/jira/browse/JBFORUMS-85?page=all ] Ryszard Kozmik updated JBFORUMS-85: ----------------------------------- Comment: was deleted > Identify and Define Training Materials for Portal Training > ---------------------------------------------------------- > > Key: JBFORUMS-85 > URL: http://jira.jboss.com/jira/browse/JBFORUMS-85 > Project: JBoss Forums > Issue Type: Task > Components: Documentation, Portlet Productization > Affects Versions: 1.0.0 Alpha > Reporter: Damon Sicore > Assigned To: Ryszard Kozmik > Fix For: 1.0.0 RC > > > At a minimum, we need to at least identify the relationships with JBoss Portal training and where JBoss Forums administration and usage concepts are required. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBFORUMS-108) Migrate all of the JBoss.com Forums data to this new Forums

by Sohil Shah (JIRA)

Migrate all of the JBoss.com Forums data to this new Forums ----------------------------------------------------------- Key: JBFORUMS-108 URL: http://jira.jboss.com/jira/browse/JBFORUMS-108 Project: JBoss Forums Issue Type: Sub-task Components: Java Server Faces based UIController layer Affects Versions: 1.0.0 Alpha Reporter: Sohil Shah Assigned To: Sohil Shah Fix For: 1.0.0 Alpha -- 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

17 years, 9 months

2
4
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-92) Integrate and enable multiplex transport

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-92?page=all ] Ovidiu Feodorov closed JBMESSAGING-92. -------------------------------------- Resolution: Out of Date Will use "bisocket" instead. > Integrate and enable multiplex transport > ---------------------------------------- > > Key: JBMESSAGING-92 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-92 > Project: JBoss Messaging > Issue Type: Feature Request > Components: JMS Remoting > Reporter: Ovidiu Feodorov > Assigned To: Ron Sigal > Fix For: 1.2.0.Beta2 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Replace "Connector per Consumer" solution with a Remoting UIL2-like transport > The ConsumerInterceptor creates a new Connector instance per each Consumer, and associates maintains a reference to it as transitory metadata, so it can shut it down when the Consumer closes. > The Connector is necessary as a callback server for asynchronous notifications. The MessageCallbackHandler instance is registered to it. Maintaining an instance per Consumer is necessary to avoid port conflicts. > This is a temporary solution until JBoss Remoting gets an UIL2-like transport. > As long as we maintain a server socket per consumer, it won't be possbile to receive asynchronous notifications over firewalls. > until multiplex performance is better it should not be the default tranport but should be available nevertheless -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBFORUMS-85) Identify and Define Training Materials for Portal Training

by Ryszard Kozmik (JIRA)

[ http://jira.jboss.com/jira/browse/JBFORUMS-85?page=all ] Ryszard Kozmik updated JBFORUMS-85: ----------------------------------- I think there is no hurry yet with this one and I can work on it later. Now there are tasks with bigger priority for Beta release. > Identify and Define Training Materials for Portal Training > ---------------------------------------------------------- > > Key: JBFORUMS-85 > URL: http://jira.jboss.com/jira/browse/JBFORUMS-85 > Project: JBoss Forums > Issue Type: Task > Components: Documentation, Portlet Productization > Affects Versions: 1.0.0 Alpha > Reporter: Damon Sicore > Assigned To: Ryszard Kozmik > Fix For: 1.0.0 Beta > > > At a minimum, we need to at least identify the relationships with JBoss Portal training and where JBoss Forums administration and usage concepts are required. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBFORUMS-84) Package and Add to Portlet Swap

by Ryszard Kozmik (JIRA)

[ http://jira.jboss.com/jira/browse/JBFORUMS-84?page=all ] Ryszard Kozmik updated JBFORUMS-84: ----------------------------------- Fix Version/s: 1.0.0 RC (was: 1.0.0 Beta) The first version which community should start using/testing is in my opinion beta. That's why I'm moving this task to RC release and I'm going to work on that just after the Beta release to get JBoss Forums 1.0.0 Beta on portlet swap. > Package and Add to Portlet Swap > ------------------------------- > > Key: JBFORUMS-84 > URL: http://jira.jboss.com/jira/browse/JBFORUMS-84 > Project: JBoss Forums > Issue Type: Task > Components: Portlet Productization > Affects Versions: 1.0.0 Alpha > Reporter: Damon Sicore > Assigned To: Ryszard Kozmik > Fix For: 1.0.0 RC > > Time Spent: 4 hours > Remaining Estimate: 0 minutes > > Add JBoss Forums to Portlet Swap. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3958) org.jboss.test.txtimer.test.PersistenceTestCase failure with Sun 1.4.2_13

by Len DiMaggio (JIRA)

org.jboss.test.txtimer.test.PersistenceTestCase failure with Sun 1.4.2_13 ------------------------------------------------------------------------- Key: JBAS-3958 URL: http://jira.jboss.com/jira/browse/JBAS-3958 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Suite Affects Versions: JBossAS-4.0.5.GA Environment: OS: Red Hat Enterprise Linux 4/update4 (RHEL4/U4) Arch: i386 JDK: java version "1.4.2_13" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_13-b06) Java HotSpot(TM) Client VM (build 1.4.2_13-b06, mixed mode) Reporter: Len DiMaggio Priority: Minor These (4) tests are failing with the 1.4.2_13 JDK: Suite: org.jboss.test.txtimer.test.PersistenceTestCase Test: testSingleEventDuration Type: failure Exception: junit.framework.AssertionFailedError Message: unexpected handle count expected:<0> but was:<6> junit.framework.AssertionFailedError: unexpected handle count expected:<0> but was:<6> at org.jboss.test.txtimer.test.PersistenceTestCase.testSingleEventDuration(PersistenceTestCase.java:84) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) --------------------------------- Suite: org.jboss.test.txtimer.test.PersistenceTestCase Test: testRestoreToEntity Type: failure Exception: junit.framework.AssertionFailedError Message: unexpected handle count expected:<0> but was:<6> junit.framework.AssertionFailedError: unexpected handle count expected:<0> but was:<6> at org.jboss.test.txtimer.test.PersistenceTestCase.testRestoreToEntity(PersistenceTestCase.java:115) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) --------------------------------- Suite: org.jboss.test.txtimer.test.PersistenceTestCase Test: testRestoreToSession Type: failure Exception: junit.framework.AssertionFailedError Message: unexpected handle count expected:<0> but was:<6> junit.framework.AssertionFailedError: unexpected handle count expected:<0> but was:<6> at org.jboss.test.txtimer.test.PersistenceTestCase.testRestoreToSession(PersistenceTestCase.java:165) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) --------------------------------- Suite: org.jboss.test.txtimer.test.PersistenceTestCase Test: testPersistenceEquality Type: failure Exception: junit.framework.AssertionFailedError Message: unexpected handle count expected:<0> but was:<6> junit.framework.AssertionFailedError: unexpected handle count expected:<0> but was:<6> at org.jboss.test.txtimer.test.PersistenceTestCase.testPersistenceEquality(PersistenceTestCase.java:216) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) -- 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

17 years, 9 months

2
2
0 / 0

[JBoss JIRA] Assigned: (JBMESSAGING-355) Remove possibility of delivery race conditions

by Juha Lindfors (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-355?page=all ] Juha Lindfors reassigned JBMESSAGING-355: ----------------------------------------- Assignee: Tim Fox (was: Juha Lindfors) > Remove possibility of delivery race conditions > ---------------------------------------------- > > Key: JBMESSAGING-355 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-355 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 1.0.2.CR1 > > Attachments: race-condition.log > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Currently race conditions can occur on message delivery where the delivery is acknowledged or cancelled before the call to handle has returned. > In ChannelState we defensively program against this by synchronizing on the returned delivery and by dealing with the situation where the delivery does not exist in the channel state and ignoring. > See ChannelSupport::deliver() and ChannelState.cancelDelivery. > This approach has the following problems: > Complexity of code to maintain and understand. > Where acks return quickly we are likely to get contention on the lock in ChannelSupport::deliver, thus reducing throughput. > A much simpler solution enables us to remove the possibility of such race conditions and remove the corresponding lock contention. > This can be done by adding a confirm() method on Delivery. > When the receiver receives the message in it's handle() call, before dispatching the message it calls Delivery::confirm. This results in the channel adding the delivery to the channel state. Thus we can be assured that the delivery exists before any acknowledgment or cancellation comes in. > This is a very simple change. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBTM-20) Ensure ATS logging capabilities are compatible with JBoss

by Jonathan Halliday (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-20?page=all ] Jonathan Halliday updated JBTM-20: ---------------------------------- Fix Version/s: 4.2.3 (was: 4.4) > Ensure ATS logging capabilities are compatible with JBoss > --------------------------------------------------------- > > Key: JBTM-20 > URL: http://jira.jboss.com/jira/browse/JBTM-20 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JTA Implementation, JTS Implementation > Affects Versions: 4.2.2 > Reporter: Mark Little > Assigned To: Jonathan Halliday > Fix For: 4.2.3 > > Time Spent: 1 day > Remaining Estimate: 0 minutes > > ATS has its own way of logging errors, warnings, debugging etc. Although it follows JDK 1.4 logging specification (and can use log4j as an implementation), we need to ensure it is compatible with the standard way of logging in the result of JBoss. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Commented: (JGRP-130) Problems with reincarnation

by r p (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-130?page=comments#action_12349128 ] r p commented on JGRP-130: -------------------------- As Bela points out we can easily reproduce this condition. Our ideal configuration (for a variety of reasons, esp. network configuration at our datacenters) is a know TCP port for group members. A FIX for this in 2.5 would be greatly appreciated. > Problems with reincarnation > --------------------------- > > Key: JGRP-130 > URL: http://jira.jboss.com/jira/browse/JGRP-130 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.9 > Reporter: Bela Ban > Assigned To: Bela Ban > Fix For: 2.6 > > > Problems with reincarnation > =========================== > Author: Bela Ban > Version: $Id$ > The identity of a JGroups member is always the IP address and a port. The port is usually chosen by the OS, unless > bind_port is set (not set by default). > Let's say a member's address is hostA:5000. When that member dies and is restarted, the OS will likely assign a > higher port, say 5002. This depends on how many other processes requested a port in between the start and restart > of the member. > JGroups relies on the fact that the assignment of ports by the OS is always (not necessarily monotonically) > *increasing* across a single machine. If this is not the case, then the following problems can occur: > 1. Restart: > When a member P crashes and then is restarted, if FD is used and P is restarted *before* it is excluded, > then we have a new member *under the same old address* ! Since it lost all of its state (e.g. retransmission table), > retransmission requests sent to the new P will fail. > 2. Shunning: > Regarding shunning: a member keeps its last N (default is 100) ports used, and makes sure it doesn't reuse one of > those already-used ports when it is shunned. However, this is process-wide and *not* machine-wide, e.g. when we have > processes P1 on A:5000 and P2 on A:5002 (on machine A), and both of them are shunned at the same time, > when they rejoin, P1 does not use port 5000, but might use port 5002, and P2 doesn't use 5002, but might use 5000, so > they could assume each other's identity ! > Both problems cannot be solved by remembering the last 100 ports: in case #1, this list is lost because we start a > new process and in case #2, the list is process-wide, but not machine-wide. > Again, these problems occur *only* when the OS reuses previously assigned ports. > SOLUTION: > A: Use temporary storage (per host) to store the last N addresses assigned on a given host. This makes sure we > don't reuse previous addresses > B: Use logical addresses, such as java.rmi.VMID or java.rmi.server.UID, which are unique over time for a given host. > Then, it doesn't matter what ports we use because the ports are not used to determine a member's identity. > The JIRA task for logical addresses is http://jira.jboss.com/jira/browse/JGRP-129. -- 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

17 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2006