[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
[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
[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
[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
[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
[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