[JBoss JIRA] Created: (JBCACHE-1253) Unneeded copying of data in Notifier
by Bela Ban (JIRA)
Unneeded copying of data in Notifier
------------------------------------
Key: JBCACHE-1253
URL: http://jira.jboss.com/jira/browse/JBCACHE-1253
Project: JBoss Cache
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 2.1.0.CR2
Reporter: Bela Ban
Assigned To: Manik Surtani
All Notifier.notifyXXX() methods are written like this:
public void notifyNodeActivated(Fqn fqn, boolean pre, Map data, InvocationContext ctx)
{
boolean originLocal = ctx.isOriginLocal();
Map dataCopy = copy(data); // <===== COPY !
Transaction tx = ctx.getTransaction();
List<ListenerInvocation> listeners = listenerInvocations.get(NodeActivated.class);
if (listeners != null && listeners.size() > 0)
{
InvocationContext backup = resetInvocationContext(ctx);
// ... bla bla
}
}
The data (hashmap) is copied regardless of whether there are actually any listeners, this leads to poor performance. I saw this as hotspot #1 in my perf tests with JBossCache in JProfiler.
FIX: copy only if there are any listeners
--
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
17 years
[JBoss JIRA] Created: (JBREM-843) MicroSocketClientInvoker can miscount number of active sockets
by Ron Sigal (JIRA)
MicroSocketClientInvoker can miscount number of active sockets
--------------------------------------------------------------
Key: JBREM-843
URL: http://jira.jboss.com/jira/browse/JBREM-843
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Ron Sigal
Assigned To: Ron Sigal
Fix For: 2.2.2.GA_CP01, 2.4.0.Beta1 (Pinto), 2.2.2.SP2
org.jboss.remoting.transport.socket.MicroSocketClientInvoker maintains (1) a pool of available sockets, and (2) a counter, usedPooled, of the number of sockets currently in use. Because the sequence of (1) checking for a free socket in the pool, and (2) creating a new socket if the pool is empty, is not in a synchronized block, it is possible to create more sockets than the maximum pool size. In particular, the following sequence of events can produce "extra" sockets:
1. Thread 1 sees that the pool is empty,
2. Thread 2 returns a socket to the pool, and
3. Thread 1 creates a new socket.
It would be possible to synchronize events 1 and 3, but it's probably undesirable since the process of getting a socket from the pool can be time consuming if the "socket.check_connection" flag is set to true. Therefore, MicroSocketClientInvoker tolerates the possibility of creating "extra" sockets. However, it never puts more than the configured maximum number of sockets in the pool. That is, if the pool is full (i.e., size == maxPoolSize), then, when an invocation completes, the socket used for that invocation will be discarded instead of being added to the pool.
The problem is that the usedPooled counter is incremented every time a socket is created and decremented every time a socket is returned to the pool, but is is *not* decremented when a socket is discarded. Suppose maxPoolSize is 100, If 101 sockets are created, 100 sockets are returned to the pool, and 1 socket is discarded, then the resulting value of usedPooled will be 1 instead of 0. It appears, then, that there is 1 socket in use, so MicroSocketClientInvoker will create no more than 99 additional sockets (excluding the race described above). So, there is a leak, not of sockets, but of "slots" for sockets. Eventually, it could become impossible to create new sockets.
--
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
17 years
[JBoss JIRA] Created: (JBREM-889) If an exception occurs during invocation, usedPooled is not decremented, thus leading into eventual remoting failures
by Hasan Ceylan (JIRA)
If an exception occurs during invocation, usedPooled is not decremented, thus leading into eventual remoting failures
----------------------------------------------------------------------------------------------------------------------
Key: JBREM-889
URL: http://jira.jboss.com/jira/browse/JBREM-889
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: transport
Affects Versions: 2.2.2.SP1
Environment: Should for all environments
Reporter: Hasan Ceylan
Hello,
I guess this goes into Ron's area. Back in 2004 we had had a similar issue.
:)
In MicroSocketClientInvoker.transport(), having obtained a socket, if an exception occurs during the invocation, the code that decrements usedPooled never gets called thus inflating overtime. Eventually reaches 50, the hard limit which in turn, makes clients unable to obtain a socket from pool or create a new one.
I guess, a try, finally block is needed starting right after successful socket acquired, till where you decrement the usedPooled (marked with // Put socket back in pool for reuse).
This will make sure the usedPooled is decremented.
I searched the JIRA and also found similar bug reports which I believe all should be related.
Regards,
Hasan Ceylan
--
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
17 years
[JBoss JIRA] Created: (GPD-191) ESB Service Node
by Koen Aers (JIRA)
ESB Service Node
----------------
Key: GPD-191
URL: http://jira.jboss.com/jira/browse/GPD-191
Project: JBoss jBPM GPD
Issue Type: Feature Request
Components: jpdl
Reporter: Koen Aers
Assigned To: Koen Aers
Fix For: jBPM jPDL Designer 3.1.2
ESB Service Node
A new icon on the tool palette that would inject the following JPDL
syntax into my process definition:
<node name="Calculate Discount">
<action name="esbAction"
class="org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler">
<esbCategoryName>BPM_Orchestration4</esbCategoryName>
<esbServiceName>DiscountService</esbServiceName>
<jbpmToEsbVars>
<mapping jbpm="entireCustomerAsObject" esb="customer" />
<mapping jbpm="entireOrderAsObject" esb="orderHeader" />
<mapping jbpm="entireOrderAsXML" esb="BODY_CONTENT" />
</jbpmToEsbVars>
<returnVars>
<mapping jbpm="entireOrderAsObject" esb="order"
/>
</returnVars>
</action>
<transition name="" to="Review Discount"></transition>
</node>
And provide a property sheet that allows me to specify the service name,
category and the mapping of process variables to esb message parts.
--
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
17 years
[JBoss JIRA] Created: (JBAS-5048) Lookup of resource bound via ExternalContext using a CompondName results in serialization of org.jnp.interfaces.FastNamingProperties
by Mike Clark (JIRA)
Lookup of resource bound via ExternalContext using a CompondName results in serialization of org.jnp.interfaces.FastNamingProperties
------------------------------------------------------------------------------------------------------------------------------------
Key: JBAS-5048
URL: http://jira.jboss.com/jira/browse/JBAS-5048
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Naming
Affects Versions: JBossAS-4.0.5.GA
Reporter: Mike Clark
Assigned To: Scott M Stark
When a user registers resources using the org.jboss.naming.ExternalContext, they can only successfully lookup resources on the remote JNDI system if they first lookup the Context registered in the ExternalContext and then look up resources on the returned Context. Looking up the full name results in the use of the org.jnp.interfaces.FastNamingProperties class which is not generally available on the remote JNDI implementation.
So, for example, a user might register "external/foreign_jndi" using the ExternalContext. Looking up resource, a/b/c as follows works:
Context initialContext = new InitialContext();
Context remoteContext = (Context) initialContext.lookup("external/foreign_jndi");
Object obj = remoteContext.lookup("a/b/c");
while, the more direct
Context initialContext = new InitialContext();
Object obj = initialContext.lookup("external/foreign_jndi/a/b/c");
results in a "java.lang.ClassNotFoundException: org.jnp.interfaces.FastNamingProperties" exception on the remote JNDI system.
It appears to occur because the FastNamingProperties class is used in the construction of the CompoundName in the org.jnp.interfaces.NamingParser. So, in the first case, the parsing of "a/b/c" is handled by the foreign JNDI system, while in the latter, the CompoundName containing the FastNamingProperties is passed to the foreign JNDI system.
--
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
17 years
[JBoss JIRA] Commented: (JBAS-1436) Improved management
by Robert Klemme (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1436?page=comments#action_12393418 ]
Robert Klemme commented on JBAS-1436:
-------------------------------------
While looking for a way to get wait times for connections logged I stumbled across this one. From the activity log it's unclear to me whether there is actually work in progress besides PreparedStatementPool. Is there a chance that we will be able to see logging of how long a thread waited for a connection in JB 4.2.0? I looked at InternalManagedConnectionPool but it seems there is logging of wait time only in case the thread is interrupted (via the exception) but not in the standard case.
> Improved management
> -------------------
>
> Key: JBAS-1436
> URL: http://jira.jboss.com/jira/browse/JBAS-1436
> Project: JBoss Application Server
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: JCA service
> Reporter: Adrian Brock
> Assigned To: Weston Price
> Priority: Minor
>
> Forum Discussion Thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48682
> **This is a holder issue. Each section should be raised as a new issue as it is
> developed with a link from this issue.**
> There are a number of areas in JCA that need better management capabilities.
> Some of these stats may also reveal the need for new configuration/tuning parameters.
> In core JCA:
> 1) Better visibility on the ManagedConnectionFactory.
> This is currently a DynamicMBean that provides basic config parameters, but we could also
> provide a proxy/wrapper to provide statistics of operations on the factory and its
> ManagedConnections.
> a) createManagedConnections
> b) matchManagedConnections
> c) events on from the listeners
> 2) Better visibility of the Pool(s)
> Only top level statistics are provided (you cannot see the subpools).
> The statistics are also not synchronized with the pool (for performance reasons
> and also the fact that each stat is retrieved on individual MBean getAttribute requests)
> Additional statistics could include wait times when requests are waiting on an empty pool,
> idle time of unused connections, etc.
> 3) Better visibility of the ConnectionManager
> Currently this has no visibility for management.
> Its main responsibilties are transactions enlistment and security.
> e.g. This could show how long is wasted because <track-connection-by-tx/> does not
> return the connection the pool until transaction completion.
> 4) JDBC resource adapter
> PreparedStatementCache stats
> Query time stats
> etc.
> 5) JMS resource adapter
> Message send/receive stats
> 6) Inbound messaging
> Stats for message delivery
> 7) Transaction inflow
> Stats for transaction inflow and also display a list of current inbound transactions
> 8) Work management
> Stats for the work management pools and timers
--
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
17 years
[JBoss JIRA] Updated: (JBAS-1483) Non-clustering testing for clustered http session code
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1483?page=all ]
Brian Stansberry updated JBAS-1483:
-----------------------------------
Summary: Non-clustering testing for clustered http session code (was: Black box testing for http session (with and without replication))
Description:
We need to have more black box testing for http requests without replication. Every feature in single node should also be supported by the clustered session manager and session classes. But currently, our testsuite largely only covers the clustered aspects.
So here is two main steps:
1. Create an automated black box testing suite for http session request in a single node. We can use some tool to do this. Question is we need to define the tests.
2. Currently, Tomcat has a whole suite of unit testing on http session. We should look into that to see if we can re-use some of it in our own Tomcat module.
was:
While talking with Ivelin, I think we need to have more black box testing for http requests with and without replication. Every feature in single node should also be supported bu clustering, plus some additional use caes for clustering failover. But currently, I only have limited unit test case for clustering in term of failing over.
So here is two main steps:
1. Create an automated black box testing suite for http session request in a single node. We can use some tool to do this. Question is we need to define the tests.
2. Currently, Tomcat has a whole suite of unit testing on http session. We should look into that to see if we can re-use some of it in our own Tomcat module.
3. Create test cases for fail-over. I can help to define the set here.
Assignee: Brian Stansberry
Updated this to focus on the standalone use case testing. The comments regarding missing clustered testing were largely out of date.
> Non-clustering testing for clustered http session code
> ------------------------------------------------------
>
> Key: JBAS-1483
> URL: http://jira.jboss.com/jira/browse/JBAS-1483
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering
> Reporter: Ben Wang
> Assigned To: Brian Stansberry
> Fix For: JBossAS-5.0.1.CR1
>
> Original Estimate: 4 weeks
> Remaining Estimate: 4 weeks
>
> We need to have more black box testing for http requests without replication. Every feature in single node should also be supported by the clustered session manager and session classes. But currently, our testsuite largely only covers the clustered aspects.
> So here is two main steps:
> 1. Create an automated black box testing suite for http session request in a single node. We can use some tool to do this. Question is we need to define the tests.
> 2. Currently, Tomcat has a whole suite of unit testing on http session. We should look into that to see if we can re-use some of it in our own Tomcat module.
--
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
17 years