I'm happy that Rolling Log has gone, as I never did get this to recover, as it always ran out of file handles. However, File PM has been very reliable.
Issues outlined in Wiki anonymous wrote : Each message requires an filehandle, for large numbers of messages, the OS can run out of filehandles. - You can use MaxDepth to ensure there are a limited amount of messages in a queue. Also I have only ever encountered this issue with the Rolling Log implementation. anonymous wrote : No hard flush to the disk means the data may still be stuck in OS/hardware buffers. - The File PM be changed to optionally use the FileDescriptor.sync method to ensure the data is written to disk? anonymous wrote : No check summing means the recover may be looking at corrupted or incomplete data. - Use the java.util.zip to write to disk and use its checksum, this will also give the benefit of less data getting written to disk (faster writes). anonymous wrote : The RollingLogged implementation is "deliberately" broken by design in that it gambles reliability in favour of performance. Again, each queue requires hundreds of open filehandles. - I Agree, but I'm happy with removing rolling log. anonymous wrote : There is no link between the cache implementation and the persistence manager meaning that persistent message could be stored twice on disk. - I have noticed this on some occasions but the performance benefit of File PM overall makes this hit negligible. The Cache implementation could be altered to not roll out to disk, just get from the Persistence Manager again. Enhancing File PM If the File PM allows its default mode, and another mode which uses FileDescriptor sync method this should cover most requirements. Allowing the developer to choose speed over reliability if required. Background on WebLogic JMS WebLogic gives you the choice several alternatives for JMS File persistence (which is refers to in the performance document as the fastest JMS persistence method, see http://ftpna2.bea.com/pub/downloads/WebLogicJMSPerformanceGuide.pdf section 4.4.1). It has Disabled which means fully cached (limited failover support). Cache-Flush waits for until the message has been flushed to disk. Direct-Write means no buffers are used and all writes are written directly to disk. We to go from Here I think File PM should still be included in 4.0 as is, with warnings if you wish in the documentation/Wiki. I understand that the new Messaging component is being worked on, but until its available there needs to be an alternative to JDBC within the current Jbossmq. Also the new JBoss Messaging component needs to have a reliable fast File based PM available. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880582#3880582 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880582 ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
