[JBoss JIRA] Commented: (JBAS-3268) FormAuthenticator has copy/paste error
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3268?page=comments#action_12339967 ]
Dimitris Andreadis commented on JBAS-3268:
------------------------------------------
Anil, can you please fix this in the jboss codebase and close it? If there is something to be fixed in the tomcat codebase, that should be openned in their bug tracking system, and linked from here instead (I guess).
> FormAuthenticator has copy/paste error
> --------------------------------------
>
> Key: JBAS-3268
> URL: http://jira.jboss.com/jira/browse/JBAS-3268
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Tomcat) service
> Affects Versions: JBossAS-4.0.2 Final, JBossAS-4.0.3 SP1, JBossAS-4.0.4.GA
> Reporter: Anil Saldhana
> Assigned To: Remy Maucherat
> Priority: Minor
> Fix For: JBossAS-4.0.5.CR1
>
>
> The matchRequest method of the FormAuthenticator is trying to match a URI with itself as indicated at the end of the method:
> ==================================================
> // Does the request URI match?
> String requestURI = request.getRequestURI();
> if (requestURI == null)
> return (false);
> return (requestURI.equals(request.getRequestURI()));
> ==================================================
> It should be:
> ========================================================
> // Does the request URI match?
> String requestURI = request.getRequestURI();
> if (requestURI == null)
> return (false);
> return (requestURI.equals(sreq.getRequestURI()));
> =======================================================
> This affects both org.jboss.web.tomcat.security.FormAuthenticator and
> http://svn.apache.org/repos/asf/tomcat/container/tc5.5.x/catalina/src/sha...
--
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
19 years, 12 months
[JBoss JIRA] Updated: (JBAS-3355) DetachedHANamingService does not register its ObjectName with Registry
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3355?page=all ]
Dimitris Andreadis updated JBAS-3355:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
> DetachedHANamingService does not register its ObjectName with Registry
> ----------------------------------------------------------------------
>
> Key: JBAS-3355
> URL: http://jira.jboss.com/jira/browse/JBAS-3355
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, Naming
> Affects Versions: JBossAS-4.0.4.GA
> Reporter: Brian Stansberry
> Assigned To: Brian Stansberry
> Priority: Minor
> Fix For: JBossAS-4.0.6.CR1
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> DetachedHANamingService does not register its ObjectName with Registry. Because of this, if it is used with ProxyFactoryHA and JRMPInvokerHA, calls to it will fail in JRMPInvokerHA.invoke due to a failure lookup the ObjectName in the registry.
> The purpose of having DetachedHANamingService as a distinct base class from HANamingService is to allow use with the detached invokers, so not having this work kind of defeats the point.
--
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
19 years, 12 months
[JBoss JIRA] Updated: (JBAS-3199) Tomcat consuming 99, 9% CPU
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3199?page=all ]
Dimitris Andreadis updated JBAS-3199:
-------------------------------------
Fix Version/s: (was: JBossAS-4.0.5.CR1)
Priority: Major (was: Minor)
> Tomcat consuming 99,9% CPU
> --------------------------
>
> Key: JBAS-3199
> URL: http://jira.jboss.com/jira/browse/JBAS-3199
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Tomcat) service
> Affects Versions: JBossAS-4.0.3 SP1
> Environment: SUSE LINUX 10.0 (X86-64)
> VERSION = 10.0
> java version "1.5.0_03"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
> Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_03-b07, mixed mode)
> Reporter: Petri Rautakoski
> Assigned To: Remy Maucherat
>
> Suddenly Tomcat reserves all CPU resources. When investigated from web-console we get statcktrace for thread consuming CPU:
> Thread: http-0.0.0.0-6060-46 : priority:5, demon:true, threadId:1155, threadState:RUNNABLE, threadLockName:null
> java.lang.StrictMath.floor(Native Method)
> java.lang.Math.floor(Math.java:407)
> org.apache.naming.resources.ResourceCache.allocate(ResourceCache.java:233)
> org.apache.naming.resources.ProxyDirContext.cacheLoad(ProxyDirContext.java:1599)
> org.apache.naming.resources.ProxyDirContext.cacheLookup(ProxyDirContext.java:1448)
> org.apache.naming.resources.ProxyDirContext.lookupCache(ProxyDirContext.java:1376)
> org.apache.catalina.servlets.DefaultServlet.renderHtml(DefaultServlet.java:1314)
> org.apache.catalina.servlets.DefaultServlet.render(DefaultServlet.java:1102)
> org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:807)
> org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:335)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> java.lang.Thread.run(Thread.java:595)
--
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
19 years, 12 months
[JBoss JIRA] Updated: (JBAS-3325) Remove old code
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3325?page=all ]
Dimitris Andreadis updated JBAS-3325:
-------------------------------------
Issue Type: Bug (was: Task)
Assignee: Dimitris Andreadis
Priority: Major (was: Optional)
>From a quick look, the code might seems obsolete but "java.rmi.server.hostname" is not used at all, so I changed this to a bug and assigned to myself, in case I find the time to look at it for 4.0.5.CR1
> Remove old code
> ---------------
>
> Key: JBAS-3325
> URL: http://jira.jboss.com/jira/browse/JBAS-3325
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Other
> Affects Versions: JBossAS-4.0.4.GA
> Environment: JBoss 4.0.3.SP1
> $ java -version
> java version "1.4.2_12"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_12-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_12-b03, mixed mode)
> $ java -version
> java version "1.5.0_07"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
> Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode, sharing)
> Reporter: Robert Schroeder
> Assigned To: Dimitris Andreadis
> Fix For: JBossAS-4.0.5.CR1
>
>
> http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingJBossBehindAFirewall mentions the parameter "java.rmi.server.hostname" to set if the external host name differs from the local host (e.g. server machine is behind a firewall)
> But org.jboss.web.WebService doesn'r recognize this parameter:
> String hostname = server.getBindAddress(); // this always returns something, at least "0.0.0.0"!
> // If not user specified hostname given, then try to determine what it should be
> if (hostname == null) //this branch is never executed!
> {
> // First look for the rmi server name
> try
> {
> hostname = System.getProperty("java.rmi.server.hostname"); // this parameter is not recognized as this branch is never executed
> }
> catch (SecurityException e)
> {
> // ignore, but don't be silent
> ThrowableHandler.addWarning(e);
> }
> // else use the localhost name
> if (hostname == null)
> {
> try
> {
> hostname = InetAddress.getLocalHost().getHostName();
> }
> catch (IOException e)
> {
> log.error("Failed to get localhost name; ignoring", e);
> }
> }
> if (hostname != null)
> {
> setHost(hostname);
> }
> }
> // Host must be set to continue (either by user or detection)
> String address = getHost();
> if (address == null)
> throw new MissingAttributeException("Host");
> // Set the rmi codebase if it is not already set
> String codebase = System.getProperty("java.rmi.server.codebase");
> if (codebase == null)
> {
> address = ServerConfigUtil.fixRemoteAddress(address);
> codebase = "http://" + address + ":" + getPort() + "/";
> System.setProperty("java.rmi.server.codebase", codebase);
> }
> log.info("Using RMI server codebase: " + codebase);
> So the resulting problem is that codebase contains an address which is not reachable from the other side of firewall because "java.rmi.server.hostname" is not recognized (same for "-Djava.rmi.server.useLocalHostname=false" )
> Example:
> JBoss started with parameter set "-Djava.rmi.server.hostname=as2.subdomain1.subdomain2.test.com"
> but (thanks to rmi logging) the proxy objects on client side have codebase set to "http://as2:<port>" and not to "http://as2.subdomain1.subdomain2.test.com:<port>" as expected.
> JBoss 4 runs on a linux machine
> hostname --> "as2"
> hostname -f --> "as2.subdomain1.subdomain2.test.com"
--
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
19 years, 12 months
[JBoss JIRA] Updated: (JBAS-2635) Performance enhancements to JDBC2 CMP
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2635?page=all ]
Dimitris Andreadis updated JBAS-2635:
-------------------------------------
Priority: Minor (was: Optional)
> Performance enhancements to JDBC2 CMP
> -------------------------------------
>
> Key: JBAS-2635
> URL: http://jira.jboss.com/jira/browse/JBAS-2635
> Project: JBoss Application Server
> Issue Type: Patch
> Security Level: Public(Everyone can see)
> Components: CMP service
> Affects Versions: JBossAS-4.0.3 SP1
> Environment: Linux/Windows
> Reporter: David Strong
> Assigned To: Alexey Loubyansky
> Priority: Minor
> Fix For: JBossAS-4.0.5.CR1
>
> Attachments: jboss-jdbc2-patches.tar.gz
>
>
> Unisys Patches For JDBC2
> Unisys have made some patches to four of the JDBC2 files:
> $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/bridge/JDBCCMPFieldBridge2.java
> $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/schema/EntityTable.java
> $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/schema/PartitionedTableCache.java
> $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/schema/TableCache.java
> All changes are tagged with /// UIS and some brief comments. Some changes have been made to JDBCCMPFieldBridge2.java and EntityTable.java to cache frequently used objects such as entity fields and primary keys.
> The majority of changes relate to the interaction between EntityTable.java, PartitionedTableCache.java and TableCache.java.
> Consider the following situation. An EJB requires a row from the database. EntityTable.java contains an inner View class. The View seems to be instantiated per transaction. The View is asked to locate the row in question. First, the View looks to an internal cache. If the row exists, it is returned. If not, PartitionedTableCache.java and then TableCache.java are used to determine if the row is in their cache. If the row exists, it is returned. If not, the View loads the row from the database and places it into its own cache. At the end of the transaction in question, the View flushes its cache into the TableCache.java cache. The next transaction along will get a new View and the process starts again.
> This mechanism is adequate if rows are being updated. In this case, TableCache.java will hold a clean copy of the row, the View will update a copy of the row and then copy it back to TableCache.java in the case of a commit or not in the case of a rollback.
> However, in the case of a read only transaction, there is a lot of wasted overhead with object creation and copies that don?t really need to occur.
> The UIS patches to EntityTable.java, PartitionedTableCache.java and TableCache.java provide a prototype that does not make excessive copies of objects when a bean is marked as read only.
> Another patch to this area allows rows, from read only tables, to be preloaded at startup time. This allows the code to access caches without locking them and does not require the row promotion logic within TableCache.java to be executed. This prototype should only be used for small, static tables.
> The patches are enabled when the <read-only-cache> and <pre-load-rows> elements appear in the jboss.xml file for a specific EJB. A sample jboss.xml file is shown below:
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <!DOCTYPE jboss PUBLIC
> "-//JBoss//DTD JBOSS 3.2//EN"
> "http://www.jboss.org/j2ee/dtd/jboss_3_2.dtd">
> <jboss>
> <enterprise-beans>
> <entity>
> <ejb-name>SomeEJB</ejb-name>
> <configuration-name>SomeEJB</configuration-name>
> </entity>
> </enterprise-beans>
> <container-configurations>
> <container-configuration extends="Standard CMP 2.x EntityBean">
> <container-name>SomeEJB</container-name>
> <container-invoker-conf>
> <Optimized>True</Optimized>
> </container-invoker-conf>
> <container-cache-conf>
> <cache-policy-conf>
> <min-capacity>100</min-capacity>
> <max-capacity>100</max-capacity>
> </cache-policy-conf>
> <cache-policy-conf-other>
> <partitions>1</partitions>
> <read-only-cache>true</read-only-cache>
> <pre-load-cache>true</pre-load-cache>
> </cache-policy-conf-other>
> </container-cache-conf>
> </container-configuration>
> </container-configurations>
> </jboss>
> Although the prototype code seems to work well ? we?ve observed a 20% improvement in throughput in some test cases as well as lower CPU usage, better response times, less garbage created - we believe a better scheme could be used for read only transactions of this nature. We will investigate the possibility of using a different View for read only transactions, possibly reusing the same View for all read only transactions. The intent would be to provide caching at the View level only, to further reduce the overhead of unnecessary objection creation and copies.
> Another area of further investigation would be focused on the use of common caches between related entities. At present, it looks like entity relationships cause the same tables to be cached by different instances of EntityTable.java.
--
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
19 years, 12 months
[JBoss JIRA] Assigned: (JBAS-2635) Performance enhancements to JDBC2 CMP
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2635?page=all ]
Dimitris Andreadis reassigned JBAS-2635:
----------------------------------------
Assignee: Alexey Loubyansky (was: Clebert Suconic)
Alex, have you looked at the modifications, do you agree with them?
> Performance enhancements to JDBC2 CMP
> -------------------------------------
>
> Key: JBAS-2635
> URL: http://jira.jboss.com/jira/browse/JBAS-2635
> Project: JBoss Application Server
> Issue Type: Patch
> Security Level: Public(Everyone can see)
> Components: CMP service
> Affects Versions: JBossAS-4.0.3 SP1
> Environment: Linux/Windows
> Reporter: David Strong
> Assigned To: Alexey Loubyansky
> Priority: Optional
> Fix For: JBossAS-4.0.5.CR1
>
> Attachments: jboss-jdbc2-patches.tar.gz
>
>
> Unisys Patches For JDBC2
> Unisys have made some patches to four of the JDBC2 files:
> $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/bridge/JDBCCMPFieldBridge2.java
> $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/schema/EntityTable.java
> $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/schema/PartitionedTableCache.java
> $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/schema/TableCache.java
> All changes are tagged with /// UIS and some brief comments. Some changes have been made to JDBCCMPFieldBridge2.java and EntityTable.java to cache frequently used objects such as entity fields and primary keys.
> The majority of changes relate to the interaction between EntityTable.java, PartitionedTableCache.java and TableCache.java.
> Consider the following situation. An EJB requires a row from the database. EntityTable.java contains an inner View class. The View seems to be instantiated per transaction. The View is asked to locate the row in question. First, the View looks to an internal cache. If the row exists, it is returned. If not, PartitionedTableCache.java and then TableCache.java are used to determine if the row is in their cache. If the row exists, it is returned. If not, the View loads the row from the database and places it into its own cache. At the end of the transaction in question, the View flushes its cache into the TableCache.java cache. The next transaction along will get a new View and the process starts again.
> This mechanism is adequate if rows are being updated. In this case, TableCache.java will hold a clean copy of the row, the View will update a copy of the row and then copy it back to TableCache.java in the case of a commit or not in the case of a rollback.
> However, in the case of a read only transaction, there is a lot of wasted overhead with object creation and copies that don?t really need to occur.
> The UIS patches to EntityTable.java, PartitionedTableCache.java and TableCache.java provide a prototype that does not make excessive copies of objects when a bean is marked as read only.
> Another patch to this area allows rows, from read only tables, to be preloaded at startup time. This allows the code to access caches without locking them and does not require the row promotion logic within TableCache.java to be executed. This prototype should only be used for small, static tables.
> The patches are enabled when the <read-only-cache> and <pre-load-rows> elements appear in the jboss.xml file for a specific EJB. A sample jboss.xml file is shown below:
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <!DOCTYPE jboss PUBLIC
> "-//JBoss//DTD JBOSS 3.2//EN"
> "http://www.jboss.org/j2ee/dtd/jboss_3_2.dtd">
> <jboss>
> <enterprise-beans>
> <entity>
> <ejb-name>SomeEJB</ejb-name>
> <configuration-name>SomeEJB</configuration-name>
> </entity>
> </enterprise-beans>
> <container-configurations>
> <container-configuration extends="Standard CMP 2.x EntityBean">
> <container-name>SomeEJB</container-name>
> <container-invoker-conf>
> <Optimized>True</Optimized>
> </container-invoker-conf>
> <container-cache-conf>
> <cache-policy-conf>
> <min-capacity>100</min-capacity>
> <max-capacity>100</max-capacity>
> </cache-policy-conf>
> <cache-policy-conf-other>
> <partitions>1</partitions>
> <read-only-cache>true</read-only-cache>
> <pre-load-cache>true</pre-load-cache>
> </cache-policy-conf-other>
> </container-cache-conf>
> </container-configuration>
> </container-configurations>
> </jboss>
> Although the prototype code seems to work well ? we?ve observed a 20% improvement in throughput in some test cases as well as lower CPU usage, better response times, less garbage created - we believe a better scheme could be used for read only transactions of this nature. We will investigate the possibility of using a different View for read only transactions, possibly reusing the same View for all read only transactions. The intent would be to provide caching at the View level only, to further reduce the overhead of unnecessary objection creation and copies.
> Another area of further investigation would be focused on the use of common caches between related entities. At present, it looks like entity relationships cause the same tables to be cached by different instances of EntityTable.java.
--
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
19 years, 12 months