[JBoss JIRA] Created: (JBMESSAGING-1009) Add configurale defaults on ServerPeer for FullSize, PageSize, and DownCacheSize
by Jay Howell (JIRA)
Add configurale defaults on ServerPeer for FullSize, PageSize, and DownCacheSize
--------------------------------------------------------------------------------
Key: JBMESSAGING-1009
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1009
Project: JBoss Messaging
Issue Type: Feature Request
Components: Messaging Core
Affects Versions: 1.3.0.GA
Reporter: Jay Howell
Assigned To: Tim Fox
Priority: Minor
I see all the other defaults on the ServerPeer, but there seems to be no way to set the defaults for all the queues for the paging. I would ask that we add the following as properties on the serverpeer
DefaultFullSize
DefaultPageSize
and Default DownCacheSize
These constants should probably be taken out of org.jboss.jms.server.destination.ManagedDestination and put into the server peer as defaults. It would be ok to put these defaults in the Serverpeer as default values, but they need to be able to be overridden by default configuration settings.
--
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
18 years
[JBoss JIRA] Created: (JBMESSAGING-1162) JBM takes eons to startup with topic persisted messages within db
by Gabriele Garuglieri (JIRA)
JBM takes eons to startup with topic persisted messages within db
-----------------------------------------------------------------
Key: JBMESSAGING-1162
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1162
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core Persistence
Affects Versions: 1.4.0.SP1
Environment: Java 1.5.0_14
JBoss 4.2.2
Solaris 10, AMD Opteron biprocessor machine
Reporter: Gabriele Garuglieri
Assigned To: Tim Fox
Priority: Critical
The problem is reproduced as follows:
1-Start server
2-start a producer that inserts persisted messages (we tried 90.000 messages) in TestTopic topic with default configuration where there are some consumers subscribed but not active
3-stop producer and orderly shutdown the server
4-start server
During server startup JBM executes a select to load the persisted messages id's then executes 180 selects loading 500 messages at time.
With 90.000 messages those 180 selects takes about 10 minutes. The DBMS is Oracle 10g with dedicated instance on a separate machine with no more than 1% cpu load during test and physical db on a very fast NAS.
While JBM is executing those selects, obviously the server startup hangs until the load is finished.
--
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
18 years
[JBoss JIRA] Created: (JBRULES-1660) Rule agent not detecting deleted files and removing packages
by Michael Neale (JIRA)
Rule agent not detecting deleted files and removing packages
------------------------------------------------------------
Key: JBRULES-1660
URL: http://jira.jboss.com/jira/browse/JBRULES-1660
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.0.7
Reporter: Michael Neale
Assigned To: Michael Neale
Fix For: FUTURE
1) If I delete a file, it does not remove those rules from the rules base. I assume that this is because all we get back from a the FileScanner.getChangeSet() is a Package[], which is the list of packages to load. There is no code to indicate that it will do a File.exist() on the list of file handles in the scanner to see if any packages have disappeared.
2) In the case where I remove one .drl and create a new different one, (in addition to point 1, where the old one is not removed) the new one is also not picked up. The problem lies in an assumption in the DirectoryScanner.loadPackageChanges(). The following line
if ( currentList.length != dir.listFiles().length ) {
assumes that if the number of files in the directory has not changed, then it really is the same list of files were dealing with. In my case this is not true, and hence it does not give the new list of files to the FileScanner to load.
--
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
18 years