December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-383) Port of JGRP-380 to 2.5

by Bela Ban (JIRA)

Port of JGRP-380 to 2.5 ----------------------- Key: JGRP-383 URL: http://jira.jboss.com/jira/browse/JGRP-383 Project: JGroups Issue Type: Task Affects Versions: 2.4.1 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 -- 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, 7 months

1
1
0 / 0

[JBoss JIRA] Resolved: (JGRP-205) Out-of-band messages

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-205?page=all ] Bela Ban resolved JGRP-205. --------------------------- Resolution: Done - Added Message.setFlags(): message now has flags (e.g. OOB) - UNICAST and NAKACK now handle OOB messages correctly (JGRP-377/379) - Most protocols were changed to use OOB messages for asynchronous messages where ordering is not important > Out-of-band messages > -------------------- > > Key: JGRP-205 > URL: http://jira.jboss.com/jira/browse/JGRP-205 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.8, 2.2.9, 2.3, 2.2.9.1 > Reporter: Bela Ban > Assigned To: Bela Ban > Fix For: 2.5 > > > We need to be able to tag individual messages with a quality-of-service bit: ASYNC. This means that, when such a message is received, it can be delivered asynchronously, e.g. by a thread from a separate threadpool (compared this to http://jira.jboss.com/jira/browse/JGRP-181). > Examples for OOB messages: > - ACKs (unicast) > - XMIT requests (NAKACK) > - Credit replenishment messages (FC) > - Failure detection: heartbeats and are-you-alive messages, plus acks > We might even introduce priority based message delivery > One example for FC: > - We have members A and B > - A and B continuously invoke put()s on the TreeCache in *synchronous* mode > - When B receives a put() request, it applies it and wants to send the response. However, assume that the response is blocked in FC.down() because we don't have enough credits available to send the response to A > - Now A sent a REPLENISH message to B, but B is still stuck in the FC.down() method, which blocks the *up thread* ! > - Therefore B cannot handle the replenishment message from A and therefore won't unblock: deadlock ! > - If we could deliver the REPLENISH message from A to B *on a separate thread*, B would receive the REPLENISH message and unblock the FC.down() method -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-379) CLONE -TLS: implement OOB handling in NAKACK

by Bela Ban (JIRA)

CLONE -TLS: implement OOB handling in NAKACK -------------------------------------------- Key: JGRP-379 URL: http://jira.jboss.com/jira/browse/JGRP-379 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 - How are OOB messages handled by UNICAST and NAKACK ? Are these 2 effectively ignoring OOB flags ? Does it make sense to use OOB messages in protocols *above* UNICAST or NAKACK ? Exampe: GMS sending VIEW_ACK messages. Logic in UNICAST: - Receive OOB message, place in receiver table - Pass up the OOB message *immediately*, regardless of whether it is in sequence ! - When message is finally removed, do *NOT* pass it up when marked as OOB ! Example (for UNICAST): - We receive 1, 2, 4(OOB) , 5 - Messages 1 and 2 are delivered and removed from the table (AckReceiverTable) - Message 4 is added to AckReceiverWindow and *delivered* (passed up) - Message 3 is received, added to AckReceiverWindow and delivered - Message 4 is removed, but *not* delivered because it has already been delivered - Message 5 is removed from AckreceiverWindow and delivered This means that if we mark a message as OOB, that message may be delivered out-of-order, e.g. in the above example, the application will get 1, 2, 4, 3, 5 ! Therefore, an application has to think twice before marking a unicast or multicast message as OOB ! A similar scheme will be applied for NAKACK messages -- 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, 7 months

1
2
0 / 0

[JBoss JIRA] Updated: (JBAS-2222) Add support to LdapExtLoginModule for user searches that return a referral

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2222?page=all ] Dimitris Andreadis updated JBAS-2222: ------------------------------------- Fix Version/s: JBossAS-4.2.1.CR1 (was: JBossAS-4.2.0.CR1) Assignee: Anil Saldhana > Add support to LdapExtLoginModule for user searches that return a referral > -------------------------------------------------------------------------- > > Key: JBAS-2222 > URL: http://jira.jboss.com/jira/browse/JBAS-2222 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: JBossAS-4.0.3 Final > Reporter: Scott M Stark > Assigned To: Anil Saldhana > Fix For: JBossAS-4.2.1.CR1 > > > The current LdapExtLoginModule cannot handle a user search that returns a referral. We need to look into supporting following the referral to authenticate the user against the target server. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2222) Add support to LdapExtLoginModule for user searches that return a referral

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2222?page=all ] Dimitris Andreadis updated JBAS-2222: ------------------------------------- Component/s: Security > Add support to LdapExtLoginModule for user searches that return a referral > -------------------------------------------------------------------------- > > Key: JBAS-2222 > URL: http://jira.jboss.com/jira/browse/JBAS-2222 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: JBossAS-4.0.3 Final > Reporter: Scott M Stark > Assigned To: Anil Saldhana > Fix For: JBossAS-4.2.1.CR1 > > > The current LdapExtLoginModule cannot handle a user search that returns a referral. We need to look into supporting following the referral to authenticate the user against the target server. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2330) Create Hibernate based timer persistence layer

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2330?page=all ] Dimitris Andreadis updated JBAS-2330: ------------------------------------- Fix Version/s: (was: JBossAS-4.2.0.CR1) > Create Hibernate based timer persistence layer > ---------------------------------------------- > > Key: JBAS-2330 > URL: http://jira.jboss.com/jira/browse/JBAS-2330 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Scott M Stark > > In the update of the timer service to support persistence independent of the server lifecycle, we should move to a hibernate based pm as opposed to screwing around with sql. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-377) TLS: implement OOB handling in UNICAST and NAKACK

by Bela Ban (JIRA)

TLS: implement OOB handling in UNICAST and NAKACK ------------------------------------------------- Key: JGRP-377 URL: http://jira.jboss.com/jira/browse/JGRP-377 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 - How are OOB messages handled by UNICAST and NAKACK ? Are these 2 effectively ignoring OOB flags ? Does it make sense to use OOB messages in protocols *above* UNICAST or NAKACK ? Exampe: GMS sending VIEW_ACK messages. Logic in UNICAST: - Receive OOB message, place in receiver table - Pass up the OOB message *immediately*, regardless of whether it is in sequence ! - When message is finally removed, do *NOT* pass it up when marked as OOB ! Example (for UNICAST): - We receive 1, 2, 4(OOB) , 5 - Messages 1 and 2 are delivered and removed from the table (AckReceiverTable) - Message 4 is added to AckReceiverWindow and *delivered* (passed up) - Message 3 is received, added to AckReceiverWindow and delivered - Message 4 is removed, but *not* delivered because it has already been delivered - Message 5 is removed from AckreceiverWindow and delivered This means that if we mark a message as OOB, that message may be delivered out-of-order, e.g. in the above example, the application will get 1, 2, 4, 3, 5 ! Therefore, an application has to think twice before marking a unicast or multicast message as OOB ! A similar scheme will be applied for NAKACK messages -- 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, 7 months

1
3
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1158) Secure instances in dashboard configurator

by Roy Russo (JIRA)

Secure instances in dashboard configurator ------------------------------------------ Key: JBPORTAL-1158 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1158 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.Alpha1 Reporter: Roy Russo Assigned To: Roy Russo Fix For: 2.6.Alpha1 User should not be allowed to add instances that are secured to him. -- 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, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1159) portal testsuite with derby database

by Prabhat Jha (JIRA)

portal testsuite with derby database ------------------------------------ Key: JBPORTAL-1159 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1159 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal CMS Reporter: Prabhat Jha Assigned To: Roy Russo After sybase problem, we seem to have stumbled across another issue while running portal testsuite against apache derby database. I am going to check in derby database config to regular portal testsuite run so that when the problem is fixed, it's reflected. I do see portal database created on derby side so there should not be any driver/connection issue. I see following error when testsuite tries to create tables on derby: [junit_] 14:54:19,819 INFO [SchemaExport] exporting generated schema to database [junit_] 14:54:20,041 ERROR [SchemaExport] Unsuccessful: create table jbp_cms_version_node (PK integer not null, NODE_ID varchar(36), NODE_DATA varchar(100000000) for bit data not null, primary key (PK)) [junit_] 14:54:20,041 ERROR [SchemaExport] The length, precision, or scale attribute for column, or type mapping 'VARCHAR (100000000) FOR BIT DATA' is not valid. [junit_] 14:54:20,045 ERROR [SchemaExport] Unsuccessful: create table jbp_cms_version_prop (PK integer not null, PROP_ID varchar(255), PROP_DATA varchar(100000000) for bit data not null, primary key (PK)\ ) [junit_] 14:54:20,045 ERROR [SchemaExport] The length, precision, or scale attribute for column, or type mapping 'VARCHAR (100000000) FOR BIT DATA' is not valid. [junit_] 14:54:20,052 ERROR [SchemaExport] Unsuccessful: create table jbp_cms_version_refs (PK integer not null, NODE_ID varchar(36), REFS_DATA varchar(100000000) for bit data not null, primary key (PK)) [junit_] 14:54:20,052 ERROR [SchemaExport] The length, precision, or scale attribute for column, or type mapping 'VARCHAR (100000000) FOR BIT DATA' is not valid. [junit_] 14:54:20,164 ERROR [SchemaExport] Unsuccessful: create table jbp_cms_wsp_node (PK integer not null, NODE_ID varchar(36), NODE_DATA varchar(100000000) for bit data not null, primary key (PK)) [junit_] 14:54:20,164 ERROR [SchemaExport] The length, precision, or scale attribute for column, or type mapping 'VARCHAR (100000000) FOR BIT DATA' is not valid. [junit_] 14:54:20,172 ERROR [SchemaExport] Unsuccessful: create table jbp_cms_wsp_prop (PK integer not null, PROP_ID varchar(255), PROP_DATA varchar(100000000) for bit data not null, primary key (PK)) [junit_] 14:54:20,172 ERROR [SchemaExport] The length, precision, or scale attribute for column, or type mapping 'VARCHAR (100000000) FOR BIT DATA' is not valid. [junit_] 14:54:20,177 ERROR [SchemaExport] Unsuccessful: create table jbp_cms_wsp_refs (PK integer not null, NODE_ID varchar(36), REFS_DATA varchar(100000000) for bit data not null, primary key (PK)) [junit_] 14:54:20,177 ERROR [SchemaExport] The length, precision, or scale attribute for column, or type mapping 'VARCHAR (100000000) FOR BIT DATA' is not valid. [junit_] 14:54:20,238 INFO [SchemaExport] schema export complete Looks like 10x10^7 is a big number for derby. Just a note: tck5 tests are run with derby so database should be able to handle regular database needs. -- 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, 7 months

1
1
0 / 0

[JBoss JIRA] Updated: (JBAS-3023) Bad interaction between farming/ha proxies

by Scott Marlow (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3023?page=all ] Scott Marlow updated JBAS-3023: ------------------------------- Fix Version/s: JBossAS-4.2.1.CR1 (was: JBossAS-4.2.0.CR1) > Bad interaction between farming/ha proxies > ------------------------------------------ > > Key: JBAS-3023 > URL: http://jira.jboss.com/jira/browse/JBAS-3023 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering, Deployment services > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Scott M Stark > Assigned To: Scott Marlow > Fix For: JBossAS-4.2.1.CR1 > > > At least two forum thread indicate there is a problem with farmed deployments breaking ha proxy behavior when one application is undeployed: > http://www.jboss.com/index.html?module=bb&op=viewtopic&t=80011 > http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77986 -- 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, 7 months

1
0
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 December 2006