July 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-987) support DeliveryActive MDB activation config property

by William DeCoste (JIRA)

support DeliveryActive MDB activation config property ----------------------------------------------------- Key: EJBTHREE-987 URL: http://jira.jboss.com/jira/browse/EJBTHREE-987 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: AS 4.2.0 GA, EJB 3.0 RC9 - Patch 1 Reporter: William DeCoste Assigned To: William DeCoste -- 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, 3 months

3
12
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1013) Manual merge queue feature via JMX

by Evgueni Smoliar (JIRA)

Manual merge queue feature via JMX ---------------------------------- Key: JBMESSAGING-1013 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1013 Project: JBoss Messaging Issue Type: Feature Request Components: Configuration and Management, JMS Clustering Environment: Clustering/load balancing Reporter: Evgueni Smoliar Assigned To: Tim Fox In a case of disaster recovery you are obliged always to recover last running cluster node. Otherwise some messages will remain in the queue waiting for this node to startup. Idd there is a workaround for this, but it's not always easy to do. Would me much nicer to have a manual function to merge queues ( or reallocate messages) preferably available via JMX. For more detail please check forum. -- 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, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-752) Create safe mode where session concurrent access is checked

by Tim Fox (JIRA)

Create safe mode where session concurrent access is checked ----------------------------------------------------------- Key: JBMESSAGING-752 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-752 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.1 As per JMS spec, a JMS session is supposed to be only accessed from one thread at a time. This is so the implementor does not have to synchronize access which might degrade performance. However, users are often unaware of this and use the session concurrent by multiple threads, resulting in subtle or hard to identify bugs. We should create a "safeMode", where if enabled, concurrent access is checked. safeMode should be turned on for development and off for production, so no performance penalty is incurred in production. -- 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, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1002) Improve order preservation checking

by Tim Fox (JIRA)

Improve order preservation checking ----------------------------------- Key: JBMESSAGING-1002 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1002 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Priority: Minor Fix For: 2.0.0 Beta 1 The current version of order preservation involves preventing messages being sucked from one queue to another more than once. This could be improved by encoding the nodeid/counter for each node sucked from in a header. The counter would be reset every time all consumers are closed on a particular node. A message won't be sucked to a node if its node id is encoded in the header and the distributor's current counter value matches the value in the header. -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4498) JMS Inbound Resource Adapter does not support JMS1.1

by Adrian Brock (JIRA)

JMS Inbound Resource Adapter does not support JMS1.1 ---------------------------------------------------- Key: JBAS-4498 URL: http://jira.jboss.com/jira/browse/JBAS-4498 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.2.0.GA Reporter: Adrian Brock Fix For: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta3 The JMS inbound resource adapter's server session pool does not support old JMS1.0.2b connections. The issue is with JmsServerSession::setup() that only uses the 1.1 api to create sessions. -- 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, 3 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-3774) Synch up with the ide team on use of the VDF

by Scott M Stark (JIRA)

Synch up with the ide team on use of the VDF -------------------------------------------- Key: JBAS-3774 URL: http://jira.jboss.com/jira/browse/JBAS-3774 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Deployment services Reporter: Scott M Stark Assigned To: Dimitris Andreadis Fix For: JBossAS-5.0.0.Beta Part of fleshing out the VDF should be the jbosside integration usecase. -- 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, 3 months

4
8
0 / 0

[JBoss JIRA] Created: (EJBTHREE-889) Up-port SimpleMultiplexer from Branch_4_2

by Carlo de Wolf (JIRA)

Up-port SimpleMultiplexer from Branch_4_2 ----------------------------------------- Key: EJBTHREE-889 URL: http://jira.jboss.com/jira/browse/EJBTHREE-889 Project: EJB 3.0 Issue Type: Task Reporter: Carlo de Wolf Assigned To: Carlo de Wolf Fix For: EJB 3.0 RC11 - FD -- 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, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-544) Use NBIO for connection model

by Tim Fox (JIRA)

Use NBIO for connection model ----------------------------- Key: JBMESSAGING-544 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-544 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.1 For throughput and scalability we need to use a non blocking IO model to provide connections between jms clients and server. Unfortunately the JBoss remoting model does not currently allows this. We can either drive JBoss Remoting to support this model (may take some time) Or write out own connection functionality - this could be fairly straightforward if we use tools such as Apache MINA. This would also solve the problem of providing a functional and performant multiplex transport. Essentially we need a bidirectional channel between jms client and server. On either end bytes can be read or witten in a non blocking fashion. On top of that we can introduce simple framing in order to provide multiplex functionality. -- 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, 3 months

3
9
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-604) Duplicate message detection

by Tim Fox (JIRA)

Duplicate message detection --------------------------- Key: JBMESSAGING-604 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-604 Project: JBoss Messaging Issue Type: Feature Request Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.1 Whereas JMS requires once and only once *delivery* of messages, there are no such guarantees when sending messages to a queue/durable sub. This can result in duplicate messages existing in a queue or durable sub. For some clients this is unacceptable, so we should implement a feature which alerts to the presence of duplicates. This can be done by keeping a persistent cache of message (or transaction) id on the server. Entries should time out after a period of time. This will not remove duplicates 100% of the time since we cannot cache the previous values of id for ever, but only for a window. See forum thread for more details -- 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, 3 months

3
8
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1302) supported-window-states ignored ? no limitation to normal window only.

by Antoine Herzog (JIRA)

supported-window-states ignored ? no limitation to normal window only. ---------------------------------------------------------------------- Key: JBPORTAL-1302 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1302 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.4.1 Final Environment: portal 2.4.1 Reporter: Antoine Herzog Assigned To: Julien Viet In the -object.xml file, remove all window-state elements, but the normal one. <supported-window-states> <window-state>normal</window-state>  </supported-window-states> It does not change anything The min/max icons are still displayed. . And you can still ask for the maximized or minimized state. no exception, the portal still works as usual (with the "classic" all three states enabled). Is it the portal core that should prevent to use these states, if not enabled ? Or the layout strategy and rendering that should not show the icons ? (but then, the portal should warn if we type an url that ask a state that is disabled... even it is not by clicking in the window icon). -- 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, 3 months

2
2
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 2007