April 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-394) Performance enhancements

by Bela Ban (JIRA)

Performance enhancements ------------------------ Key: JGRP-394 URL: http://jira.jboss.com/jira/browse/JGRP-394 Project: JGroups Issue Type: Task Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 - NAKACK.handleMessage(): NakReceiver.add() --> Retransmitter.add() --> TimeScheduler.add() is quite costly; we also iterate through a linear list when removing a message from the Retransmitter ! -- 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, 11 months

2
7
0 / 0

[JBoss JIRA] Created: (JGRP-281) Investigate whether sent messages need to be buffered in NAKACK

by Bela Ban (JIRA)

Investigate whether sent messages need to be buffered in NAKACK --------------------------------------------------------------- Key: JGRP-281 URL: http://jira.jboss.com/jira/browse/JGRP-281 Project: JGroups Issue Type: Task Affects Versions: 2.3 SP1, 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 NAKACK buffers sent messages in sent-table and received messages in received-table. We might be able to discard sent-table entirely because received-table will contain a message sent by oneself ! Once we have loopback in place by default, we can be sure that any message sent by P will be in P's received-table. -- 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, 11 months

2
10
0 / 0

[JBoss JIRA] Created: (JGRP-461) Add highest_deliverable to NakreceiverWindow

by Bela Ban (JIRA)

Add highest_deliverable to NakreceiverWindow -------------------------------------------- Key: JGRP-461 URL: http://jira.jboss.com/jira/browse/JGRP-461 Project: JGroups Issue Type: Sub-task Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 Currently, we use highest_delivered (= removed) seqno, highest_deliverable would purge more messages faster, if we have a slow receiver (slow to call receive()) -- 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, 11 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-487) Rewrite Retransmitter

by Bela Ban (JIRA)

Rewrite Retransmitter --------------------- Key: JGRP-487 URL: http://jira.jboss.com/jira/browse/JGRP-487 Project: JGroups Issue Type: Task Affects Versions: 2.5 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.6 Attachments: Retransmitter.java The old Retransmitter is (a) too complex and (b) uses a linear list of Entries as retransmission list, which has a cost proportional to the number of messages in the retransmit buffer. We should switch to using simple scheduled futures with the TimeScheduler for retransmissions and cancel the futures when a message has been acked. The new Retransmitter.java is attached -- 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, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-462) NAKACK: remove bundling for retransmitted messages

by Bela Ban (JIRA)

NAKACK: remove bundling for retransmitted messages -------------------------------------------------- Key: JGRP-462 URL: http://jira.jboss.com/jira/browse/JGRP-462 Project: JGroups Issue Type: Task Affects Versions: 2.4.1 SP1 Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.5 In NAKACK, all retransmitted messages are sent in batches (governed by max_xmit_size). This is redundant, as TP also provides bundling. A quick change of code showed that individual retransmissions is as fast as batched retransmission. This functionality can therefore be removed -- 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, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-678) Remove spring dependency

by Geoffrey De Smet (JIRA)

Remove spring dependency ------------------------ Key: JBRULES-678 URL: http://jira.jboss.com/jira/browse/JBRULES-678 Project: JBoss Rules Issue Type: Task Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Once the configuration xml is extracted this should be a peice of cake -- 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, 11 months

1
3
0 / 0

[JBoss JIRA] Created: (JBRULES-642) Extract solver configuration

by Geoffrey De Smet (JIRA)

Extract solver configuration ---------------------------- Key: JBRULES-642 URL: http://jira.jboss.com/jira/browse/JBRULES-642 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Mark Proctor Priority: Critical Preferable into an xml file. Should help to make the integration tests easier to 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, 11 months

3
4
0 / 0

[JBoss JIRA] Created: (JGRP-491) Multiplexer should execute getState for all registered MuxChannel under one FLUSH phase

by Vladimir Blagojevic (JIRA)

Multiplexer should execute getState for all registered MuxChannel under one FLUSH phase --------------------------------------------------------------------------------------- Key: JGRP-491 URL: http://jira.jboss.com/jira/browse/JGRP-491 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1, 2.5 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Fix For: 2.6 The idea behind MuxChannel state transfer listeners is to trigger all state transfers together and have all or none result for all registered MuxChannels. As currently implemented underlying plumbing with will trigger each transfer under *separate* FLUSH. In order to have it done under one flush we have to do manual flushing in Multiplexer (startFlush/stopFlush) for these transfers T and we should retrofit FLUSH protocol *not to* trigger flushing for each GET_STATE from T. We have two options: a) add requireFlush field in StateTransferInfo - that is then passed down with GET_STATE - this requires changing signature of JChannel.getState b) retrofit FLUSH to detect special handling of GET_STATE - at state requester A we record that we requested GET_STATE and if another GET_STATE arrives from A while channel is already flushed do not trigger another flush -- 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, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-3658) Remote classloading service - Redesign

by Dimitris Andreadis (JIRA)

Remote classloading service - Redesign -------------------------------------- Key: JBAS-3658 URL: http://jira.jboss.com/jira/browse/JBAS-3658 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Remoting Reporter: Dimitris Andreadis Assigned To: Tom Elrod Fix For: JBossAS-4.0.6.CR1 We need to redesign the remote classloading service such that there is more control at the deployment layer on what is exposed. I will create a forum thread where this can be discussed in more detail. Requirement 1: Provide sensible defaults, which probably means no remote classloading by default Requirement 2: Individual deployments can choose whether remote classloading is enabled and what is available remotely Requirement 3: Allow "aspects" of the deployment to enhance what can be downloaded remotely, e.g. RMI/IIOP generated proxies or AOP remoting proxies Requirement 4: Use the spec defined RMIClassloaderSPI (exposed via an MBean) to make this configurable Requirement 5: Alternate implementations, e.g. exposure of remote classloading via a servlet in Tomcat or a custom resource url that triggers the use of invokers to do remote classloading. -- 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, 11 months

3
7
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1148) SEAM / JSF / Portlet: Compatibility problem

by JP Barbe (JIRA)

SEAM / JSF / Portlet: Compatibility problem ------------------------------------------- Key: JBPORTAL-1148 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1148 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Portlet Affects Versions: 2.6.CR1 Environment: Windows XP MyFaces 1.1.5 SEAM 1.0.1 Reporter: JP Barbe Assigned To: Julien Viet When I use a seam tag into a jsf page, I have the following exception (You can see config files after the exception): 2006-11-30 17:20:57,934 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/seam-desk]] No active conversation context java.lang.IllegalStateException: No active conversation context at org.jboss.seam.core.Process.instance(Process.java:32) at org.jboss.seam.core.TaskInstance.instance(TaskInstance.java:51) at org.jboss.seam.contexts.BusinessProcessContext.getTaskInstance(BusinessProcessContext.java:213) at org.jboss.seam.contexts.BusinessProcessContext.get(BusinessProcessContext.java:51) at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:155) at org.jboss.seam.Component.getInstance(Component.java:1245) at org.jboss.seam.Component.getInstance(Component.java:1230) at org.jboss.seam.contexts.Lifecycle.resumeConversation(Lifecycle.java:328) at org.jboss.seam.jsf.AbstractSeamPhaseListener.restoreAnyConversationContext(AbstractSeamPhaseListener.java:42) at org.jboss.seam.jsf.SeamPortletPhaseListener.beforePhase(SeamPortletPhaseListener.java:51) at org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener.beforePhase(SeamExtendedManagedPersistencePortletPhaseListener.java:37) at org.apache.myfaces.lifecycle.LifecycleImpl.informPhaseListenersBefore(LifecycleImpl.java:520) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:342) at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:396) at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:266) at com.eads.desk.core.portlet.DeskAccessPortlet.doView(DeskAccessPortlet.java:30) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133) #### Here is the faces-config.xml file: <faces-config> <lifecycle> <phase-listener> org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener </phase-listener> </lifecycle> <navigation-rule> <from-view-id>/view/deskAccess.jsp</from-view-id> <navigation-case> <from-outcome>trManager</from-outcome> <to-view-id>/view/viewTRManager.jsp</to-view-id> <redirect /> </navigation-case> </navigation-rule> <navigation-rule> <navigation-case> <from-action>#{pooledTask.assignToCurrentActor}</from-action> <from-outcome>taskAssignedToActor</from-outcome> <to-view-id>/view/viewTRManager.jsp</to-view-id> </navigation-case> </navigation-rule> </faces-config> #### web.xml: <?xml version="1.0" encoding="UTF-8"?> <web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">  <listener> <listener-class>org.jboss.seam.servlet.SeamListener</listener-class> </listener> </web-app> ### I have seen an issue (Key: JBSEAM-347) but I don't anderstand the solution proposed or if a solution exists ! (http://jira.jboss.org/jira/browse/JBSEAM-347) Thanks. JP. -- 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, 11 months

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