[jboss-user] [Microcontainer] - Re: Installing a context leads to resolve of other unrelated
anonymous wrote : | Re-read the JNDI example. ;-) | Or how else are you gonna make sure you don't miss a potential dependency resolving bean, | if you don't check them all? | One idea would be to process the dependencies statically via an installation/configuration step that generates initialization code. This could be done via the MC compiler (MCC or maybe YAMCC). I know that we don't have this now but I like the general idea of pre-compiling/caching what ever stuff makes sense to improve performance. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244091#4244091 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244091 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Clustering/JBoss] - Re: ConcurrentModificationException during session serializa
Currently, deployed applications do not hold a RL lock while processing requests. If we introduce a RL lock to be held while processing requests, will that be slower? There is some potential additional overhead to the ReadWriteLock (http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/ReadWriteLock.html). Perhaps it would be better (performance wise) to synchronize on the session level facade object as I think the performance should be close to what applications currently see (whether or not they also synchronize on the session object when accessing mutable attributes). What do you think? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241218#4241218 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241218 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Performance Tuning] - Re: Full GC not releasing Memory
Be sure that you aren't using the jmap tool from an JDK 1.6 installation (unlikely but thought it was worth mentioning). http://www.j2ee.me/javase/6/webnotes/trouble/other/matrix5-Unix.htm talks about Java SE 5.0 update 14 supporting -XX:+HeapDumpOnCtrlBreak option. I haven't tried this but maybe you could try this (with update 14 or newer). Perhaps the jmap tool will even behave better. I also like to use XX:+HeapDumpOnOutOfMemoryError (generates a heapdump file on first Java OOM) which was added in Java 5 update 7. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240870#4240870 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240870 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Performance Tuning] - Re: Full GC not releasing Memory
At the moment, my favorite OSS tool for finding memory issues is http://www.eclipse.org/mat/ Basically, you generate a heap dump and run the eclipse memory analyzer against it. You will get a report of the likely suspects and can view the contents of any memory variable. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240523#4240523 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240523 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Clustering/JBoss] - Re: ConcurrentModificationException during session serializa
I see, so we are obtaining the RL for the application (held while the application request is running). This avoids the cooperative locking scheme that would of required the application to lock on the sessionFacade object. Some potential performance issues that could challenge this approach. 1. During http session replication, further http requests (from users that are involved with the replication) will block (at least while the session level write lock is held for the replication). 2. When a http request is completing that has modified http session attributes, the replication will be delayed until the write lock can be obtained. This could introduce unexpected performance delays. 3. Are there additional performance implications for synchronous replication? If the user waits in the browser for the replication to complete, they could be waiting a long time, depending on when the write lock can be obtained. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240439#4240439 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240439 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Clustering/JBoss] - Re: ConcurrentModificationException during session serializa
If we are holding the WL lock on some thread, couldn't another thread (processing an application request against the same HTTP session) access the locked attribute (reading/writing attribute values). Maybe I missed how we would force application code to use our RW lock. Does that come for free with your approach? :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240415#4240415 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240415 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Clustering/JBoss] - Re: ConcurrentModificationException during session serializa
anonymous wrote : FYI, before this thread got going I'd been thinking (vaguely) in terms of using read/write locks in AS 6 to better handle coordination. E.g., in ClusteredSessionValve acquire a RL before passing the request down the pipeline, release when it returns, acquire a WL before handling replication. Basically, allow concurrent access to a session but lock out requests while a thread is replicating. | In the current case, the application code is synchronizing on the session facade object, so they would be left out if we synchronize on an internal r/w lock. I wonder if we could somehow expose our (HTTP session level) r/w lock object to the application (in a reasonably portable way), so that they could also get a RL when getting the attribute values. Applications will also want to get a WL when setting attribute values. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240384#4240384 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240384 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Clustering/JBoss] - Re: ConcurrentModificationException during session serializa
After sleeping on it, I don't like the memory impact of my suggestion (serializing attribute values earlier). Your idea sounds better anonymous wrote : If a MutexSource is available, SimpleCachableMarshalledValue.serialize() would call that method and synchronize on the return value. ClusteredSession would implement MutexSource by returning the result of a getSession() call. | | This would also deal with the cross-context request issue noted above. | +1 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240280#4240280 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240280 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Clustering/JBoss] - Re: ConcurrentModificationException during session serializa
This isn't perfect but we might be able to convert the HTTP session attribute value to byte array before multiplexing and the reverse on the receiving end. I'm not thrilled about double buffering the attribute value (keeping a copy in serialized form and original object form), but maybe we are doing that already on the multiplexing side (in which case there isn't extra memory overhead). The advantage of the above approach is that we could easily synchronize the relevant session facade during serialization/de-serialization. I'm not sure how that impacts the current design. What do you think? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240194#4240194 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240194 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Clustering/JBoss] - Re: ConcurrentModificationException during session serializa
Brian, We will have to try to get access to the StandardSessionFacade from there as well (perhaps through the ClusteredSession). anonymous wrote : | The concern I have is StandardSession.facade is not thread safe, and what's returned from getSession() needs to be if we are going to use it as a mutex. | We will only synchronize on the StandardSession.facade object and not modify it. Since we are not modifying the StandardSession.facade object, we do not need it to be thread safe. At least that is my thinking, let me know if I'm missing something :-) anonymous wrote : | There's no ref to facade outside StandardSession.getSession(), so ClusteredSession can override the getSession() method and replace the field with a volatile field and synchronize the construction if null. | I don't really understand the case when getSession would return null. I wonder if the null session case signify something special that needs to be preserved? For what its worth, the javadoc for Requests.getsession() is: /** | * Return the session associated with this Request, creating one if necessary. | */ | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240146#4240146 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240146 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Clustering/JBoss] - Re: ConcurrentModificationException during session serializa
If you have difficulties applying/building the patch, I'll try to recreate/test instead. Let me know either way. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239846#4239846 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239846 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Clustering/JBoss] - Re: ConcurrentModificationException during session serializa
It is easy to build (assuming 4.2.x): cd jboss_4.2.x_tree cd build ./build.sh cd output cd jboss-4.2.4.GA/bin ./run.sh -c all I also attached the potential 4.2 code patch (need to get it reviewed still) to JBAS-5615. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239828#4239828 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239828 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Clustering/JBoss] - Re: ConcurrentModificationException during session serializa
There are other code changes that go with the change but the above should be enough for you to test. The super classes also need to change to synchronize on the getSession() instead of "this". View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239809#4239809 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239809 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Clustering/JBoss] - Re: ConcurrentModificationException during session serializa
What I mean, is should SessionBasedClusteredSession.writeExternal +
SessionBasedClusteredSession.readExternal instead synchronize on getSession(),
which should be the same StandardSessionFacade as RichFaces is synchronizing on.
I haven't recreated the bug yet. I could either recreate it or you could try
the following SessionBasedClusteredSession change (two line change to
synchronize on common session facade) :
public void readExternal(ObjectInput in) throws IOException,
ClassNotFoundException
|{
| synchronized (getSession()) // change 1 of 2
| {
| // Let superclass read in everything but the attribute map
| super.readExternal(in);
|
| attributes = (Map) in.readObject();
| }
|}
|
|public void writeExternal(ObjectOutput out) throws IOException
|{
| synchronized (getSession) // change 2 of 2
| {
| // Let superclass write out everything but the attribute map
| super.writeExternal(out);
|
| // Don't replicate any excluded attributes
| Map excluded = removeExcludedAttributes(attributes);
|
| out.writeObject(attributes);
|
| // Restore any excluded attributes
| if (excluded != null)
| attributes.putAll(excluded);
| }
|
|}
|
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239792#4239792
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239792
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Clustering/JBoss] - Re: ConcurrentModificationException during session serializa
What could the solution be? Should SessionBasedClusteredSession.writeExternal synchronize on the same session facade as RichFaces? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239779#4239779 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239779 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Clustering/JBoss] - Re: ConcurrentModificationException during session serializa
I agree, that running with only one node in the cluster shouldn't require "sticky sessions=true". When we do run with more than one cluster node, we need to enable "sticky sessions" to avoid multiple http session attribute changes (to the same http session attribute) coming from different nodes (at the same time). Thank you for explaining this part of the problem. Of course, it goes deeper than not configuring the http load-balancer (please always enable "sticky http sessions" :-) anonymous wrote : The problem as it seems to be is the web session gets modified while it is been serialized. Specifically the serialization of an org.ajax4jsf.util.LRUMap instance holding some JSF(?) state is failing with ConcurrentModificationException, so I've first thought it could be a RichFaces library problem. >From your description of the problem, it sounds like the following events have >occurred: An HTTP request is received for user Sharon, during the processing of this request (R1), an HTTP session attribute change is made. As part of the HTTP processing after request processing, we attempt to replicate the attribute change. Meanwhile, another HTTP request (R2) for user Sharon was also processed that generated an HTTP session attribute change. As part of R2 processing, the same attribute change was transmitted (from a different HTTP client service thread) and applied to the collection (while the R1 client request handling thread is iterating through the collection). The java.util.ConcurrentModificationException occurs when iterating through the collection, while another thread modifies the collection. Before we discuss possible solutions, lets see if we agree on the above. If I am not stating things correctly above, please explain your understanding of what is happening. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239560#4239560 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239560 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Clustering/JBoss] - Re: ConcurrentModificationException during session serializa
anonymous wrote : The same problem appears with 2 nodes configuration on FreeBSD 7.0 with Sun's JDK 1.5.0_11. I am trying to help with JBAS-5615. Could you clarify if "sticky http session" handling is enabled or disabled in this two node cluster? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239473#4239473 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239473 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
