October 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-6842) Unwanted deployment of the shared STLBs

by Miroslav Havram (JIRA)

Unwanted deployment of the shared STLBs --------------------------------------- Key: JBAS-6842 URL: https://jira.jboss.org/jira/browse/JBAS-6842 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployers Affects Versions: JBossAS-5.0.1.GA Reporter: Miroslav Havram Assignee: Ales Justin STLBs from the EAR's lib are deployed even if they are explicitly excluded from deployment. More information can be found on the related forum topic. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 7 months

3
11
0 / 0

[JBoss JIRA] Created: (JBAS-6299) Cluster Performance tuning docs

by Brian Stansberry (JIRA)

Cluster Performance tuning docs ------------------------------- Key: JBAS-6299 URL: https://jira.jboss.org/jira/browse/JBAS-6299 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Docs/Performance Tuning Guide Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-5.1.0.Beta1 Document suggestions for increased performance in a cluster. Off the top of my head, I'm sure there are others, in no particular order: 1) Adjust UDP buffer kernel defaults. 2) Buddy replication for session use case. 3) Separate transport for high load channel. a) Bundling enabled for async use case; udp-async stack 4) No FC for synchronous use case; udp-sync stack. 5) Shorter cluster names. 6) Remove cache loader config from web session cache if not using passivation. 7) TCP for smaller clusters??? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 7 months

2
3
0 / 0

[JBoss JIRA] Commented: (JBAS-7102) Problem sending large files via farm service

by Brian Stansberry (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-7102?page=com.atlassian.jira.plug... ] Brian Stansberry commented on JBAS-7102: ---------------------------------------- I've added a test that farms a 150MB file[1] and it passes, with the test taking < 25 secs to run (which includes time to write out the 150MB file). I'll comment in more detail on the forum thread, but here are a couple suggestions: 1) Stop the hot deployment scanner thread before doing lengthy I/O operations (e.g. copying in files) in the farm/ (or deploy/) folders. Then restart it when I/O is done. This avoids the hot deployment scanning running and seeing partially completed I/O. The scanner can be stopped by invoking the JMX stop() operation on the jboss.deployment:flavor=URL,type=DeploymentScanner MBean. This can be done via the jmx-console or via the twiddle utility in $JBOSS_HOME/bin. 2) Make sure your network is tuned to limit losses of UDP packets. Among other things, increase the OS maximum network read and write buffers; e.g. on Linux sysctl -w net.core.rmem_max=26214400 sysctl -w net.core.wmem_max=1048576 [1] https://svn.jboss.org/repos/jbossas/branches/Branch_5_x/testsuite/src/mai... > Problem sending large files via farm service > -------------------------------------------- > > Key: JBAS-7102 > URL: https://jira.jboss.org/jira/browse/JBAS-7102 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering, ProfileService > Affects Versions: JBossAS-5.1.0.GA > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > Fix For: JBossAS-6.0.0.Alpha1 > > > Users have reported issues sending large files over the AS 5.1 farming service; see forum thread. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-7257) org.jboss.test.deployers.seam.test.Seam*ExampleUnitTestCase

by Shelly McGowan (JIRA)

org.jboss.test.deployers.seam.test.Seam*ExampleUnitTestCase ----------------------------------------------------------- Key: JBAS-7257 URL: https://jira.jboss.org/jira/browse/JBAS-7257 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Shelly McGowan Assignee: Shelly McGowan Fix For: JBossAS-5.2.0.Beta1 SEAM examples failing to deploy with the following error when processing jars in WARs WEB-INF/lib directory: 2009-09-14 13:01:27,760 ERROR [org.apache.catalina.startup.TldConfig] (WorkerThread#0[127.0.0.1:59105]) Exception processing JAR at resource path /work/Branch_5_x/build/output/jboss-5.2.0.Beta1/server/all/tmp/3j001-fc2u1g-fzlgnahp-1-fzlgpa1i-ac/jboss-seam-booking.war/WEB-INF/lib/jboss-seam-debug.jar in context /seam-booking java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:114) at java.util.jar.JarFile.<init>(JarFile.java:133) at java.util.jar.JarFile.<init>(JarFile.java:97) at org.apache.catalina.startup.TldConfig.tldScanJar(TldConfig.java:461) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:301) at org.apache.catalina.core.StandardContext.processTlds(StandardContext.java:4540) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4308) at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:321) at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:146) at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:462) at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118) at org.jboss.web.deployers.WebModule.start(WebModule.java:97) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 7 months

3
11
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2432) PortletRequestDispatcher does not execute 'forward' method during resource request.

by Alexander Smirnov (JIRA)

PortletRequestDispatcher does not execute 'forward' method during resource request. ----------------------------------------------------------------------------------- Key: JBPORTAL-2432 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2432 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Environment: Jboss Portal 2.7 built from http://anonsvn.jboss.org/repos/portal/branches/JBoss_Portal_Branch_2_7 revision 13553 / Jboss AS 4.2.3.GA Reporter: Alexander Smirnov By default, GenericFacesPortlet uses PortletRequestDispatcher.forward method to serve resources during resource requests. The code is: /** * Default resource serving. * <p> * The default implemention of this method is to call a * RequestDispatcher.foward with the ResourceID of the ResourceRequest. * <p> * If no ResourceID is set on the resource URL the default implementation * does nothing. * * @since 2.0 */ public void serveResource(ResourceRequest request, ResourceResponse response) throws PortletException, IOException { if (request.getResourceID() != null) { PortletRequestDispatcher rd = getPortletConfig().getPortletContext().getRequestDispatcher( request.getResourceID()); if (rd != null) rd.forward(request, response); } } Never that code nor custom portletBridge code that uses 'forward' method doesn't work in Jboss Portal but works properly in other Portlet 2.0 implementations. The same PortletRequestDispatcher.forward method works properly during render request. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 7 months

3
3
0 / 0

[JBoss JIRA] Created: (JBVFS-125) Allow for plugable temp location creation

by Ales Justin (JIRA)

Allow for plugable temp location creation ----------------------------------------- Key: JBVFS-125 URL: https://jira.jboss.org/jira/browse/JBVFS-125 Project: JBoss VFS Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.1.3.SP1 Reporter: Ales Justin Assignee: Ales Justin Fix For: 2.2.0.Alpha Users should be able to provide their own mechanism of temp location creation. See the forum post for the actual use case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-7308) wrong attributes in templates for persistence manager and post office configuration

by testrot (JIRA)

wrong attributes in templates for persistence manager and post office configuration ----------------------------------------------------------------------------------- Key: JBAS-7308 URL: https://jira.jboss.org/jira/browse/JBAS-7308 Project: JBoss Application Server Issue Type: Quality Risk Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.1.0.GA Reporter: testrot The templates for the Persistence Manager MBean and Messaging Post Office MBean seem to be wrong (xyz-persistence-service.xml). For example the template for MS SQL (..\docs\examples\jms\mssql-persistence-service.xml) contains the attributes "DetectDuplicates" and "IDCacheSize" in the configuration section for the persistence manager. Shouldn't these attributes belong to the Post Office configuration? At least the "JBoss Messaging 1.4 User's Guide" page 33 suggests this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-1946) Deserializing a KnowledgeBase object throws a java.io.EOFException

by Simon Kelly (JIRA)

Deserializing a KnowledgeBase object throws a java.io.EOFException ------------------------------------------------------------------ Key: JBRULES-1946 URL: https://jira.jboss.org/jira/browse/JBRULES-1946 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.0.0.M5, 5.0.0.M4 Environment: Ubuntu 8.10 Reporter: Simon Kelly Assignee: Mark Proctor A java.io.EOFException is thrown when reading a serialized KnowledgeBase object from a file. java.io.EOFException at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281) at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750) at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780) at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280) at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:55) at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:49) at org.drools.common.AbstractRuleBase.readExternal(AbstractRuleBase.java:227) at org.drools.reteoo.ReteooRuleBase.readExternal(ReteooRuleBase.java:173) at org.drools.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:83) at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at com.sample.DroolsTest.read(DroolsTest.java:75) at com.sample.DroolsTest.testIO(DroolsTest.java:50) at com.sample.DroolsTest.main(DroolsTest.java:40) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 7 months

5
15
0 / 0

[JBoss JIRA] Updated: (JGRP-100) Large-scale JGroups

by Bela Ban (JIRA)

[ https://jira.jboss.org/jira/browse/JGRP-100?page=com.atlassian.jira.plugi... ] Bela Ban updated JGRP-100: -------------------------- Fix Version/s: 2.9 (was: 3.x) > Large-scale JGroups > ------------------- > > Key: JGRP-100 > URL: https://jira.jboss.org/jira/browse/JGRP-100 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.9 > > > - Run JGroups on hundreds of nodes (either physical, or simulation). > - Determine a protocol stack that can be used for large-scale execution > - Example: > - Coordinator may be SPOF. If coord is hung, messages will be sent, but no new views will > be generated > - Retransmission: retransmit from anyone (not sender, otherwise we have NAK implosion) > - Look at PBCAST -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-1044) UNICAST: use actual retransmission values for timeouts

by Bela Ban (JIRA)

UNICAST: use actual retransmission values for timeouts ------------------------------------------------------ Key: JGRP-1044 URL: https://jira.jboss.org/jira/browse/JGRP-1044 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 In NAKACK, we already have use_stats_for_retransmission. Implement the same in UNICAST: Every AckSenderWindow maintains AVG_XMIT_TIME (a double) which is a rolling average of the retransmission times (diff between sending a message and receiving its ACK). Once we have AVG_XMIT_TIME, we schedule retransmission tasks to be AVG_XMIT_TIME + CONST. CONST should be a few millisconds, but could also be 0. The rolling average should start with an initial value (say 30ms), and then add the diff between sending of a message and reception of its ACK, for each ACK received, divided by the number of values. More recent values should be weighted higher, so we have a decay of values over time. We could make this simple by having a bounded number of values, e.g. the last 1000 values. So, assuming a CONST of 10, if we have a rolling average of 350ms to member B, then we would schedule retransmission of our messages to B to 360ms. If the avg drops down to 30, we'd retransmit in 40. If it increases to 2300, we'd go to 2310 etc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 7 months

1
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 October 2009