[Design of Messaging on JBoss (Messaging/JBoss)] - Testsuite updates... (Repost)
by clebert.suconic＠jboss.com
I just wanted to give you guys an update about my recent work on the testsuite.. You guys are a few hours ahead of me.. so an update would probably be a good thing now.
I - I profiled the testsuite, and I added some code locally (Using JVMTIInterface) to produce a memory dump on every test (with just counters... just like the one we have with kill -3).
There was/is an issue on Pinger. The Pinger instance will stay hold for a few seconds after the close is called, so it was hard to double check what tests are leaking PostOfficeImpl and QueueImpl. So, I modified the Pinger (locally) to clean basically all the fields. But I still wanted to understand why the future.cancel is holding the Pinger for more 10-30 seconds in avg after being called.
With this I've found several tests not setting up server to null, and one that was probably not shutting down the server properly.
I still have a few leaks after RedistributionTest... Redistribution will be my next update.
II - NettyFileStorageSymmetricClusterWithBackupTest::testStartStop
For some reason when the live is creating a few IDs during closing a few Consumers, a few empty transactions.. and other things that are not getting replicating. Because of that the backup node will get the IDs out of sync with live, so the backup won't be activated after the second restart due to this exception:
| if (liveUniqueID != backupID)
| {
| initialised = false;
|
| throw new IllegalStateException("Live and backup unique ids different (" + liveUniqueID + ":" + backupID + "). You're probably trying to restart a live backup pair after a crash");
| }
|
|
I'm looking at avoiding creating extra IDs during the shutdown. I'm almost there.. I didn't get there today just because it's too late now, but I'm confident about it now.
III - There is also another separate issue on NettyFileStorageSymmetricClusterWithBackupTest. (Which will probably show up in other tests).
When the bridge is deployed, it will send a message to a management queue. When several bridges are being deployed very quickly, you would eventually have messages arriving on the backup at a different order, and the message ACK repplication won't get there. I will work on this as soon as I finish II.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249568#4249568
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249568
16 years, 7 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Testsuite updates...
by clebert.suconic＠jboss.com
I - I just wanted to give you guys an update about my recent work on the testsuite.. You guys are a few hours ahead of me.. so an update would probably be a good thing now.
I profiled the testsuite, and I added some code locally (Using JVMTIInterface) to produce a memory dump on every test (with just counters... just like the one we have with kill -3).
There was/is an issue on Pinger. The Pinger instance will stay hold for a few seconds after the close is called, so it was hard to double check what tests are leaking PostOfficeImpl and QueueImpl. So, I modified the Pinger (locally) to clean basically all the fields. But I still wanted to understand why the future.cancel is holding the Pinger for more 10-30 seconds in avg after being called.
With this I've found several tests not setting up server to null, and one that was probably not shutting down the server properly.
I still have a few leaks after RedistributionTest... Redistribution will be my next update.
II - NettyFileStorageSymmetricClusterWithBackupTest::testStartStop
For some reason when the live is creating a few IDs during closing a few Consumers, a few empty transactions.. and other things that are not getting replicating. Because of that the backup node will get the IDs out of sync with live, so the backup won't be activated after the second restart due to this exception:
| if (liveUniqueID != backupID)
| {
| initialised = false;
|
| throw new IllegalStateException("Live and backup unique ids different (" + liveUniqueID + ":" + backupID + "). You're probably trying to restart a live backup pair after a crash");
| }
|
|
I'm looking at avoiding creating extra IDs during the shutdown. I'm almost there.. I didn't get there today just because it's too late now, but I'm confident about it now.
III - There is also another separate issue on NettyFileStorageSymmetricClusterWithBackupTest. (Which will probably show up in other tests).
When the bridge is deployed, it will send a message to a management queue. When several bridges are being deployed very quickly, you would eventually have messages arriving on the backup at a different order, and the message ACK repplication won't get there. I will work on this as soon as I finish II.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249568#4249568
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249568
16 years, 7 months
[Design of POJO Server] - AS-5 Files to watch for application redeployment
by jaikiran
Background: http://lists.jboss.org/pipermail/jboss-development/2009-June/014478.html and other threads where AS-5 re-deployments have been discussed
As discussed in the mailing list, unlike AS-4.x, in AS-5, *by default* we watch for all xml files in a metadata location, to decide whether a application redeployment(hotdpeloyment) is necessary. In AS-4.x, we used to watch only for known files application.xml, web.xml (and other known top level descriptor). The nice thing about that feature was we let the end users decide when they want to trigger a redeployment instead of guessing it ourselves. So in AS-4.x, an end user could do 'n' number of changes to various xml files (or other files) in the metadata locations of the application (or any other location) and then at some point "decide" to trigger the redeployment by touching the application.xml or the appropriate top level descriptor. There were no surprises here.
However in AS-5, this has changed. It's now the application server which does redeployments more aggressive by guessing that the application needs redeployment. So if the user has to do 'n' number of changes to various xml files in the metadata locations, then the AS could end up triggering those many redeployments, effectively taking away the control that end users had over redeployments in AS-4.x. Users are finding this default behaviour difficult to manage.
In AS-5, the configuration/filter which decides which files to consider for redeployments is managed by this (in profile.xml):
| <bean name="MetaDataStructureModificationChecker" class="org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker">
| <constructor>
| <parameter><inject bean="MainDeployer" /></parameter>
| </constructor>
| <property name="cache"><inject bean="StructureModCache" /></property>
| <property name="filter"><bean class="org.jboss.system.server.profile.basic.XmlIncludeVirtualFileFilter" /></property>
| </bean>
|
So *by default* in AS-5, the filter is meant to check for all xml files. It can be argued that the end user can configure/tweak this filter as per his wish to take care of his re-deployment needs. But do we really want the normal end users (most of them) to be changing this? Or should be *by default* manage it such that we have a similar behaviour as AS-4.x may be by using the PatternIncludeVirtualFileFilter
| <bean name="MetaDataStructureModificationChecker" class="org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker">
| <constructor>
| <parameter><inject bean="MainDeployer" /></parameter>
| </constructor>
| <property name="cache"><inject bean="StructureModCache" /></property>
|
| <property name="filter">
| <!-- A pattern matching filter. We can configure this to our custom pattern.
| Here we configure it to include only application.xml and web.xml
| for modification check (and any subsequent redeployments) -->
| <bean class="org.jboss.system.server.profile.basic.PatternIncludeVirtualFileFilter">
| <constructor>
| <!-- Remember, the parameter is a regex so use the correct syntax
| as below -->
| <parameter class="java.lang.String">application.xml|web.xml</parameter>
| </constructor>
| </bean>
| </property>
|
| </bean>
|
The PatternIncludeVirtualFileFilter approach is just an example. The real question is, *by default* should we be really doing the guess work for redeployments or like AS-4.x only watch for known top level files and give the end users more freedom to trigger an redeployment? Furthermore, if some advanced user wants to customize the way redeployments are done then he can always change the default settings, but for most of the users should we switch to AS-4.x behaviour?
Thoughts?
[OT] - The PatternIncludeVirtualFileFilter (and other similar filters) in Branch_5_x needs to be changed to extend the new class that was introduced in JBDEPLOYERS for 2.0.8 version. Or else these filters won't be usable as a cacheFilter.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249565#4249565
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249565
16 years, 7 months
[Design of POJO Server] - Re: Seam deployments and hot deployments in AS 5.1.0
by jaikiran
"alesj" wrote :
| Jaikiran, can you reproduce this?
We just got the seam redeployment issues sorted out on branch 5_x which already includes the 2.0.8 version deployers :) clerum was on #jboss where we got this working. He's going to update this thread with the details.
The only additional thing that he had to do other than just building the AS 5_x branch was to update the profile.xml to include the cacheFilter:
<bean name="ModificationCheckFilter" class="org.jboss.system.server.profile.basic.XmlIncludeVirtualFileFilter"/>
|
| <bean name="MetaDataStructureModificationChecker" class="org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker">
| <constructor>
| <parameter><inject bean="MainDeployer" /></parameter>
| </constructor>
| <property name="cache"><inject bean="StructureModCache" /></property>
| <property name="cacheFilter"><inject bean="ModificationCheckFilter" /></property>
| <property name="filter"><inject bean="ModificationCheckFilter" /></property>
| </bean>
We'll have to add this in the 5_x branch by default. clerum with update this thread with the rest of tests and details.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249527#4249527
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249527
16 years, 7 months