July 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-5751) Make max unreplicated time for clustered session configurable in AS 5

by Brian Stansberry (JIRA)

Make max unreplicated time for clustered session configurable in AS 5 --------------------------------------------------------------------- Key: JBAS-5751 URL: http://jira.jboss.com/jira/browse/JBAS-5751 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.CR2 Parent issue doesn't really apply to AS 5, as there have been significant changes in how timestamps are replicated. But, there is a concept of a maximum period after which a timestamp should replicate whether or not the session is dirty. This should be made configurable a la the parent task fix. -- 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

18 years

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5731) JaxWS 2.0 / JaxWS 2.1 support for Branch_4_2

by Jesper Pedersen (JIRA)

JaxWS 2.0 / JaxWS 2.1 support for Branch_4_2 -------------------------------------------- Key: JBAS-5731 URL: http://jira.jboss.com/jira/browse/JBAS-5731 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: EJB3 Reporter: Jesper Pedersen Assigned To: Heiko Braun Priority: Critical Fix For: JBossAS-4.2.3.GA The class org.jboss.ejb3.webservice.WebServiceContextImpl in Branch_4_2 must be able to compile with both JDK5 (JaxWS 2.0) and OpenJDK6 (JaxWS 2.1) which means that the getEndpointReference() methods must be handled. -- 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

18 years

3
7
0 / 0

[JBoss JIRA] Created: (JBAS-5647) HAPartition to support wait for first positive response

by Galder Zamarreno (JIRA)

HAPartition to support wait for first positive response ------------------------------------------------------- Key: JBAS-5647 URL: http://jira.jboss.com/jira/browse/JBAS-5647 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering, Naming Reporter: Galder Zamarreno Assigned To: Galder Zamarreno Fix For: JBossAS-5.0.0.CR2, JBossAS-5.0.0.GA Create a new method in HAPartition or modify an existing one so that we can provide the capability of calling a method cluster wide but waiting only until the first positive response has been received. The definition of positive response would be defined by a RspFilter impl that tells JGroups it's OK to return as soon as a valid response is received. The call would still be GET_ALL. An example of this can be found in JBC's DataGravitationInterceptor.gravitateData() where it filters NNFEs. RspFilter concept doesn't exist in JGroups 2.4, so this won't be implemented for AS 4.x. The use case for this would be the following: Let's say you have a cluster of N nodes and you have a jar deployment in M nodes where M is less than N. A request comes to a node that does not have this jar deployment, so it tries to look it up cluster wide. At this point all M nodes reply with the binding but one of the nodes that didn't have the binding is having GC issues so it does not respond in time. With the current set up, AS would have to wait for all nodes to reply back before it can return any of the positive responses received. The idea here is for positive results to make JGroups return straight back. If M was 1 and this was the node with GC problems, not much we could do. -- 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

18 years

2
4
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2070) Let a portlet developer override the default portlet instance preference configuration screen

by Thomas Heute (JIRA)

Let a portlet developer override the default portlet instance preference configuration screen --------------------------------------------------------------------------------------------- Key: JBPORTAL-2070 URL: http://jira.jboss.com/jira/browse/JBPORTAL-2070 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal Core Admin Reporter: Thomas Heute Fix For: 2.8 Final It could be interesting to let a Portlet developer override the default screen for instances preferences. This could be done by using the optional edit_defaults mode as defined by the spec. The main benefis is to be able to show a custom form instead of the sometimes cryptic preference names. (We can also use the jsf portlet component as used by the page layout) -- 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

18 years

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-5333) Fix object name of the JMS based EJB2 entity cache invalidation mbean

by Brian Stansberry (JIRA)

Fix object name of the JMS based EJB2 entity cache invalidation mbean --------------------------------------------------------------------- Key: JBAS-5333 URL: http://jira.jboss.com/jira/browse/JBAS-5333 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, EJB2 Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.0.CR1 The type attribute in "jboss.cache:service=InvalidationBridge,type=JavaGroups" doesn't make sense for the JMS-based bridge. -- 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

18 years

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-5414) Application class loaders leak to JGroups thread pools

by Brian Stansberry (JIRA)

Application class loaders leak to JGroups thread pools ------------------------------------------------------ Key: JBAS-5414 URL: http://jira.jboss.com/jira/browse/JBAS-5414 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-5.0.0.Beta4 Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.CR1 Application threads carrying messages down can end up creating pool threads in the various JGroups thread pools, and will leak their TCCL to the pool thread. Immediate solution is to have the AS channel factory inject specialized thread pools into the channels it creates. Specialized thread pool will ensure TCCL leaks don't occur, using the same basic approach as was used for JBCOMMON-41. We'll see whether JGroups can add the ability to handle this itself. Also need to ensure that the default domain classloader is the TCCLwhenever the AS (including EJB3 and Hibernate) connects a channel. This will prevent leakage of user deployment classloaders to the many JGroups threads created during Channel.connect(). Currently this isn't an issue as all channels are created as part of deployment of core services where the TCCL is the default domain loader. But, this will become an issue as we switch to lazy-initializing JBoss Cache instances as part of deploying user apps. -- 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

18 years

1
4
0 / 0

[JBoss JIRA] Created: (JBAS-5750) Update the interoperability tests matrix with 4.2.2.GA client libs

by Dimitris Andreadis (JIRA)

Update the interoperability tests matrix with 4.2.2.GA client libs ------------------------------------------------------------------ Key: JBAS-5750 URL: http://jira.jboss.com/jira/browse/JBAS-5750 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Dimitris Andreadis Assigned To: Rajesh Rajasekaran Priority: Critical Fix For: JBossAS-4.2.3.GA -- 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

18 years

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-5568) sample-binding.xml does not work for jboss-messaging-1.4

by Ingo Bruell (JIRA)

sample-binding.xml does not work for jboss-messaging-1.4 -------------------------------------------------------- Key: JBAS-5568 URL: http://jira.jboss.com/jira/browse/JBAS-5568 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Other Affects Versions: JBossAS-4.2.2.GA Environment: jdk 5 and jdk 6 jboss-4.2.2.GA, jboss-messaging-1.4.0.SP3 Reporter: Ingo Bruell The binding manager with sample-bindings.xml from docs/example/... will not work for the actual jboss-messaging. There are some attributes missing. -- 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

18 years

4
7
0 / 0

[JBoss JIRA] Created: (JBAS-5650) Merge clustering fixes from EAP branch

by Brian Stansberry (JIRA)

Merge clustering fixes from EAP branch -------------------------------------- Key: JBAS-5650 URL: http://jira.jboss.com/jira/browse/JBAS-5650 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-4.2.3.GA If we decide to release a 4.2.3, need to check for any significant items fixed in EAP branch and trunk but not ported to Branch_4_2. -- 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

18 years

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5735) Session not reliably bound to SessionReplicationContext if SecurityAssocationValve not present

by Brian Stansberry (JIRA)

Session not reliably bound to SessionReplicationContext if SecurityAssocationValve not present ---------------------------------------------------------------------------------------------- Key: JBAS-5735 URL: http://jira.jboss.com/jira/browse/JBAS-5735 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Affects Versions: JBossAS-5.0.0.CR1, JBossAS-4.2.2.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-4.2.3.GA, JBossAS-5.0.0.CR2 The call in JBossCacheManager.findSession(String id) to SessionReplicationContext.bindSession(...) only binds the session if ClusteredSessionValve has first called SessionReplicationContext.enterWebapp() to establish the context. The problem is, if any code calls Request.getSession(...) before ClusteredSessionValve is invoked, the session will be cached in the request, not bound to the context, and subsequent calls to Request.getSession(...) will use the cached session and never call JBossCacheManager.findSession(...). Result is the session will never be bound to the context and won't be replicated. BatchReplicationClusteredSessionValve calls Request.getSession(...) before ClusteredSessionValve is invoked. SecurityAssocationValve happens to save us, by providentially calling Manager.findSession(...) after the request has passed through ClusteredSessionValve. But that's just good luck; we need to make sure the session is properly bound to the context. -- 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

18 years

1
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 2008