[JBoss-dev] [JBoss JIRA] Commented: (JBAS-31) CachedConnectionManager - inUseConnections not correct
[ http://jira.jboss.com/jira/browse/JBAS-31?page=comments#action_12310792 ] Adrian Brock commented on JBAS-31: -- The test.jsp does not reproduce the problem for me? CachedConnectionManager - inUseConnections not correct -- Key: JBAS-31 URL: http://jira.jboss.com/jira/browse/JBAS-31 Project: JBoss Application Server Type: Bug Components: JCA service Versions: JBossAS-3.2.6 Final Reporter: Scott M Stark Assignee: Scott M Stark Attachments: test.jsp For CachedConnectionManager service debug option is enabled to monitor connections. !-- Enable connection close debug monitoring -- attribute name=Debugtrue/attribute Using jmx-console, if we look at the inUseCount property. The number displayed is not consitent with the underlying connection pool. listInUseConnections shows stack traces for connections that have been closed long back. It take a long time for the inUseCount to drop down, but never drops to 0 even after the connection pools correctly show inUseCount as 0. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBMQ-6) Message Selector Performance
Message Selector Performance Key: JBMQ-6 URL: http://jira.jboss.com/jira/browse/JBMQ-6 Project: JBoss MQ Type: Task Components: Server Reporter: Adrian Brock Priority: Minor Improving Message Selector Performance It is a common anti-pattern for users to set up a contested queue where multiple receivers try to take messages based on a message selector. In most circumstances a Topic is what they should be using. But there is a circumstance where a Topic does not work as required, that is when a message matches many of the receiver's selector but you only want one receiver to process the message (it doesn't matter which). The problem is that when a receiver does not match a message towards the top of a large Queue (or none at all). The operation to find a message or discover there are no messages is very expensive. It is read and skip. This can be even worse when the bottom of the queue has been moved out to disk by the MessageCache. The solution is to provide an index over a particular property, e.g. mbean code=org.jboss.mq.server.jmx.Queue name=jboss.mq.destination:service=Queue,name=A optimized-selectorJMSMessageID/optimized-selector depends optional-attribute-name=DestinationManagerjboss.mq:service=DestinationManager/depends /mbean This configuration should be passed via the BasicQueueParameters to the BasicQueue. NOTE: This is irrevelent for Topics. Topics run their selector before the message is added to the subscription, anything not matching the selector is dropped. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBJCA-6) JMS Message Inflow
JMS Message Inflow -- Key: JBJCA-6 URL: http://jira.jboss.com/jira/browse/JBJCA-6 Project: JBoss JCA Type: Task Reporter: Adrian Brock Assigned to: Adrian Brock The JMS message inflow in the JMS resource adapter needs properly testing. There are basic tests, but the following are missing: 1) Complete tests of edge cases for each configuration parameter in the activation spec 2) Failure tests to confirm the implementation handles error gracefully 3) Stress tests to make sure there the implementation is stable 4) Performance tests to optimize the implementation Additionally, we need to confirm that it is possible to use this implementation for EJB2.0 style deployments and hence as the default configuration. This should be possible provided the user has not created their own container configuration that uses the old JMSContainerInvoker explicitly. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBJCA-5) Interceptors
[ http://jira.jboss.com/jira/browse/JBJCA-5?page=history ] Adrian Brock reassigned JBJCA-5: Assign To: (was: Adrian Brock) Interceptors Key: JBJCA-5 URL: http://jira.jboss.com/jira/browse/JBJCA-5 Project: JBoss JCA Type: Task Reporter: Adrian Brock Priority: Minor Forums discussion thread: http://www.jboss.org/index.html?module=bbop=viewtopict=48683 This is really a major rewrite of the JCA implementation to be less monolithic so this will need some careful design and consideration and breaking up into more fine grained tasks. The idea is to provide containers/interceptors for the components within the JCA module such that these components can be more easily customised and developed according to the needs of each user. There are three main interceptor stacks that I can think of: 1) ConnectionManager (connection allocation) This provides an interceptor stack behind the ConnectionFactory/DataSource proxy to process the allocateConnection invocation. It will look something like: ConnectionFactory proxy - ConnectionManager interceptor - Pooling interceptor 2) ManagedConnection/ConnectionEventListener (connection management) This stack provides most of the features that are currently performed by the BaseManagerConnection2$ConnectionListener and their supporting methods, but as an interceptor stack. As now they will largely be driven by the events from the resource adapter, and it this object that is actually pooled. 3) Resource Adaptors The JDBC and JMS adaptors should be implemented as interceptor stacks to allow optional interceptors like statistics collection, custom behaviour and also to perform vendor specific processing/workarounds. Where AOP can be used, we could actually instrument the vendor classes so we can also expose vendor specific methods, not just the JDBC interfaces. This would remove the requirement to do things like getUnderlyingConection() by user code. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBMQ-12) Lazily Loading Queues
Lazily Loading Queues - Key: JBMQ-12 URL: http://jira.jboss.com/jira/browse/JBMQ-12 Project: JBoss MQ Type: Task Components: Persistence Reporter: Adrian Brock This is a major change that is the last obstacle to JBossMQ scalability. The idea is that messages will only be loaded into the server when the destination is activated and then only part of the messages are loaded (enough to deal with the current throughput). An attempt was made to do this and committed on Branch JBoss_3_2_5_JBossMQ_Lazy but the work was abandoned. It does not deal with the more difficult problems. In any case, the BasicQueues should be talking directly with the PersistenceManager. In fact, I would favour that the BasicQueue implementation is actually pluggable and determined by the PM to allow better optimization between these two important layers. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBJCA-8) Improvements to Message Inflow
[ http://jira.jboss.com/jira/browse/JBJCA-8?page=history ] Adrian Brock reassigned JBJCA-8: Assign To: (was: Adrian Brock) Improvements to Message Inflow -- Key: JBJCA-8 URL: http://jira.jboss.com/jira/browse/JBJCA-8 Project: JBoss JCA Type: Task Reporter: Adrian Brock Priority: Minor Forums Discussion Thread: http://www.jboss.org/index.html?module=bbop=viewtopict=48675 Need to determine what quality of service features should be provided for message inflow. The most obvious would be delivery side pooling where the RAR does not do this or does this badly. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBMQ-11) Persistence Manager Improvements
Persistence Manager Improvements Key: JBMQ-11 URL: http://jira.jboss.com/jira/browse/JBMQ-11 Project: JBoss MQ Type: Task Components: Persistence Reporter: Adrian Brock There are a number of improvements that can be made to the persistence manager. This should really be done by writing a new version that can then be optionally used while it is experimental. 1) Make use of the datasource mappings - similar what has been done for the EJB timer 2) The use of the JTA transaction is unnecessary since we are the only one in the transaction branch. The tranaction still needs suspending so we are isolated from any wrapping transacton. 3) Make use of build writes to the database This can be used for transactional sessions where multiple messages are processed But it could also be used where people want to relax the absolute requirement that messages are persisted in return for some performance improvement. 4) A general review/rewrite of where the persistence manager is invoked from the server with an aim to improve performance. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBMQ-2) Need better control over the pm memory usage during destination recovery
[ http://jira.jboss.com/jira/browse/JBMQ-2?page=comments#action_12310800 ] Adrian Brock commented on JBMQ-2: - The fundamental problem is databases that try to retrieve the entire result set into memory regardless of the size of the query. This can cause out of memory problems before the message cache gets chance to soften the messages. I don't see how this can be done in an easily portable way, e.g. here is the MySQL mechanism to avoid the problem which is very inefficient: By default, ResultSets are completely retrieved and stored in memory. In most cases this is the most efficient way to operate, and due to the design of the MySQL network protocol is easier to implement. If you are working with ResultSets that have a large number of rows or large values, and can not allocate heap space in your JVM for the memory required, you can tell the driver to 'stream' the results back one row at-a-time. To enable this functionality, you need to create a Statement instance in the following manner: stmt = conn.createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY, java.sql.ResultSet.CONCUR_READ_ONLY); stmt.setFetchSize(Integer.MIN_VALUE); The combination of a forward-only, read-only result set, with a fetch size of Integer.MIN_VALUE serves as a signal to the driver to stream result sets row-by-row. After this any result sets created with the statement will be retrieved row-by-row. There are some caveats with this approach. You will have to read all of the rows in the result set (or close it) before you can issue any other queries on the connection, or an exception will be thrown. Also, any tables referenced by the query that created the streaming result will be locked until all of the results have been read or the connection closed. Need better control over the pm memory usage during destination recovery Key: JBMQ-2 URL: http://jira.jboss.com/jira/browse/JBMQ-2 Project: JBoss MQ Type: Patch Versions: JBossAS-3.2.5 Reporter: Scott M Stark Assignee: Adrian Brock When starting up jboss with a destination with either a large number or very large persistent messages, the jdbc pm may run out of memory if the select * from the db results in the jdbc driver pulling in all of the records. We need to either write the pm with this expectation or allow for some configuration to avoid this. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBJMX-1) Rewrite to use Unified Container/Interceptors and MicroContainer
[ http://jira.jboss.com/jira/browse/JBJMX-1?page=comments#action_12310824 ] Adrian Brock commented on JBJMX-1: -- A prototype has already been started in the MicroContainer project. Rewrite to use Unified Container/Interceptors and MicroContainer Key: JBJMX-1 URL: http://jira.jboss.com/jira/browse/JBJMX-1 Project: JBoss JMX Type: Task Reporter: Adrian Brock Assignee: Adrian Brock Fix For: JBossAS-5.0 Alpha Rewrite JBossMX to use the Unified Container/Interceptors and MicroContainer. This will help the integration work of the MicroContainer into JBoss5 and also provide a full test of the Unified Container/Interceptors. The other advantage is that all aspects will be available to MBeans. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-31) CachedConnectionManager - inUseConnections not correct
[ http://jira.jboss.com/jira/browse/JBAS-31?page=comments#action_12310797 ] Adrian Brock commented on JBAS-31: -- I'm obviously seeing different garbage collection behaviour. Since the result I get is zero. It should be irrelvent once unregisterConnection tidies up the map. CachedConnectionManager - inUseConnections not correct -- Key: JBAS-31 URL: http://jira.jboss.com/jira/browse/JBAS-31 Project: JBoss Application Server Type: Bug Components: JCA service Versions: JBossAS-3.2.6 Final Reporter: Scott M Stark Assignee: Adrian Brock Attachments: test.jsp For CachedConnectionManager service debug option is enabled to monitor connections. !-- Enable connection close debug monitoring -- attribute name=Debugtrue/attribute Using jmx-console, if we look at the inUseCount property. The number displayed is not consitent with the underlying connection pool. listInUseConnections shows stack traces for connections that have been closed long back. It take a long time for the inUseCount to drop down, but never drops to 0 even after the connection pools correctly show inUseCount as 0. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBMQ-5) Message Bridge
[ http://jira.jboss.com/jira/browse/JBMQ-5?page=history ] Adrian Brock updated JBMQ-5: Component: Server Message Bridge -- Key: JBMQ-5 URL: http://jira.jboss.com/jira/browse/JBMQ-5 Project: JBoss MQ Type: Task Components: Server Reporter: Adrian Brock Priority: Minor Implementation of a MessageBridge. -- This is a proxy that allows messages to be sent to one JMS server and then forwarded to the real destination. To the senders this looks like a plain queue or topic. This is the simplist implementation, more performant implementations are possible: 1) Implement the bridge as a new destination type within JBossMQ 2) It will behave similarly to a Queue but will not accept external receivers. 3) On a background thread (inside a JTA transaction) take some messages from the queue and send them to the real destination. 4) The background thread should automatically recover from a failed connection and retry at configurable intervals. Similarly it should keep retrying if the connection cannot be instantiated at initial startup. This is similar to what the MDB does. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBJCA-10) More Configurable Bootstrap Context
[ http://jira.jboss.com/jira/browse/JBJCA-10?page=comments#action_12310814 ] Adrian Brock commented on JBJCA-10: --- This should also include a mechanism to customise the createTimerTask which currently just uses the JRE implementation. More Configurable Bootstrap Context --- Key: JBJCA-10 URL: http://jira.jboss.com/jira/browse/JBJCA-10 Project: JBoss JCA Type: Task Reporter: Adrian Brock Priority: Minor Forums Discussion Thread: http://www.jboss.org/index.html?module=bbop=viewtopict=48677 Need a mechanism to make the Bootstrap context passed to rar more configurable. Currently a single context is passed to all rars. e.g. A rar may want its own WorkManager/ThreadPool -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBMQ-10) Thread Pool improvements on the client
Thread Pool improvements on the client -- Key: JBMQ-10 URL: http://jira.jboss.com/jira/browse/JBMQ-10 Project: JBoss MQ Type: Task Components: Client Reporter: Adrian Brock The thread usage on the client needs to be improved. The users of threads are: 1) The invocation layers for message delivery 2) The message listeners to wait for messages These should be combinded to use a single thread pool. There is no need for a message listener to hold a thread while it is waiting for a message. It can add itself to a registry which is then used by delivery to invoke the correct listener when a message arrives. In fact, by spec the listeners should register themselves with the session and the session deliver the messages (single threadedly - is that a word? :-). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-31) CachedConnectionManager - inUseConnections not correct
[ http://jira.jboss.com/jira/browse/JBAS-31?page=comments#action_12310793 ] Adrian Brock commented on JBAS-31: -- I do see that unregisterConnection should also remove the connection from connectionStackTraces rather than leaving it to the garbage collector to remove it from the WeakHashMap. The other code is correct. At the end of the invocation (the servlet request), it invokes popMetaAwareObject which does closeAll. If there is a transaction, the unclosed connections are added to the synchronization and checked at transaction termination. This will create a synchronization if necessary (the purpose of the true flag). If there is no transaction the connections are closed immediately. However, it should really be checking whether the transaction is still active rather than (tx != null). But this would really represent buggy code that is leaving a transaction association with the thread. CachedConnectionManager - inUseConnections not correct -- Key: JBAS-31 URL: http://jira.jboss.com/jira/browse/JBAS-31 Project: JBoss Application Server Type: Bug Components: JCA service Versions: JBossAS-3.2.6 Final Reporter: Scott M Stark Assignee: Scott M Stark Attachments: test.jsp For CachedConnectionManager service debug option is enabled to monitor connections. !-- Enable connection close debug monitoring -- attribute name=Debugtrue/attribute Using jmx-console, if we look at the inUseCount property. The number displayed is not consitent with the underlying connection pool. listInUseConnections shows stack traces for connections that have been closed long back. It take a long time for the inUseCount to drop down, but never drops to 0 even after the connection pools correctly show inUseCount as 0. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBJMX-1) Rewrite to use Unified Container/Interceptors and MicroContainer
Rewrite to use Unified Container/Interceptors and MicroContainer Key: JBJMX-1 URL: http://jira.jboss.com/jira/browse/JBJMX-1 Project: JBoss JMX Type: Task Reporter: Adrian Brock Assigned to: Adrian Brock Fix For: JBossAS-5.0 Alpha Rewrite JBossMX to use the Unified Container/Interceptors and MicroContainer. This will help the integration work of the MicroContainer into JBoss5 and also provide a full test of the Unified Container/Interceptors. The other advantage is that all aspects will be available to MBeans. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBJTA-1) Transaction Recovery
Transaction Recovery Key: JBJTA-1 URL: http://jira.jboss.com/jira/browse/JBJTA-1 Project: JBoss JTA Type: Task Reporter: Adrian Brock Implement optional transaction recovery The simplest mechanism is to do this is with a local database using the last resource gambit where during its prepare it logs the XID in a table. If this last resource fails to commit, recovery will not find the transaction in the table which means it will rollback the whole transaction. This has limitations where a different local resource is required within the transaction but not this local database used as the recovery log. Another implementation is a local file. Though more complicated it should give superior performance. But, it does not work well with the last resource gambit, e.g. you cannot tell whether the jdbc commit() suceeded or failed if it crashes just at the point of this invocation before the result is returned from the db. The other work required: 1) Possibly, simplify the dependencies in the JCA module so we can run the recovery earlier. Currently the RARs need the transaction manager at deployment time. The recovery service needs to be an external service depending upon both the tm and the managed connection factories. At least this will require a GUID for the XID so we can avoid duplicates between unrecovered XIDs and any new XIDs created before recovery is complete. 2) JBossMQ needs to implement XAResource.recover() -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBJCA-2) Programmatic Connection Definition Deployment
Programmatic Connection Definition Deployment - Key: JBJCA-2 URL: http://jira.jboss.com/jira/browse/JBJCA-2 Project: JBoss JCA Type: Task Reporter: Adrian Brock Priority: Minor Forums Discussion Thread: http://www.jboss.org/index.html?module=bbop=viewtopict=48673 Provide a mechanism where ConnectionFactorys/DataSources (Connection Definitions) can be deployed/undeployed programmatically. The basic design is as follows: 1) Provide a mechanism to instantiate MetaData for a connection factory. This information is the same as the -ds.xml deployment format. The MetaData can be logically divided into at least the following categories: * RAR/ConnectionDefinition identification * ManagedConnectionFactory * Pool * Security * ConnectionManager * Proxy/JNDI binding 2) Write an optimized version of the MetaData for the DataSource deployments which are really a simplified version of the ConnectionFactory deployments with some hardwiring. 3) Write a service that deploys the ConnectionFactory (creates MBeans) from the MetaData and undeploys them based on their id (jndi binding). 4) Convert the ConnectionFactory deployer to construct the MetaData from the -ds.xml files and invoke the service new service. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBMQ-5) Message Bridge
Message Bridge -- Key: JBMQ-5 URL: http://jira.jboss.com/jira/browse/JBMQ-5 Project: JBoss MQ Type: Task Reporter: Adrian Brock Priority: Minor Implementation of a MessageBridge. -- This is a proxy that allows messages to be sent to one JMS server and then forwarded to the real destination. To the senders this looks like a plain queue or topic. This is the simplist implementation, more performant implementations are possible: 1) Implement the bridge as a new destination type within JBossMQ 2) It will behave similarly to a Queue but will not accept external receivers. 3) On a background thread (inside a JTA transaction) take some messages from the queue and send them to the real destination. 4) The background thread should automatically recover from a failed connection and retry at configurable intervals. Similarly it should keep retrying if the connection cannot be instantiated at initial startup. This is similar to what the MDB does. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBMQ-2) Need better control over the pm memory usage during destination recovery
[ http://jira.jboss.com/jira/browse/JBMQ-2?page=history ] Adrian Brock updated JBMQ-2: Component: Persistence Need better control over the pm memory usage during destination recovery Key: JBMQ-2 URL: http://jira.jboss.com/jira/browse/JBMQ-2 Project: JBoss MQ Type: Patch Components: Persistence Versions: JBossAS-3.2.5 Reporter: Scott M Stark Assignee: Adrian Brock When starting up jboss with a destination with either a large number or very large persistent messages, the jdbc pm may run out of memory if the select * from the db results in the jdbc driver pulling in all of the records. We need to either write the pm with this expectation or allow for some configuration to avoid this. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBJCA-9) XID usage for transaction inflow
[ http://jira.jboss.com/jira/browse/JBJCA-9?page=history ] Adrian Brock reassigned JBJCA-9: Assign To: (was: Adrian Brock) XID usage for transaction inflow Key: JBJCA-9 URL: http://jira.jboss.com/jira/browse/JBJCA-9 Project: JBoss JCA Type: Task Reporter: Adrian Brock Forum Discussion Thread: http://www.jboss.org/index.html?module=bbop=viewtopict=48680 Currently in transaction inflow we use the generated JBoss local id. To properly process distributed transactions, this should really be inflow's XID. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBJCA-5) Interceptors
Interceptors Key: JBJCA-5 URL: http://jira.jboss.com/jira/browse/JBJCA-5 Project: JBoss JCA Type: Task Reporter: Adrian Brock Assigned to: Adrian Brock Priority: Minor Forums discussion thread: http://www.jboss.org/index.html?module=bbop=viewtopict=48683 This is really a major rewrite of the JCA implementation to be less monolithic so this will need some careful design and consideration and breaking up into more fine grained tasks. The idea is to provide containers/interceptors for the components within the JCA module such that these components can be more easily customised and developed according to the needs of each user. There are three main interceptor stacks that I can think of: 1) ConnectionManager (connection allocation) This provides an interceptor stack behind the ConnectionFactory/DataSource proxy to process the allocateConnection invocation. It will look something like: ConnectionFactory proxy - ConnectionManager interceptor - Pooling interceptor 2) ManagedConnection/ConnectionEventListener (connection management) This stack provides most of the features that are currently performed by the BaseManagerConnection2$ConnectionListener and their supporting methods, but as an interceptor stack. As now they will largely be driven by the events from the resource adapter, and it this object that is actually pooled. 3) Resource Adaptors The JDBC and JMS adaptors should be implemented as interceptor stacks to allow optional interceptors like statistics collection, custom behaviour and also to perform vendor specific processing/workarounds. Where AOP can be used, we could actually instrument the vendor classes so we can also expose vendor specific methods, not just the JDBC interfaces. This would remove the requirement to do things like getUnderlyingConection() by user code. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBJCA-9) XID usage for transaction inflow
[ http://jira.jboss.com/jira/browse/JBJCA-9?page=history ] Adrian Brock updated JBJCA-9: - Description: Forum Discussion Thread: http://www.jboss.org/index.html?module=bbop=viewtopict=48680 Currently in transaction inflow we use the generated JBoss local id. To properly process distributed transactions, this should really be inflow's XID. was: Currently in transaction inflow we use the generated JBoss local id. To properly process distributed transactions, this should really be inflow's XID. XID usage for transaction inflow Key: JBJCA-9 URL: http://jira.jboss.com/jira/browse/JBJCA-9 Project: JBoss JCA Type: Task Reporter: Adrian Brock Assignee: Adrian Brock Forum Discussion Thread: http://www.jboss.org/index.html?module=bbop=viewtopict=48680 Currently in transaction inflow we use the generated JBoss local id. To properly process distributed transactions, this should really be inflow's XID. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBMQ-7) Improved management
[ http://jira.jboss.com/jira/browse/JBMQ-7?page=history ] Adrian Brock updated JBMQ-7: Component: Server Improved management --- Key: JBMQ-7 URL: http://jira.jboss.com/jira/browse/JBMQ-7 Project: JBoss MQ Type: Task Components: Server Reporter: Adrian Brock Priority: Minor There are a number of areas in JBossMQ that could be better exposed for management. The main one is the ClientConsumers. This would allow an admin to break a connection with a client and also see stats at the client level. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBMQ-2) Need better control over the pm memory usage during destination recovery
[ http://jira.jboss.com/jira/browse/JBMQ-2?page=comments#action_12310801 ] Adrian Brock commented on JBMQ-2: - Having said that, all that is really needed is enough information to create MessageReference. This could be acheived by adding extra columns to the database for each property used in MessageReference.init() Need better control over the pm memory usage during destination recovery Key: JBMQ-2 URL: http://jira.jboss.com/jira/browse/JBMQ-2 Project: JBoss MQ Type: Patch Versions: JBossAS-3.2.5 Reporter: Scott M Stark Assignee: Adrian Brock When starting up jboss with a destination with either a large number or very large persistent messages, the jdbc pm may run out of memory if the select * from the db results in the jdbc driver pulling in all of the records. We need to either write the pm with this expectation or allow for some configuration to avoid this. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBJTA-2) Implement JTS
[ http://jira.jboss.com/jira/browse/JBJTA-2?page=history ] Adrian Brock updated JBJTA-2: - Fix Version: JBossAS-5.0 Beta Implement JTS - Key: JBJTA-2 URL: http://jira.jboss.com/jira/browse/JBJTA-2 Project: JBoss JTA Type: Task Reporter: Adrian Brock Priority: Minor Fix For: JBossAS-5.0 Beta Implement JTS We at least want to implement the optional compatibility with OTS at the IIOP level. Additional features that would be nice to have: 1) Distributed transactions over any protocol - i.e. protocol independenct TPCs using JBoss Remoting 2) Multithreaded use of a transaction with a (pluggable?) mechanism for reconciliation at transaction commit. Although there are still places within J2EE that disallow multi-threaded use of a transaction, e.g. SFSB, the JCA workmanager, etc. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBJTA-2) Implement JTS
Implement JTS - Key: JBJTA-2 URL: http://jira.jboss.com/jira/browse/JBJTA-2 Project: JBoss JTA Type: Task Reporter: Adrian Brock Priority: Minor Implement JTS We at least want to implement the optional compatibility with OTS at the IIOP level. Additional features that would be nice to have: 1) Distributed transactions over any protocol - i.e. protocol independenct TPCs using JBoss Remoting 2) Multithreaded use of a transaction with a (pluggable?) mechanism for reconciliation at transaction commit. Although there are still places within J2EE that disallow multi-threaded use of a transaction, e.g. SFSB, the JCA workmanager, etc. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBJCA-4) Improved management
[ http://jira.jboss.com/jira/browse/JBJCA-4?page=history ] Adrian Brock updated JBJCA-4: - Priority: Minor (was: Major) Improved management --- Key: JBJCA-4 URL: http://jira.jboss.com/jira/browse/JBJCA-4 Project: JBoss JCA Type: Task Reporter: Adrian Brock Priority: Minor Forum Discussion Thread: http://www.jboss.org/index.html?module=bbop=viewtopict=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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBMQ-2) Need better control over the pm memory usage during destination recovery
[ http://jira.jboss.com/jira/browse/JBMQ-2?page=comments#action_12310802 ] Adrian Brock commented on JBMQ-2: - The real solution to the problem is here: http://jboss.org/index.html?module=bbop=viewtopict=46186 Need better control over the pm memory usage during destination recovery Key: JBMQ-2 URL: http://jira.jboss.com/jira/browse/JBMQ-2 Project: JBoss MQ Type: Patch Versions: JBossAS-3.2.5 Reporter: Scott M Stark Assignee: Adrian Brock When starting up jboss with a destination with either a large number or very large persistent messages, the jdbc pm may run out of memory if the select * from the db results in the jdbc driver pulling in all of the records. We need to either write the pm with this expectation or allow for some configuration to avoid this. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-31) CachedConnectionManager - inUseConnections not correct
[ http://jira.jboss.com/jira/browse/JBAS-31?page=history ] Adrian Brock closed JBAS-31: Resolution: Done Fix Version: JBossAS-3.2.7 Final Fixed. unregisterConnection now removes the connection from the map as well as the invocation context stack. I also backported the transaction completion checking from JBoss4 as well as changing it to check TxUtils.isActive(tx) rather than tx != null before creating a transaction synchronization. CachedConnectionManager - inUseConnections not correct -- Key: JBAS-31 URL: http://jira.jboss.com/jira/browse/JBAS-31 Project: JBoss Application Server Type: Bug Components: JCA service Versions: JBossAS-3.2.6 Final Reporter: Scott M Stark Assignee: Adrian Brock Fix For: JBossAS-3.2.7 Final Attachments: test.jsp For CachedConnectionManager service debug option is enabled to monitor connections. !-- Enable connection close debug monitoring -- attribute name=Debugtrue/attribute Using jmx-console, if we look at the inUseCount property. The number displayed is not consitent with the underlying connection pool. listInUseConnections shows stack traces for connections that have been closed long back. It take a long time for the inUseCount to drop down, but never drops to 0 even after the connection pools correctly show inUseCount as 0. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBJCA-6) JMS Message Inflow
[ http://jira.jboss.com/jira/browse/JBJCA-6?page=history ] Adrian Brock updated JBJCA-6: - Description: Forums Discussion Thread: http://www.jboss.org/index.html?module=bbop=viewtopict=48672 The JMS message inflow in the JMS resource adapter needs properly testing. There are basic tests, but the following are missing: 1) Complete tests of edge cases for each configuration parameter in the activation spec 2) Failure tests to confirm the implementation handles error gracefully 3) Stress tests to make sure there the implementation is stable 4) Performance tests to optimize the implementation Additionally, we need to confirm that it is possible to use this implementation for EJB2.0 style deployments and hence as the default configuration. This should be possible provided the user has not created their own container configuration that uses the old JMSContainerInvoker explicitly. was: The JMS message inflow in the JMS resource adapter needs properly testing. There are basic tests, but the following are missing: 1) Complete tests of edge cases for each configuration parameter in the activation spec 2) Failure tests to confirm the implementation handles error gracefully 3) Stress tests to make sure there the implementation is stable 4) Performance tests to optimize the implementation Additionally, we need to confirm that it is possible to use this implementation for EJB2.0 style deployments and hence as the default configuration. This should be possible provided the user has not created their own container configuration that uses the old JMSContainerInvoker explicitly. JMS Message Inflow -- Key: JBJCA-6 URL: http://jira.jboss.com/jira/browse/JBJCA-6 Project: JBoss JCA Type: Task Reporter: Adrian Brock Assignee: Adrian Brock Forums Discussion Thread: http://www.jboss.org/index.html?module=bbop=viewtopict=48672 The JMS message inflow in the JMS resource adapter needs properly testing. There are basic tests, but the following are missing: 1) Complete tests of edge cases for each configuration parameter in the activation spec 2) Failure tests to confirm the implementation handles error gracefully 3) Stress tests to make sure there the implementation is stable 4) Performance tests to optimize the implementation Additionally, we need to confirm that it is possible to use this implementation for EJB2.0 style deployments and hence as the default configuration. This should be possible provided the user has not created their own container configuration that uses the old JMSContainerInvoker explicitly. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-65) MDB Deployment ignores activation-config
[ http://jira.jboss.com/jira/browse/JBAS-65?page=history ] Adrian Brock closed JBAS-65: Resolution: Duplicate Issue Closed as a duplicate. MDB Deployment ignores activation-config Key: JBAS-65 URL: http://jira.jboss.com/jira/browse/JBAS-65 Project: JBoss Application Server Type: Bug Components: EJBs Versions: JBossAS-4.0.1RC1 Environment: Sun JVM 5 JBOSS: 4.0.1 RC1 Reporter: Michael Kopp Assignee: Adrian Brock I use ejb-jar.xml with EJB spec 2.1. Jboss ignores the message-selector on the following MDB: message-driven description![CDATA[]]/description ejb-nameTransactionWriterBean/ejb-name ejb-classcom.ftisoft.streetlamp.ejb.TransactionWriter/ejb-class messaging-typejavax.jms.MessageListener/messaging-type transaction-typeContainer/transaction-type message-destination-typejavax.jms.Topic/message-destination-type activation-config activation-config-property activation-config-property-namedestinationType/activation-config-property-name activation-config-property-valuejavax.jms.Topic/activation-config-property-value /activation-config-property activation-config-property activation-config-property-namemessageSelector/activation-config-property-name activation-config-property-valuestreetlampWritten lt; true/activation-config-property-value /activation-config-property /activation-config resource-ref res-ref-namejdbc/HibernateFactory/res-ref-name res-typenet.sf.hibernate.SessionFactory/res-type res-authContainer/res-auth /resource-ref /message-driven Furthermore I see the following Warnings during deployment: 11:14:34,971 WARN [JMSContainerInvoker] No message-driven-destination given; using; guessing type 11:14:35,142 WARN [JMSContainerInvoker] No message-driven-destination given; using; guessing type 11:14:35,365 WARN [JMSContainerInvoker] Could not determine destination type, defaults to: javax.jms.Topic 11:14:35,691 WARN [JMSContainerInvoker] No message-driven-destination given; using; guessing type 11:14:35,717 WARN [JMSContainerInvoker] No message-driven-destination given; using; guessing type -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBMQ-7) Improved management
Improved management --- Key: JBMQ-7 URL: http://jira.jboss.com/jira/browse/JBMQ-7 Project: JBoss MQ Type: Task Reporter: Adrian Brock Priority: Minor There are a number of areas in JBossMQ that could be better exposed for management. The main one is the ClientConsumers. This would allow an admin to break a connection with a client and also see stats at the client level. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBMQ-13) XA Recovery
XA Recovery --- Key: JBMQ-13 URL: http://jira.jboss.com/jira/browse/JBMQ-13 Project: JBoss MQ Type: Task Components: Persistence Reporter: Adrian Brock XARecovery needs to completed by implementing XAResource.recover(). To make this work, the persistence manager will need to remember the Xids and return the list in response to the above request. The current implementation which heuristically rollsback incomplete transactions at recovery will need to be disabled when recovery is required. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBMQ-16) ReadAhead and DUPS_OK message acknowledgement
ReadAhead and DUPS_OK message acknowledgement - Key: JBMQ-16 URL: http://jira.jboss.com/jira/browse/JBMQ-16 Project: JBoss MQ Type: Task Components: Transport Reporter: Adrian Brock Performance can be improved by sending mulitple messages in one request to the client when they are using a MessageListener. Similary, there is no implementation of DUPS_OK message acknowledgement, which would reduce the number of network requests required to acknowledge receipt of messages. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-63) MicroContainer work for JBoss-5.0.0 Alpha
MicroContainer work for JBoss-5.0.0 Alpha - Key: JBAS-63 URL: http://jira.jboss.com/jira/browse/JBAS-63 Project: JBoss Application Server Type: Task Components: MicroContainer bus Reporter: Adrian Brock Assigned to: Adrian Brock Fix For: JBossAS-5.0 Alpha Schedule -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-62) JMX work for JBoss-5.0.0 Alpha
JMX work for JBoss-5.0.0 Alpha -- Key: JBAS-62 URL: http://jira.jboss.com/jira/browse/JBAS-62 Project: JBoss Application Server Type: Task Components: JMX Reporter: Adrian Brock Assigned to: Adrian Brock Fix For: JBossAS-5.0 Alpha Schedule -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBJCA-9) XID usage for transaction inflow
XID usage for transaction inflow Key: JBJCA-9 URL: http://jira.jboss.com/jira/browse/JBJCA-9 Project: JBoss JCA Type: Task Reporter: Adrian Brock Assigned to: Adrian Brock Currently in transaction inflow we use the generated JBoss local id. To properly process distributed transactions, this should really be inflow's XID. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-61) JTA work for JBoss-5.0.0Beta
JTA work for JBoss-5.0.0Beta Key: JBAS-61 URL: http://jira.jboss.com/jira/browse/JBAS-61 Project: JBoss Application Server Type: Task Components: JTA service Reporter: Adrian Brock Fix For: JBossAS-5.0 Beta Schedule -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-59) JCA work for JBoss-5.0.0Beta
JCA work for JBoss-5.0.0Beta Key: JBAS-59 URL: http://jira.jboss.com/jira/browse/JBAS-59 Project: JBoss Application Server Type: Task Components: JCA service Reporter: Adrian Brock Fix For: JBossAS-5.0 Beta Schedule -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBMQ-9) Thread Pool improvements on the server
Thread Pool improvements on the server -- Key: JBMQ-9 URL: http://jira.jboss.com/jira/browse/JBMQ-9 Project: JBoss MQ Type: Task Components: Server Reporter: Adrian Brock There are a number of different components on the server that use thread pools. 1) Invocation Layers 2) Client Consumer for delivering messages 3) Scheduled delivery/message expiration These need to be combined to share threads and minimize context switching where possible. The thread pool should be based on the BasicThreadPool from jboss-common -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBMQ-14) Clustered Invocation Layer
Clustered Invocation Layer -- Key: JBMQ-14 URL: http://jira.jboss.com/jira/browse/JBMQ-14 Project: JBoss MQ Type: Task Components: Transport Reporter: Adrian Brock Priority: Minor Clustered Invocation Layer 1) Transportation of the cluster view to the client. 2) Persistent connections that allows the server to recover the client's state after a failure. Both these together will mean the client can transparently failover after a server failure. The persistent connections could be used without clustering where the client waits for server recovery. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBMQ-15) Message Serialization
Message Serialization - Key: JBMQ-15 URL: http://jira.jboss.com/jira/browse/JBMQ-15 Project: JBoss MQ Type: Task Components: Transport Reporter: Adrian Brock The message body does not need to be deserialized on the server. It could just be retained as byte[] This will avoid unnecessary Object serialiation at the transport and persistent layer inside the server. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-58) Complete testing of JMS Message Inflow
Complete testing of JMS Message Inflow -- Key: JBAS-58 URL: http://jira.jboss.com/jira/browse/JBAS-58 Project: JBoss Application Server Type: Task Components: JCA service Versions: JBossAS-4.0.0 Final Reporter: Adrian Brock Assigned to: Adrian Brock Fix For: JBossAS-4.0.2 Final Complete the testing of JMS Message Inflow -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBJCA-10) More Configurable Bootstrap Context
More Configurable Bootstrap Context --- Key: JBJCA-10 URL: http://jira.jboss.com/jira/browse/JBJCA-10 Project: JBoss JCA Type: Task Reporter: Adrian Brock Priority: Minor Forums Discussion Thread: http://www.jboss.org/index.html?module=bbop=viewtopict=48677 Need a mechanism to make the Bootstrap context passed to rar more configurable. Currently a single context is passed to all rars. e.g. A rar may want its own WorkManager/ThreadPool -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBJCA-7) Message Inflow targetting MBeans/POJOs
Message Inflow targetting MBeans/POJOs -- Key: JBJCA-7 URL: http://jira.jboss.com/jira/browse/JBJCA-7 Project: JBoss JCA Type: Task Reporter: Adrian Brock Priority: Minor Forums Discussion Thread: http://www.jboss.org/index.html?module=bbop=viewtopict=48674 The JCA message inflow could target MBeans or POJOs rather than EJBs. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBJCA-8) Improvements to Message Inflow
Improvements to Message Inflow -- Key: JBJCA-8 URL: http://jira.jboss.com/jira/browse/JBJCA-8 Project: JBoss JCA Type: Task Reporter: Adrian Brock Assigned to: Adrian Brock Priority: Minor Forums Discussion Thread: http://www.jboss.org/index.html?module=bbop=viewtopict=48675 Need to determine what quality of service features should be provided for message inflow. The most obvious would be delivery side pooling where the RAR does not do this or does this badly. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBMQ-63) Wrong behaviour with multiple listeners to a queue
[ http://jira.jboss.com/jira/browse/JBMQ-63?page=comments#action_12313195 ] Adrian Brock commented on JBMQ-63: -- Logged In: YES user_id=9459 I am willing to be proved wrong by experiment, but an ArrayList is more efficient for this use case (in fact in most use cases). 1) It requires no additional object contructions, except the array object when resizing (linked lists have internal node objects containing the next pointer) 2) It can be efficiently iterated with a for(i in list) list.get(i); whereas a LinkedList requires contructing an iterator object on every request Since the List will be pretty much constant size, the only advantage a LinkedList has is that removal on an already located element is quicker. It is probably worth creating an interface for the receiver operations and let people plugin the implementation that best fits their use case. Wrong behaviour with multiple listeners to a queue -- Key: JBMQ-63 URL: http://jira.jboss.com/jira/browse/JBMQ-63 Project: JBoss MQ Type: Feature Request Reporter: SourceForge User Assignee: Adrian Brock SourceForge Submitter: sverkera . I wanted to have messages distibruted to multiple listeners from one queue but no matter how many listeners I added, it was always the first and occationally the second that were given all the messages. I asked in the forum in thread http://www.jboss.org/thread.jsp? forum=48thread=36553 about this and eventually I found out the answer. The answer is to replace HashSet receivers = new HashSet(); in org.jboss.mq.server.BasicQueue with LinkedList receivers = new LinkedList(); Changing to LinkedList gave the expected behaviour, messages are now distributed evenly to all listeners. The reason for that is explained in the text below which I've copied from the thread. I've been running the server with this patch for a couple of months now and it works excellent. (Below is text copied from the thread) BasicQueue keeps the waiting receivers in a HashSet and when it gets a messag, it calls the internalAddMessage method which iterates through the receivers and picks the first subscription that matches the headers of the message and pass the message on to it's ClientConsumer instance. After that it removes that subscription from the receivers. The ClientConsumer passes the message on through the registered ClientIL to a Connection's asyncDeliver method. It is then passed on to a SpyConsumer instance with the addMessage method. In my case that is a SpyMessageConsumer which puts the message in a LinkedList. A thread then picks it from the LinkedList and call the onMessage method on my listener. I haven't found out exactly how yet but when the ClientConsumer has delivered the message it's subscription is added again to the receivers in BasicQueue. receivers is a HashSet instance and it's implementation uses a HashMap to store it's entries in the HashMap key. HashMap keys are stored in an array and when a new key/value pair (the value is null in this case) is added, the array is searched for the first empty position in the array, which happens to be the first position since that is the one where the key were removed by the iterator in BasicQueue.internalAddMessage. This means that the order of the subscriptions is maintained more or less to be the same as when they were registered the first time. internalAddMessage picks the first subscription and the only time it will pick the second subscription is when it receives a message before the first subscription has finished processing the previous message. ClientConsumer uses a thread pool so it looks like that the thread that calls it from BasicQueue just drops it of on a thread from the pool and returns so most of the times the first subscription process the messages as fast as they arrive so it's only in a few cases the second subscriber get used. That means that most of the messages ends up in the LinkedList of the SpyMessageConsumer to which my first listeners is registered. The second listener receives a few and the rest of them receives nothing.. The behaviour I expected was that the messages would be evenly between the listeners, I think that is logica. That behaviour should be acomplished by changing the receivers in BasicQueue from a HashSet to a LinkedList, then the subscriber that has finished is added to the end of the list and have to wait until last. I'll test that and see what happens. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-589) Transaction equality test bug
[ http://jira.jboss.com/jira/browse/JBAS-589?page=comments#action_12312172 ] Adrian Brock commented on JBAS-589: --- Logged In: YES user_id=9459 This has been fixed in TxConnectionManager Transaction equality test bug - Key: JBAS-589 URL: http://jira.jboss.com/jira/browse/JBAS-589 Project: JBoss Application Server Type: Bug Components: JCA service Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Adrian Brock SourceForge Submitter: marklittle . In JBoss 3.2 RC1, the org.jboss.resource.connectionmanager.TxConnectionMa nager class checks for transaction equality using the = operator. In general you can't guarantee that this will work and particularly for distributed transactions. That's why the JTA specification has a specific section in 3.3 on transaction equality: The transaction manager must implement the Transaction object s equals method to allow comparison between the target object and another Transaction object. I think this may happen in more than just this class as well. Mark. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[JBoss-dev] [JBoss JIRA] Moved: (JBJCA-1) Force closing of all database connections
[ http://jira.jboss.com/jira/browse/JBJCA-1?page=history ] Adrian Brock moved JBAS-27 to JBJCA-1: -- Project: JBoss JCA (was: JBoss Application Server) Key: JBJCA-1 (was: JBAS-27) Component: (was: JCA service) Version: (was: JBossAS-4.0.1) Force closing of all database connections - Key: JBJCA-1 URL: http://jira.jboss.com/jira/browse/JBJCA-1 Project: JBoss JCA Type: Feature Request Reporter: Tom Elrod Assignee: Scott M Stark Priority: Minor Would like enhancement of the JBossManagedConnectionPool's flush() method to not only close those connections in the pool, but also mark those in use so that when they are returned to the pool, they are closed as well. Just using idle-timeout-minutes is not enough in certain casess as wehn under heavy load, as connections may not be idle long enough to be picked up and closed. One particular use case for needing this feature is when using plsql, which when updated on the server, will cause errors when the same open connection is used after this update (so need to close and re-open the connections). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBJCA-1) Force closing of all database connections
[ http://jira.jboss.com/jira/browse/JBJCA-1?page=comments#action_12310700 ] Adrian Brock commented on JBJCA-1: -- It already does this. JBossManagedConnectionPool.flush() delegates to InternalManagedConnectionPool.destroy/flush() See the implementation of the latter method. Force closing of all database connections - Key: JBJCA-1 URL: http://jira.jboss.com/jira/browse/JBJCA-1 Project: JBoss JCA Type: Feature Request Reporter: Tom Elrod Assignee: Scott M Stark Priority: Minor Would like enhancement of the JBossManagedConnectionPool's flush() method to not only close those connections in the pool, but also mark those in use so that when they are returned to the pool, they are closed as well. Just using idle-timeout-minutes is not enough in certain casess as wehn under heavy load, as connections may not be idle long enough to be picked up and closed. One particular use case for needing this feature is when using plsql, which when updated on the server, will cause errors when the same open connection is used after this update (so need to close and re-open the connections). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBJCA-1) Force closing of all database connections
[ http://jira.jboss.com/jira/browse/JBJCA-1?page=history ] Adrian Brock closed JBJCA-1: Assign To: Adrian Brock (was: Scott M Stark) Resolution: Rejected Force closing of all database connections - Key: JBJCA-1 URL: http://jira.jboss.com/jira/browse/JBJCA-1 Project: JBoss JCA Type: Feature Request Reporter: Tom Elrod Assignee: Adrian Brock Priority: Minor Would like enhancement of the JBossManagedConnectionPool's flush() method to not only close those connections in the pool, but also mark those in use so that when they are returned to the pool, they are closed as well. Just using idle-timeout-minutes is not enough in certain casess as wehn under heavy load, as connections may not be idle long enough to be picked up and closed. One particular use case for needing this feature is when using plsql, which when updated on the server, will cause errors when the same open connection is used after this update (so need to close and re-open the connections). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBMICROCONT-1) 1_0_0M1 release
[ http://jira.jboss.com/jira/browse/JBMICROCONT-1?page=history ] Adrian Brock closed JBMICROCONT-1: -- Resolution: Done 1_0_0M1 release --- Key: JBMICROCONT-1 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-1 Project: JBoss MicroContainer Type: Task Versions: JBossMC_1_0_0M1 Reporter: Adrian Brock Assignee: Adrian Brock Fix For: JBossMC_1_0_0M1 Initial milestone release of JBoss Microcontainer RoadMap --- The first milestone reproduces the core features of JMX Microkernel in a POJO environment. Registry - provides the ability to access beans and services using a name. The registry is expanded to include other registry implementations using KernelRegistryFactorys, e.g. JNDI Bus - provides name/detyped invocations using JoinPoints. Configurator - allows beans to be instantiated and configured from metadata. Bean Info - provides a self description of the bean. Bean Metadata - used to configure the bean deployment. Controller - configures and registers beans when dependencies are satisfied. Classloading - allows the construction of nontrivial classloading domains. Bootstrap - allows a simple mechanism to construct the kernel. Events - an event notification mechanism. Container - a mechanism to allow aspects to enhance the beans. Installation: unzip microcontainer-M1.zip or tar -xzf microcontainer-M1.tgz Test (make sure ant1.6 and java 1.4 is in the classpath) cd microcontainer-M1/examples/bootstrap ant You should see the output described in microcontainer-M1/examples/bootstrap/readme.txt Other examples are described in examples/readme.txt Documentation - The subfolders api and docs contain documentation for the release. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBMICROCONT-1) 1_0_0M1 release
1_0_0M1 release --- Key: JBMICROCONT-1 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-1 Project: JBoss MicroContainer Type: Task Versions: JBossMC_1_0_0M1 Reporter: Adrian Brock Assigned to: Adrian Brock Fix For: JBossMC_1_0_0M1 Initial milestone release of JBoss Microcontainer RoadMap --- The first milestone reproduces the core features of JMX Microkernel in a POJO environment. Registry - provides the ability to access beans and services using a name. The registry is expanded to include other registry implementations using KernelRegistryFactorys, e.g. JNDI Bus - provides name/detyped invocations using JoinPoints. Configurator - allows beans to be instantiated and configured from metadata. Bean Info - provides a self description of the bean. Bean Metadata - used to configure the bean deployment. Controller - configures and registers beans when dependencies are satisfied. Classloading - allows the construction of nontrivial classloading domains. Bootstrap - allows a simple mechanism to construct the kernel. Events - an event notification mechanism. Container - a mechanism to allow aspects to enhance the beans. Installation: unzip microcontainer-M1.zip or tar -xzf microcontainer-M1.tgz Test (make sure ant1.6 and java 1.4 is in the classpath) cd microcontainer-M1/examples/bootstrap ant You should see the output described in microcontainer-M1/examples/bootstrap/readme.txt Other examples are described in examples/readme.txt Documentation - The subfolders api and docs contain documentation for the release. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBMQ-1) Simple*MessageDrivenUnitTestCase failing with no messages
[ http://jira.jboss.com/jira/browse/JBMQ-1?page=comments#action_12310682 ]
Adrian Brock commented on JBMQ-1:
-
This looks like a problem with the DLQ handler processing the message
at the first request. The message has not been redelivered! See
the JMSRedelivered property.
Probably related to the ActivationSpec config changes?
Simple*MessageDrivenUnitTestCase failing with no messages
-
Key: JBMQ-1
URL: http://jira.jboss.com/jira/browse/JBMQ-1
Project: JBoss JMS (JBossMQ)
Type: Bug
Versions: JBossAS-4.0.1
Environment: current 4.0 branch with jdk 1.4.2_05.
Reporter: Scott M Stark
Assignee: Scott M Stark
Both the
org.jboss.test.messagedriven.test.SimpleQueueMessageDrivenUnitTestCase and
org.jboss.test.messagedriven.test.SimpleTopicMessageDrivenUnitTestCase are
failing with timeouts waiting for messages. This is do to the message being
dumped to the DLQ for some reason:
06:36:59,556 INFO [EJBDeployer] Deployed:
file:/cvs/JBoss4.0/jboss-4.0/testsuite/output/lib/mdbtopicxa.jar
06:37:00,171 WARN [AbstractDLQHandler] Message redelivered=1 max=0 sending
it to the dlq org.jboss.mq.SpyMessage {
Header {
jmsDestination : TOPIC.testTopic
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 4
jmsMessageID: ID:3-11018254200691
jmsTimeStamp: 1101825420069
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {jboss_test_MESSAGEID=1}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:3
}
}
06:37:24,668 INFO [EJBDeployer] Undeploying:
file:/cvs/JBoss4.0/jboss-4.0/testsuite/output/lib/mdbtopicxa.jar
06:37:24,713 INFO [EjbModule] Undeployed TestMDB
06:44:50,449 INFO [EjbModule] Deploying TestMDB
06:44:50,556 INFO [EJBDeployer] Deployed:
file:/cvs/JBoss4.0/jboss-4.0/testsuite/output/lib/mdbqueuexa.jar
06:44:51,083 WARN [AbstractDLQHandler] Message redelivered=1 max=0 sending
it to the dlq org.jboss.mq.SpyMessage {
Header {
jmsDestination : QUEUE.testQueue
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 4
jmsMessageID: ID:6-11018258910651
jmsTimeStamp: 1101825891064
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {jboss_test_MESSAGEID=1}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:6
}
}
06:45:15,667 INFO [EJBDeployer] Undeploying:
file:/cvs/JBoss4.0/jboss-4.0/testsuite/output/lib/mdbqueuexa.jar
06:45:15,716 INFO [EjbModule] Undeployed TestMDB
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBMQ-1) Simple*MessageDrivenUnitTestCase failing with no messages
[ http://jira.jboss.com/jira/browse/JBMQ-1?page=comments#action_12310683 ]
Adrian Brock commented on JBMQ-1:
-
While you are there, this message
Message redelivered=1 max=0
should read
Message delivered=1 max=0
Simple*MessageDrivenUnitTestCase failing with no messages
-
Key: JBMQ-1
URL: http://jira.jboss.com/jira/browse/JBMQ-1
Project: JBoss JMS (JBossMQ)
Type: Bug
Versions: JBossAS-4.0.1
Environment: current 4.0 branch with jdk 1.4.2_05.
Reporter: Scott M Stark
Assignee: Scott M Stark
Both the
org.jboss.test.messagedriven.test.SimpleQueueMessageDrivenUnitTestCase and
org.jboss.test.messagedriven.test.SimpleTopicMessageDrivenUnitTestCase are
failing with timeouts waiting for messages. This is do to the message being
dumped to the DLQ for some reason:
06:36:59,556 INFO [EJBDeployer] Deployed:
file:/cvs/JBoss4.0/jboss-4.0/testsuite/output/lib/mdbtopicxa.jar
06:37:00,171 WARN [AbstractDLQHandler] Message redelivered=1 max=0 sending
it to the dlq org.jboss.mq.SpyMessage {
Header {
jmsDestination : TOPIC.testTopic
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 4
jmsMessageID: ID:3-11018254200691
jmsTimeStamp: 1101825420069
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {jboss_test_MESSAGEID=1}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:3
}
}
06:37:24,668 INFO [EJBDeployer] Undeploying:
file:/cvs/JBoss4.0/jboss-4.0/testsuite/output/lib/mdbtopicxa.jar
06:37:24,713 INFO [EjbModule] Undeployed TestMDB
06:44:50,449 INFO [EjbModule] Deploying TestMDB
06:44:50,556 INFO [EJBDeployer] Deployed:
file:/cvs/JBoss4.0/jboss-4.0/testsuite/output/lib/mdbqueuexa.jar
06:44:51,083 WARN [AbstractDLQHandler] Message redelivered=1 max=0 sending
it to the dlq org.jboss.mq.SpyMessage {
Header {
jmsDestination : QUEUE.testQueue
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 4
jmsMessageID: ID:6-11018258910651
jmsTimeStamp: 1101825891064
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {jboss_test_MESSAGEID=1}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:6
}
}
06:45:15,667 INFO [EJBDeployer] Undeploying:
file:/cvs/JBoss4.0/jboss-4.0/testsuite/output/lib/mdbqueuexa.jar
06:45:15,716 INFO [EjbModule] Undeployed TestMDB
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBMQ-1) Simple*MessageDrivenUnitTestCase failing with no messages
[ http://jira.jboss.com/jira/browse/JBMQ-1?page=comments#action_12310688 ]
Adrian Brock commented on JBMQ-1:
-
Which other ones did you change?
This WIKI page needs updating:
http://www.jboss.org/wiki/Wiki.jsp?page=ConfigJMSMessageListener
Simple*MessageDrivenUnitTestCase failing with no messages
-
Key: JBMQ-1
URL: http://jira.jboss.com/jira/browse/JBMQ-1
Project: JBoss JMS (JBossMQ)
Type: Bug
Versions: JBossAS-4.0.1
Environment: current 4.0 branch with jdk 1.4.2_05.
Reporter: Scott M Stark
Assignee: Scott M Stark
Fix For: JBossAS-4.0.1
Both the
org.jboss.test.messagedriven.test.SimpleQueueMessageDrivenUnitTestCase and
org.jboss.test.messagedriven.test.SimpleTopicMessageDrivenUnitTestCase are
failing with timeouts waiting for messages. This is do to the message being
dumped to the DLQ for some reason:
06:36:59,556 INFO [EJBDeployer] Deployed:
file:/cvs/JBoss4.0/jboss-4.0/testsuite/output/lib/mdbtopicxa.jar
06:37:00,171 WARN [AbstractDLQHandler] Message redelivered=1 max=0 sending
it to the dlq org.jboss.mq.SpyMessage {
Header {
jmsDestination : TOPIC.testTopic
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 4
jmsMessageID: ID:3-11018254200691
jmsTimeStamp: 1101825420069
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {jboss_test_MESSAGEID=1}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:3
}
}
06:37:24,668 INFO [EJBDeployer] Undeploying:
file:/cvs/JBoss4.0/jboss-4.0/testsuite/output/lib/mdbtopicxa.jar
06:37:24,713 INFO [EjbModule] Undeployed TestMDB
06:44:50,449 INFO [EjbModule] Deploying TestMDB
06:44:50,556 INFO [EJBDeployer] Deployed:
file:/cvs/JBoss4.0/jboss-4.0/testsuite/output/lib/mdbqueuexa.jar
06:44:51,083 WARN [AbstractDLQHandler] Message redelivered=1 max=0 sending
it to the dlq org.jboss.mq.SpyMessage {
Header {
jmsDestination : QUEUE.testQueue
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 4
jmsMessageID: ID:6-11018258910651
jmsTimeStamp: 1101825891064
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {jboss_test_MESSAGEID=1}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:6
}
}
06:45:15,667 INFO [EJBDeployer] Undeploying:
file:/cvs/JBoss4.0/jboss-4.0/testsuite/output/lib/mdbqueuexa.jar
06:45:15,716 INFO [EjbModule] Undeployed TestMDB
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBXB-2) Xni parser has problems with short form tags
Xni parser has problems with short form tags Key: JBXB-2 URL: http://jira.jboss.com/jira/browse/JBXB-2 Project: JBoss XML Binding (JBossXB) Type: Bug Environment: jboss-head Reporter: Adrian Brock Assigned to: Alex Loubyansky The new Xni parser does not emit endElement() notifications for tags of the form mytag/ rather than mytag/mytag where it does. This means the stack of accepted elements gets out of step with the end element notifications. I've switched back to the Sax parser in the Unmarshaller as the default in jboss-head to avoid this problem. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Patches item 1041466 and 1042119
Why would they be assigned? They are patches to another patch that is not in the jboss codebase. The code depends upon Oracle specific apis. What is the license for those Oracle apis? LGPL compatible? On Tue, 2004-11-16 at 09:07, Rob v.d. Boom wrote: Message body follows: Hello Dear Adrian Brock, could you please check if i correctly filled out my bug report, since i don't see my items 1041466 and 1042119 assigned. Greetings, Rob v.d. Boom -- This message has been sent to you, a registered SourceForge.net user, by another site user, through the SourceForge.net site. This message has been delivered to your SourceForge.net mail alias. You may reply to this message using the Reply feature of your email client, or using the messaging facility of SourceForge.net at: https://sourceforge.net/sendmessage.php?touser=1134099 -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Patches item 1041466 and 1042119
These issues are about Oracle messaging. It has nothing todo with JBossMQ. Integration issues belong in the JBossServer category. I changed one of your issues to a bug report rather than a patch, but I'm not sure if it is bug or not (there is not enough information). Bug reports/patches should be filed after testing the latest release in the branch in this case 3.2.7 not 3.2.3 If you are asking for help, your question belongs in the user forums. at www.jboss.org If you want discuss any fix, use the bug/patch report you created. My mailbox is not the correct venue to discuss your problems. On Tue, 2004-11-16 at 14:24, Rob van der Boom wrote: 1041466: I'have submitted this because as far i can see it's jboss code. This because if i use Hypersonic in stead of oracle and simulating the longer time a connection needs to build up (by a delay also) the problem seems the same. The question is if it's a problem when requesting for a session from the jboss pool (when sessions are already created according to the jboss debug logging) but return a session=null. OR if it's a problem in oracle part because it has to do some checks if the sessions fysically is there ? 1042119: Again i see the Jboss Std session class creating a topic connection when configuration a MDB to a Queue. So the problem is in the Jboss class or a oracle implementation class of JMS. But if i'm not mistaken you can 'see' the problem is in oracle api's ? Greetings. Rob. -Original Message- From: Adrian Brock [mailto:[EMAIL PROTECTED] Sent: dinsdag 16 november 2004 14:47 To: Rob v.d. Boom Cc: [EMAIL PROTECTED] Subject: Re: Patches item 1041466 and 1042119 Why would they be assigned? They are patches to another patch that is not in the jboss codebase. The code depends upon Oracle specific apis. What is the license for those Oracle apis? LGPL compatible? On Tue, 2004-11-16 at 09:07, Rob v.d. Boom wrote: Message body follows: Hello Dear Adrian Brock, could you please check if i correctly filled out my bug report, since i don't see my items 1041466 and 1042119 assigned. Greetings, Rob v.d. Boom -- This message has been sent to you, a registered SourceForge.net user, by another site user, through the SourceForge.net site. This message has been delivered to your SourceForge.net mail alias. You may reply to this message using the Reply feature of your email client, or using the messaging facility of SourceForge.net at: https://sourceforge.net/sendmessage.php?touser=1134099 -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: jboss-head Build Failed
for comparing execution time between clustered and non-clustered calls (in other words, how much more does it cost to do HA). 1.1 added telrod testsuite/src/etc/cluster-harness/META-INF/ejb-jar.xml Added cluster benchmark test harness for comparing execution time between clustered and non-clustered calls (in other words, how much more does it cost to do HA). 1.1 added telrod testsuite/src/etc/cluster-harness/META-INF/jboss-app.xml Added cluster benchmark test harness for comparing execution time between clustered and non-clustered calls (in other words, how much more does it cost to do HA). 1.1 added telrod testsuite/src/etc/cluster-harness/META-INF/jboss.xml Added cluster benchmark test harness for comparing execution time between clustered and non-clustered calls (in other words, how much more does it cost to do HA). 1.1 added telrod testsuite/src/etc/cluster-harness/conf/META-INF/application.xml Added cluster benchmark test harness for comparing execution time between clustered and non-clustered calls (in other words, how much more does it cost to do HA). 1.1 added telrod testsuite/src/etc/cluster-harness/conf/META-INF/ejb-jar.xml Added cluster benchmark test harness for comparing execution time between clustered and non-clustered calls (in other words, how much more does it cost to do HA). 1.1 added telrod testsuite/src/etc/cluster-harness/conf/META-INF/jboss-app.xml Added cluster benchmark test harness for comparing execution time between clustered and non-clustered calls (in other words, how much more does it cost to do HA). 1.1 added telrod testsuite/src/etc/cluster-harness/conf/META-INF/jboss.xml Added cluster benchmark test harness for comparing execution time between clustered and non-clustered calls (in other words, how much more does it cost to do HA). 1.1 added telrod testsuite/src/etc/cluster-harness/conf/META-INF/services.properties Added cluster benchmark test harness for comparing execution time between clustered and non-clustered calls (in other words, how much more does it cost to do HA). 1.93 modified starksm varia/build.xml Filter out all logging config files from the ebxmlrr.war -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [jboss-cvs] jmx/src/main/org/jboss/mx/modelmbean XMBean.java
Please run the testsuite if you are going to make modifications to core parts of JBoss. This change has enabled AttributeChangeNotifications for all standard mbeans, which means people will be receiving notifications they didn't expect. As was the case with some failing tests in the testsuite. On Sat, 2004-10-16 at 20:43, Dimitris Andreadis wrote: User: andd Date: 04/10/16 12:43:51 Modified:src/main/org/jboss/mx/modelmbean XMBean.java Log: update ModelMBeanInvoker notification listener registry, even if the target resource is a NotificationBroadcaster, so that the XMBean's own AttributeValueChanges, still work. Revision ChangesPath 1.29 +9 -6 jmx/src/main/org/jboss/mx/modelmbean/XMBean.java Index: XMBean.java === RCS file: /cvsroot/jboss/jmx/src/main/org/jboss/mx/modelmbean/XMBean.java,v retrieving revision 1.28 retrieving revision 1.29 diff -u -r1.28 -r1.29 --- XMBean.java 10 Aug 2004 22:57:04 - 1.28 +++ XMBean.java 16 Oct 2004 19:43:51 - 1.29 @@ -397,8 +397,9 @@ // StandardMBeans and resources who implement NotificationBroadcaster if (resourceType.equals(STANDARD_MBEAN) || getResource() instanceof NotificationBroadcaster) addNotificationListenerToResource(listener, filter, handback); - else - super.addNotificationListener(listener, filter, handback); + + // update our listener registry anyway so that our AVCs still work + super.addNotificationListener(listener, filter, handback); } public void removeNotificationListener(NotificationListener listener) @@ -407,8 +408,9 @@ // StandardMBeans and resources who implement NotificationBroadcaster if (resourceType.equals(STANDARD_MBEAN) || getResource() instanceof NotificationBroadcaster) removeNotificationListenerFromResource(listener); - else - super.removeNotificationListener(listener); + + // update our listener registry anyway so that our AVCs still work + super.removeNotificationListener(listener); } public void removeNotificationListener(NotificationListener listener, @@ -419,8 +421,9 @@ // StandardMBeans and resources who implement NotificationBroadcaster if (resourceType.equals(STANDARD_MBEAN) || getResource() instanceof NotificationBroadcaster) removeNotificationListenerFromResource(listener, filter, handback); - else - super.removeNotificationListener(listener, filter, handback); + + // update our listener registry anyway so that our AVCs still work + super.removeNotificationListener(listener, filter, handback); } public MBeanNotificationInfo[] getNotificationInfo() --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ jboss-cvs-commits mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-cvs-commits -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Branch_3_2 and jdk 1.3
Also we don't
catch (Exception e)
{
e.printStackTrace();
}
and even worse
catch (Exception ignored)
{
// Nothing (eating exceptions is usually bad)
}
It should be
catch (Exception e)
{
log.warn(Some message, e); // for something unexpected or
log.trace(Some message, e); // otherwise
}
Nor do we log and throw. This just leads to logs that
are full of the same error message.
If you don't handle the exception, don't log it.
The only place that should log and throw are well defined
entry points like org.jboss.ejb.plugins.LogInterceptor
or org.jboss.deployment.MainDeployer
catch (Exception e)
{
log.error(Some message, e); // BAD - swamps the user
throw e;
}
On Fri, 2004-10-15 at 18:43, Adrian Brock wrote:
This is a friendly reminder for those who don't know about this
constraint.
JBoss-3.2.x is a j2ee1.3 implementation and as such, it must be
able to run on j2se 1.3. You cannot use java apis from j2se 1.4.
I'm going to go through the current codebase and remove all
usage of j2se 1.4 apis.
Examples:
1) URLDecode.decode(String) - no workaround
2) Boolean.valueOf(boolean)
I'm introducing a new method
Boolean org.jboss.util.Primitives.valueOf(boolean)
to replace this.
3) throw new RuntimeExecption(Throwable)
use throw new org.jboss.util.NestedRuntimeException(Throwable)
There is also a problem with some SSL classes from j2se 1.4
that needs to be conditionally compiled if we are going to
support compilation on j2se 1.3
--
Adrian Brock
Director of Support
Back Office
JBoss Inc.
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Branch_3_2 and jdk 1.3
Also we don't
catch (Exception e)
{
e.printStackTrace();
}
and even worse
catch (Exception ignored)
{
// Nothing (eating exceptions is usually bad)
}
It should be
catch (Exception e)
{
log.warn(Some message, e); // for something unexpected or
log.trace(Some message, e); // otherwise
}
Nor do we log and throw. This just leads to logs that
are full of the same error message.
If you don't handle the exception, don't log it.
The only place that should log and throw are well defined
entry points like org.jboss.ejb.plugins.LogInterceptor
or org.jboss.deployment.MainDeployer
catch (Exception e)
{
log.error(Some message, e); // BAD - swamps the user
throw e;
}
On Fri, 2004-10-15 at 18:43, Adrian Brock wrote:
This is a friendly reminder for those who don't know about this
constraint.
JBoss-3.2.x is a j2ee1.3 implementation and as such, it must be
able to run on j2se 1.3. You cannot use java apis from j2se 1.4.
I'm going to go through the current codebase and remove all
usage of j2se 1.4 apis.
Examples:
1) URLDecode.decode(String) - no workaround
2) Boolean.valueOf(boolean)
I'm introducing a new method
Boolean org.jboss.util.Primitives.valueOf(boolean)
to replace this.
3) throw new RuntimeExecption(Throwable)
use throw new org.jboss.util.NestedRuntimeException(Throwable)
There is also a problem with some SSL classes from j2se 1.4
that needs to be conditionally compiled if we are going to
support compilation on j2se 1.3
--
Adrian Brock
Director of Support
Back Office
JBoss Inc.
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Branch_3_2 and jdk 1.3
This is a friendly reminder for those who don't know about this constraint. JBoss-3.2.x is a j2ee1.3 implementation and as such, it must be able to run on j2se 1.3. You cannot use java apis from j2se 1.4. I'm going to go through the current codebase and remove all usage of j2se 1.4 apis. Examples: 1) URLDecode.decode(String) - no workaround 2) Boolean.valueOf(boolean) I'm introducing a new method Boolean org.jboss.util.Primitives.valueOf(boolean) to replace this. 3) throw new RuntimeExecption(Throwable) use throw new org.jboss.util.NestedRuntimeException(Throwable) There is also a problem with some SSL classes from j2se 1.4 that needs to be conditionally compiled if we are going to support compilation on j2se 1.3 -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss documentation
You should really direct this question to the jboss-user list (in copy). The dev list is for jboss developers. You are OK as long as you acknowledge the trademark: JBoss is a registered trademark and servicemark of JBoss Inc. and don't plagarise copyrighted materials unless you have a license. You should consider contributing your doco to the WIKI: http://www.jboss.org/wiki/Wiki.jsp On Sun, 2004-05-09 at 19:37, Marco Tedone wrote: Hi, I would like to put some documentation about JBoss on my website. Is this possible, or shall I pay some rights? Regards, Marco --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Axis Dependency
Thomas, Is it really acceptable for the core server module to depend upon Axis? e.g. org.jboss.webservice.ClientLoginHandler Regards, Adrian -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why the two jboss logging frameworks?
I've fixed most of the testsuite, there are still two modelmbean failures I don't understand. The descriptor validation part of the spec is voodoo to me. build test-compliance-JBossMX Also, I fixed some of the tests to catch the RuntimeOperationsException thrown by Descriptor.isValid() But the JMX RI implementation we currently have in our CVS doesn't throw this exception for 6 of the tests. build test-compliance-RI There are also two issues with MLET/classloading in the implementation tests build test-implementation Regards, Adrian On Sat, 2004-04-17 at 14:27, Adrian Brock wrote: Thomas or Tom, A lot of the JMX testsuite tests for JBossMX are failing. Either the tests should be fixed or the reason why they fail analysed. Last time I ran it, there were three known issues non of them important. Regards, Adrian On Sat, 2004-04-17 at 14:00, Adrian Brock wrote: I'll fix it in both 3.2 and head My fault for not keeping head in line. Regards, Adrian On Sat, 2004-04-17 at 13:42, Adrian Brock wrote: The JMX logging framework was removed from 3.2.0 but never from head. When Tom backported jmx from head into 3.2.4RC1 he also copied the old jmx logging framework. Regards, Adrian On Sat, 2004-04-17 at 13:25, Scott M Stark wrote: In trying to cleanup the logging for bug [ 936465 ] JCA layer has invalid assumption about Log4jLoggerPlugin https://sourceforge.net/tracker/index.php?func=detailaid=936465group_i d=22866atid=376685 I see that we have two seperate frameworks: jmx org.jboss.mx.logging comon org.jboss.logging Is this a legacy issue from before jmx depending on the common module? There can only be one jboss logging abstraction. Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why the two jboss logging frameworks?
The JMX logging framework was removed from 3.2.0 but never from head. When Tom backported jmx from head into 3.2.4RC1 he also copied the old jmx logging framework. Regards, Adrian On Sat, 2004-04-17 at 13:25, Scott M Stark wrote: In trying to cleanup the logging for bug [ 936465 ] JCA layer has invalid assumption about Log4jLoggerPlugin https://sourceforge.net/tracker/index.php?func=detailaid=936465group_i d=22866atid=376685 I see that we have two seperate frameworks: jmx org.jboss.mx.logging comon org.jboss.logging Is this a legacy issue from before jmx depending on the common module? There can only be one jboss logging abstraction. Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why the two jboss logging frameworks?
I'll fix it in both 3.2 and head My fault for not keeping head in line. Regards, Adrian On Sat, 2004-04-17 at 13:42, Adrian Brock wrote: The JMX logging framework was removed from 3.2.0 but never from head. When Tom backported jmx from head into 3.2.4RC1 he also copied the old jmx logging framework. Regards, Adrian On Sat, 2004-04-17 at 13:25, Scott M Stark wrote: In trying to cleanup the logging for bug [ 936465 ] JCA layer has invalid assumption about Log4jLoggerPlugin https://sourceforge.net/tracker/index.php?func=detailaid=936465group_i d=22866atid=376685 I see that we have two seperate frameworks: jmx org.jboss.mx.logging comon org.jboss.logging Is this a legacy issue from before jmx depending on the common module? There can only be one jboss logging abstraction. Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why the two jboss logging frameworks?
Thomas or Tom,
A lot of the JMX testsuite tests for JBossMX are failing.
Either the tests should be fixed or the reason why they
fail analysed.
Last time I ran it, there were three known issues
non of them important.
Regards,
Adrian
On Sat, 2004-04-17 at 14:00, Adrian Brock wrote:
I'll fix it in both 3.2 and head
My fault for not keeping head in line.
Regards,
Adrian
On Sat, 2004-04-17 at 13:42, Adrian Brock wrote:
The JMX logging framework was removed from 3.2.0 but never
from head. When Tom backported jmx from head into 3.2.4RC1
he also copied the old jmx logging framework.
Regards,
Adrian
On Sat, 2004-04-17 at 13:25, Scott M Stark wrote:
In trying to cleanup the logging for bug [ 936465 ] JCA layer has
invalid assumption about Log4jLoggerPlugin
https://sourceforge.net/tracker/index.php?func=detailaid=936465group_i
d=22866atid=376685
I see that we have two seperate frameworks:
jmx org.jboss.mx.logging
comon org.jboss.logging
Is this a legacy issue from before jmx depending on the common module?
There can only
be one jboss logging abstraction.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70alloc_id638op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Adrian Brock
Director of Support
Back Office
JBoss Inc.
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Attachments on sourceforge
I can't view any attachments on the jboss sourceforge patches page. Is anybody else seeing this problem? Regards, Adrian -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Seeing sporadic failures in the head jboss-local-jdbc.rar deployment
Ok, I'll look at it. Regards, Adrian On Tue, 2004-03-30 at 21:03, Scott M Stark wrote: Using a snapshot from Mar 29 15:06 - 8:00 from jboss-head I'm seeing frequent startup failures due to what appears to be a failure to obtain an remote schema. There is a 15-20 sec delay when this failure occurs. 11:49:59,568 INFO [MainDeployer] Starting deployment of package: file:/C:/cvs/J BossHead/jboss-head/build/output/jboss-4.0.0DR4/server/cts/deploy/jboss-local-jdbc.rar 11:50:22,724 WARN [Unmarshaller] src-import.0: Failed to read imported schema d ocument 'http://www.w3.org/2001/xml.xsd'. @ http://java.sun.com/xml/ns/j2ee/j2ee_1_4.xsd[74,57] 11:50:25,037 ERROR [MainDeployer] Could not initialise deployment: file:/C:/cvs/ JBossHead/jboss-head/build/output/jboss-4.0.0DR4/server/cts/deploy/jboss-local-jdbc.rar org.jboss.deployment.DeploymentException: Error parsing meta data jar:file:/C:/c vs/JBossHead/jboss-head/build/output/jboss-4.0.0DR4/server/cts/tmp/deploy/tmp437 72jboss-local-jdbc.rar!/META-INF/ra.xml; - nested throwable: (org.xml.sax.SAXExc eption: src-resolve: Cannot resolve the name 'xml:lang' to a(n) attribute declar ation component. @ http://java.sun.com/xml/ns/j2ee/j2ee_1_4.xsd[133,33]) at org.jboss.deployment.DeploymentException.rethrowAsDeploymentException(DeploymentException. java:39) at org.jboss.deployment.SimpleSubDeployerSupport.parseMetaData(SimpleSubDeployerSupport.java: 213) at org.jboss.deployment.SimpleSubDeployerSupport.init(SimpleSubDeployerSupport.java:95) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:728) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:663) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:74) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:45) at org.jboss.mx.server.Invocation.invoke(Invocation.java:70) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:168) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:469) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:174) at $Proxy7.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:303) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:477) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploy mentScanner.java:201) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScan ner.java:274) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:266) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:216) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) Scott Stark Chief Technology Officer JBoss Group, LLC -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Seeing sporadic failures in the head jboss-local-jdbc.rar deployment
Try again from cvs. At least the j2ee1.4 and connector schemas were old. I also put a hack in the entity resolver to cater for schema includes. Does anybody know how you are supposed to do this properly? It seems to want to find the xsds in the same place it got the original xml document rather than relative to the xsd that does the include? Regards, Adrian On Tue, 2004-03-30 at 21:03, Scott M Stark wrote: Using a snapshot from Mar 29 15:06 - 8:00 from jboss-head I'm seeing frequent startup failures due to what appears to be a failure to obtain an remote schema. There is a 15-20 sec delay when this failure occurs. 11:49:59,568 INFO [MainDeployer] Starting deployment of package: file:/C:/cvs/J BossHead/jboss-head/build/output/jboss-4.0.0DR4/server/cts/deploy/jboss-local-jdbc.rar 11:50:22,724 WARN [Unmarshaller] src-import.0: Failed to read imported schema d ocument 'http://www.w3.org/2001/xml.xsd'. @ http://java.sun.com/xml/ns/j2ee/j2ee_1_4.xsd[74,57] 11:50:25,037 ERROR [MainDeployer] Could not initialise deployment: file:/C:/cvs/ JBossHead/jboss-head/build/output/jboss-4.0.0DR4/server/cts/deploy/jboss-local-jdbc.rar org.jboss.deployment.DeploymentException: Error parsing meta data jar:file:/C:/c vs/JBossHead/jboss-head/build/output/jboss-4.0.0DR4/server/cts/tmp/deploy/tmp437 72jboss-local-jdbc.rar!/META-INF/ra.xml; - nested throwable: (org.xml.sax.SAXExc eption: src-resolve: Cannot resolve the name 'xml:lang' to a(n) attribute declar ation component. @ http://java.sun.com/xml/ns/j2ee/j2ee_1_4.xsd[133,33]) at org.jboss.deployment.DeploymentException.rethrowAsDeploymentException(DeploymentException. java:39) at org.jboss.deployment.SimpleSubDeployerSupport.parseMetaData(SimpleSubDeployerSupport.java: 213) at org.jboss.deployment.SimpleSubDeployerSupport.init(SimpleSubDeployerSupport.java:95) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:728) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:663) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:74) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:45) at org.jboss.mx.server.Invocation.invoke(Invocation.java:70) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:168) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:469) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:174) at $Proxy7.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:303) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:477) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploy mentScanner.java:201) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScan ner.java:274) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:266) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:216) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) Scott Stark Chief Technology Officer JBoss Group, LLC -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Deployment directory for singleton services
On Fri, 2004-03-19 at 13:35, Ivelin Ivanov wrote: Sounds like you are both suggesting to move the deploy-hasingleton to farm/singleton. Is this correct? That won't work. The farm service will deploy it on every node. Dimitris just wants distributions of the deployments across the deploy-hasingleton directories in the cluster. Regards, Adrian Ivelin --- Adrian Brock [EMAIL PROTECTED] wrote: On Thu, 2004-03-18 at 15:22, Dimitris Andreadis wrote: I'm not sure if orthogonal is the right word for this case. If I rephrase: farm - for applications deployed across a cluster deploy-hasingleton - for applications deployed across a cluster but active only on one node at a time. It seems to me more like an an attribute of a clustered application. Yes, it would make sense to farm deploy-hasingleton in most circumstances. Of course it would be a waste of effort if you are using netboot. The only argument against is that you might want different configuration on different servers? e.g. JBossMQ MessageCache memory settings. Regards, Adrian Regards /Dimitris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Adrian Brock Sent: , 18 2004 4:17 To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Deployment directory for singleton services On Wed, 2004-03-17 at 10:37, Dimitris Andreadis wrote: How about having a sub-directory farm/singleton instead? They serve different orthogonal purposes. farm - is for applications deployed across a cluster deploy-hasingleton - is for applications that should only be run on one server at a time. I can see a case for the deploy-hasingleton directory getting replicated across the cluster. But the deployment will still only be active on one server in the cluster. Regards, Adrian I guess is a little bit more difficult to implement, having the farm watcher ignore this particular dir, but it looks more intuitive to me. /Dimitris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ivelin Ivanov Sent: , 15 2004 2:47 To: [EMAIL PROTECTED] Subject: [JBoss-dev] Deployment directory for singleton services In 3.2.4 under config server/all there is going to be another deployment directory, parallel to deploy and farm, which will host services that are deployed on exactly one node in the cluster. The tentative name is deploy-hasingleton. A service under deploy declared in deploy-hasingleton-service.xml will deploy the directory in question. JMS is the first service that will take advantage of this new directory. My question is how should we name the directory and what other services are good candidates for it? Cheers, Ivelin --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ JBoss
RE: [JBoss-dev] Deployment directory for singleton services
On Wed, 2004-03-17 at 10:37, Dimitris Andreadis wrote: How about having a sub-directory farm/singleton instead? They serve different orthogonal purposes. farm - is for applications deployed across a cluster deploy-hasingleton - is for applications that should only be run on one server at a time. I can see a case for the deploy-hasingleton directory getting replicated across the cluster. But the deployment will still only be active on one server in the cluster. Regards, Adrian I guess is a little bit more difficult to implement, having the farm watcher ignore this particular dir, but it looks more intuitive to me. /Dimitris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ivelin Ivanov Sent: , 15 2004 2:47 To: [EMAIL PROTECTED] Subject: [JBoss-dev] Deployment directory for singleton services In 3.2.4 under config server/all there is going to be another deployment directory, parallel to deploy and farm, which will host services that are deployed on exactly one node in the cluster. The tentative name is deploy-hasingleton. A service under deploy declared in deploy-hasingleton-service.xml will deploy the directory in question. JMS is the first service that will take advantage of this new directory. My question is how should we name the directory and what other services are good candidates for it? Cheers, Ivelin --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Deployment directory for singleton services
On Thu, 2004-03-18 at 14:59, Juha-P Lindfors wrote: couldn't the deployer just pick up a tag from the descriptor -- rather than add yet another deployment directory? Yes, that should be the long term solution. e.g. singleton partition=DefaultDomain/ or farm partition=MyWebServers/ But it *is* easier to just a drop a deployment in a different directory than cracking open an archive and adding some xml. Regards, Adrian On Thu, 18 Mar 2004, Adrian Brock wrote: On Wed, 2004-03-17 at 10:37, Dimitris Andreadis wrote: How about having a sub-directory farm/singleton instead? They serve different orthogonal purposes. farm - is for applications deployed across a cluster deploy-hasingleton - is for applications that should only be run on one server at a time. I can see a case for the deploy-hasingleton directory getting replicated across the cluster. But the deployment will still only be active on one server in the cluster. Regards, Adrian I guess is a little bit more difficult to implement, having the farm watcher ignore this particular dir, but it looks more intuitive to me. /Dimitris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ivelin Ivanov Sent: , 15 2004 2:47 To: [EMAIL PROTECTED] Subject: [JBoss-dev] Deployment directory for singleton services In 3.2.4 under config server/all there is going to be another deployment directory, parallel to deploy and farm, which will host services that are deployed on exactly one node in the cluster. The tentative name is deploy-hasingleton. A service under deploy declared in deploy-hasingleton-service.xml will deploy the directory in question. JMS is the first service that will take advantage of this new directory. My question is how should we name the directory and what other services are good candidates for it? Cheers, Ivelin --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638opk ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Juha Lindfors Director of Training http://www.jboss.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Deployment directory for singleton services
On Thu, 2004-03-18 at 14:59, Juha-P Lindfors wrote: couldn't the deployer just pick up a tag from the descriptor -- rather than add yet another deployment directory? Yes, that should be the long term solution. e.g. singleton partition=DefaultDomain/ or farm partition=MyWebServers/ But it *is* easier to just a drop a deployment in a different directory than cracking open an archive and adding some xml. Regards, Adrian On Thu, 18 Mar 2004, Adrian Brock wrote: On Wed, 2004-03-17 at 10:37, Dimitris Andreadis wrote: How about having a sub-directory farm/singleton instead? They serve different orthogonal purposes. farm - is for applications deployed across a cluster deploy-hasingleton - is for applications that should only be run on one server at a time. I can see a case for the deploy-hasingleton directory getting replicated across the cluster. But the deployment will still only be active on one server in the cluster. Regards, Adrian I guess is a little bit more difficult to implement, having the farm watcher ignore this particular dir, but it looks more intuitive to me. /Dimitris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ivelin Ivanov Sent: , 15 2004 2:47 To: [EMAIL PROTECTED] Subject: [JBoss-dev] Deployment directory for singleton services In 3.2.4 under config server/all there is going to be another deployment directory, parallel to deploy and farm, which will host services that are deployed on exactly one node in the cluster. The tentative name is deploy-hasingleton. A service under deploy declared in deploy-hasingleton-service.xml will deploy the directory in question. JMS is the first service that will take advantage of this new directory. My question is how should we name the directory and what other services are good candidates for it? Cheers, Ivelin --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638opk ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Juha Lindfors Director of Training http://www.jboss.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Deployment directory for singleton services
On Thu, 2004-03-18 at 15:22, Dimitris Andreadis wrote: I'm not sure if orthogonal is the right word for this case. If I rephrase: farm - for applications deployed across a cluster deploy-hasingleton - for applications deployed across a cluster but active only on one node at a time. It seems to me more like an an attribute of a clustered application. Yes, it would make sense to farm deploy-hasingleton in most circumstances. Of course it would be a waste of effort if you are using netboot. The only argument against is that you might want different configuration on different servers? e.g. JBossMQ MessageCache memory settings. Regards, Adrian Regards /Dimitris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Adrian Brock Sent: , 18 2004 4:17 To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Deployment directory for singleton services On Wed, 2004-03-17 at 10:37, Dimitris Andreadis wrote: How about having a sub-directory farm/singleton instead? They serve different orthogonal purposes. farm - is for applications deployed across a cluster deploy-hasingleton - is for applications that should only be run on one server at a time. I can see a case for the deploy-hasingleton directory getting replicated across the cluster. But the deployment will still only be active on one server in the cluster. Regards, Adrian I guess is a little bit more difficult to implement, having the farm watcher ignore this particular dir, but it looks more intuitive to me. /Dimitris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ivelin Ivanov Sent: , 15 2004 2:47 To: [EMAIL PROTECTED] Subject: [JBoss-dev] Deployment directory for singleton services In 3.2.4 under config server/all there is going to be another deployment directory, parallel to deploy and farm, which will host services that are deployed on exactly one node in the cluster. The tentative name is deploy-hasingleton. A service under deploy declared in deploy-hasingleton-service.xml will deploy the directory in question. JMS is the first service that will take advantage of this new directory. My question is how should we name the directory and what other services are good candidates for it? Cheers, Ivelin --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Your TreeCache changes
On Fri, 2004-03-19 at 01:43, Bela Ban wrote: Hey Adrian, what are you doing ? You're breaking our code by changing start() to startService() ! No I am not. All the cache tests still work for me. start() invokes startService(). start() was never intended to be overriden, in fact doing so in the way you had it breaks the state machine of ServiceMBeanSupport What I have actually done is change start() to go via the service controller so when you click start()/stop() on the jmx console it also starts/stops dependent services. start() - serviceController - startService() \-- startService() on dependents before my modification it was start() - startService() which meant dependents didn't start Regards, Adrian -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Deployment directory for singleton services
No. It is the deployment/undeployment of the directory that is the singleton. Regards, Adrian On Tue, 2004-03-16 at 21:03, Scott M Stark wrote: Don't such singletons services till have unique 'start as singleton' ops that need to be specified to the hasingleton-service? Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ivelin Ivanov Sent: Sunday, March 14, 2004 4:47 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Deployment directory for singleton services In 3.2.4 under config server/all there is going to be another deployment directory, parallel to deploy and farm, which will host services that are deployed on exactly one node in the cluster. The tentative name is deploy-hasingleton. A service under deploy declared in deploy-hasingleton-service.xml will deploy the directory in question. JMS is the first service that will take advantage of this new directory. My question is how should we name the directory and what other services are good candidates for it? Cheers, Ivelin -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Service Lifecyle confusions - potential fix
I added your comment to the forums.
http://www.jboss.org/index.html?module=bbop=viewtopicp=3824602#3824602
It seems jboss-dev does not accept posts with jboss-dev in copy?
Regards,
Adrian
On Sun, 2004-03-07 at 15:53, Bill Burke wrote:
I was also hoping that you could supply a mixin class that handled
service lifecycle so that POJO's could be involved with lifecycle and
not have to implement any interface.
H, I guess you could do this with AOP introduction.
Bill
Scott M Stark wrote:
The state machine was not immeadiately for the service layer, but
will be used to enforce illegal transitions if we decide on a state
diagram.
The suggested change makes sense, but the other problem is the fact
that the deployment layer is out of the loop in this. I would like
to couple dependency and life cycle to delay the creation of the
service as an mbean, but have not really looked at how big a change
this is.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
-Original Message-
From: Adrian Brock
Sent: Saturday, March 06, 2004 5:24 PM
To: Scott M Stark
Cc: [EMAIL PROTECTED]; The Core
Subject: Service Lifecyle confusions - potential fix
Hi Scott,
Are you working on the Service lifecycle?
I saw you replaced common's state machine implementation.
I was thinking that there should be an extra indirection to
avoid the confusion caused by people clicking stop() and
other operations in the console where dependencies are not
taken into account.
My idea is that you implement an extra operation in
ServiceMBeanSupport
public void jbossServiceLifecylce(String operation) throws
Exception { if (operation.equals(create)) { // the current
create() method } etc.
}
This would be invoked from ServiceController.ServiceProxy
when it is implemented by the MBean.
This would allow us to change the current
ServiceMBeanSupport.create() to be:
serviceController.create(serviceName);
etc.
Now clicking stop() in the console goes via the service
controller making sure dependencies are also stopped.
This doesn't fix the problem for MBeans that do not extend
ServiceMBeanSupport. These would still do the old behaviour.
Similar changes would be required to
ServiceDynamicMBeanSupport and the XMBean descriptor include.
Regards,
Adrian
--
Adrian Brock
Director of Support
Back Office
JBoss Inc.
--
Adrian Brock
Director of Support
Back Office
JBoss Inc.
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Service Lifecyle confusions - potential fix
Hi Scott,
Are you working on the Service lifecycle?
I saw you replaced common's state machine implementation.
I was thinking that there should be an extra indirection
to avoid the confusion caused by people clicking stop() and other
operations in the console where dependencies are not taken into account.
My idea is that you implement an extra operation in ServiceMBeanSupport
public void jbossServiceLifecylce(String operation) throws Exception
{
if (operation.equals(create))
{
// the current create() method
}
etc.
}
This would be invoked from ServiceController.ServiceProxy when
it is implemented by the MBean.
This would allow us to change the current
ServiceMBeanSupport.create() to be:
serviceController.create(serviceName);
etc.
Now clicking stop() in the console goes via the service controller
making sure dependencies are also stopped.
This doesn't fix the problem for MBeans that do not extend
ServiceMBeanSupport. These would still do the old behaviour.
Similar changes would be required to ServiceDynamicMBeanSupport
and the XMBean descriptor include.
Regards,
Adrian
--
Adrian Brock
Director of Support
Back Office
JBoss Inc.
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Fwd: Service Lifecyle confusions - potential fix]
Test
-Forwarded Message-
From: Adrian Brock [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Service Lifecyle confusions - potential fix
Date: 07 Mar 2004 01:23:35 +
Hi Scott,
Are you working on the Service lifecycle?
I saw you replaced common's state machine implementation.
I was thinking that there should be an extra indirection
to avoid the confusion caused by people clicking stop() and other
operations in the console where dependencies are not taken into account.
My idea is that you implement an extra operation in ServiceMBeanSupport
public void jbossServiceLifecylce(String operation) throws Exception
{
if (operation.equals(create))
{
// the current create() method
}
etc.
}
This would be invoked from ServiceController.ServiceProxy when
it is implemented by the MBean.
This would allow us to change the current
ServiceMBeanSupport.create() to be:
serviceController.create(serviceName);
etc.
Now clicking stop() in the console goes via the service controller
making sure dependencies are also stopped.
This doesn't fix the problem for MBeans that do not extend
ServiceMBeanSupport. These would still do the old behaviour.
Similar changes would be required to ServiceDynamicMBeanSupport
and the XMBean descriptor include.
Regards,
Adrian
--
Adrian Brock
Director of Support
Back Office
JBoss Inc.
--
Adrian Brock
Director of Support
Back Office
JBoss Inc.
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Service Lifecyle confusions - potential fix
On Sun, 2004-03-07 at 02:08, Scott M Stark wrote:
The state machine was not immeadiately for the service layer, but
will be used to enforce illegal transitions if we decide on a state
diagram.
The suggested change makes sense, but the other problem is the fact
that the deployment layer is out of the loop in this.
I wasn't considering deployment, only lifecyle.
I would like
to couple dependency and life cycle to delay the creation of the
service as an mbean, but have not really looked at how big a change
this is.
My preferred solution for this to read-ahead all deployments
to determine the full graph (including class and jndi dependencies)
before any deployment starts. You can then inject configuration IOC
style. It would also give enough information to allow a realistic
valve implementation.
I haven't figured out how you identify the deployers or the scanner
as special - i.e. allowing their initial processing before the full
graph has been read - so they can contribute to the graph.
I'd also like to introduce cleverer (more fine grained) dependency
information like the ejb deployer should not depend upon jms.
Instead it should be based on whether jms is used, either by an
mdb or a resource-ref.
This would potentially allow the jmx-console to deploy eariler rather
than waiting for unnecessary dependencies specified on the web deployer.
Regards,
Adrian
Scott Stark
Chief Technology Officer
JBoss Group, LLC
-Original Message-
From: Adrian Brock
Sent: Saturday, March 06, 2004 5:24 PM
To: Scott M Stark
Cc: [EMAIL PROTECTED]; The Core
Subject: Service Lifecyle confusions - potential fix
Hi Scott,
Are you working on the Service lifecycle?
I saw you replaced common's state machine implementation.
I was thinking that there should be an extra indirection to
avoid the confusion caused by people clicking stop() and
other operations in the console where dependencies are not
taken into account.
My idea is that you implement an extra operation in
ServiceMBeanSupport
public void jbossServiceLifecylce(String operation) throws
Exception { if (operation.equals(create)) { // the current
create() method } etc.
}
This would be invoked from ServiceController.ServiceProxy
when it is implemented by the MBean.
This would allow us to change the current
ServiceMBeanSupport.create() to be:
serviceController.create(serviceName);
etc.
Now clicking stop() in the console goes via the service
controller making sure dependencies are also stopped.
This doesn't fix the problem for MBeans that do not extend
ServiceMBeanSupport. These would still do the old behaviour.
Similar changes would be required to
ServiceDynamicMBeanSupport and the XMBean descriptor include.
Regards,
Adrian
--
Adrian Brock
Director of Support
Back Office
JBoss Inc.
--
Adrian Brock
Director of Support
Back Office
JBoss Inc.
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: change default commit option
On Fri, 2004-03-05 at 17:50, Bill Burke wrote: Actually this requires no changes to testsuite, correct? Yes it does. Take a look at src/resources/lock/META-INF/jboss.xml for example. Regards, Adrian Alexey Loubyansky wrote: I agree with Adrian. When you develop an application, sometimes, you want to modify the db by hand and see the effect immediately in the app. So, not CO A. +1 for IPT. -Original Message- From: Adrian Brock Sent: Friday, March 05, 2004 5:46 PM To: Bill Burke Cc: Jboss-Dev; The Core Subject: Re: change default commit option I'd prefer instance per transaction. But somebody would need to go through the testsuite and update the lock tests back to pessimistic locking if they don't have their own configurations already. Regards, Adrian On Fri, 2004-03-05 at 15:42, Bill Burke wrote: If I remember correctly the default commit option is 'B' with regular pessimistic locking. So basically, out-of-the-box, you get the performance drawbacks of commit 'B' and the hairiness of pessimistic locking. Can we switch the default to 'A' + locking? Or 'C' + instance per transaction? Thanks, Bill -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Inc. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Missing web.xmls
Hi Scott, You forgot to commit the web.xml files for these changes: http://cvs.sourceforge.net/viewcvs.py/jboss/jbosstest/build.xml?r1=1.165.2.137r2=1.165.2.138 Regards, Adrian -- Adrian Brock Director of Support Back Office JBoss Inc. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: DR3 release and freeze
On Wed, 2004-02-25 at 04:13, Bill Burke wrote: Hi all, I'd like to do a DR3 of 4.0 Mid March. To do that we need to be ready to stabilize 4.0. I'd like to freeze feature development starting March 10th. For a week, fix testsuite, run SpecJ, stabilize, fix bugs. Release will be 17th on St. Patty's day so we can all drink to our hard work in DR3. Featured in the release: EJB 2.1 stuff: - web services compliance - EJB Timer Service - EJB QL updates JMX 1.2 compliance JBoss AOP Anything else that should be featured? Anybody have any concerns with the release? Last Resource gambit in JBossTM JMS1.1 compliance (Currently WIP) My main concern is the large memory footprint that has crept into JBoss4. Regards, Adrian Thanks, Bill -- Adrian Brock Director of Support Back Office JBoss Inc. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Bad cross module dependency
can't be used in CMP. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Bad cross module dependency
According to cvs it was a temporary solution that has never been fixed.
http://cvs.sourceforge.net/viewcvs.py/jboss/jbosscx/src/main/org/jboss/resource/adapter/jdbc/Attic/WrappedStatement.jpp?hideattic=0
I guess the problem is that connector depends upon server for things
like the security interfaces. But server also includes cmp.
There's a similar problem between transaction and server.
Regards,
Adrian
On Wed, 2004-02-04 at 02:26, Scott M Stark wrote:
Why does the jca WrappedStatement implement an interface from the cmp
module?
package org.jboss.resource.adapter.jdbc;
public class WrappedStatement
implements Statement, org.jboss.ejb.plugins.cmp.jdbc.WrappedStatement
{
...
}
This cmp version of the WrappedStatement is just providing access to
the underlying statement object. Why isn't that just part of the jca
version of the WrappedStatement, or some interface in the jca pkg?
There cannot be dependencies on from the jca layer to a user of jca.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Adrian Brock
Director of Support
Back Office
JBoss Group, LLC
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] URL based transaction demarcation and long running transations
You need to be careful with the http session. It can be used on multiple threads unlike an ejb stateful session bean. Regards, Adrian On Mon, 2004-01-19 at 16:50, Bill Burke wrote: I'd like for somebody to look into being able to define transaction demarcation like we can for EJB at the servlet/jsp/war level. So, based on a URL pattern you can specify trans-attributes. Along with this would be stuffing the transaction into the HTTP session so that you can have long transactions that span separate HTTP requests. I don't think that something like this would be very hard to do. It is just a matter of providing a Filter and some metadata with jboss-web.xml. You can probably steal a lot of code from the transaction interceptors within our ejb stack and invokers. Let me know if anybody is interested and I can give you some more ideas. Bill P.S. Ivelin. I'd like to add this to the roadmap. -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Expansion of service dependencies to redeployment
/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jmx unit tests
/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fwd: ASF JIRA Installation is available
capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Bill Burke Chief Architect JBoss Group LLC. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: FW: fix to org.jboss.management.mejb.ManagementBean
Charlton, It looks like your patch (for head?) is exactly the same as the class in 3.2 with the javadocs removed and the whitespace corrupted. Is that correct? If not, post a patch/bug at www.sf.net/projects/jboss Regards, Adrian On Wed, 2004-01-14 at 16:42, Marc Fleury wrote: __ From: Charlton Barreto [mailto:[EMAIL PROTECTED] Sent: Tue 1/13/2004 8:54 PM To: Marc Fleury; Andreas Schaefer Subject: fix to org.jboss.management.mejb.ManagementBean Hello, Sorry to bother you, but I had a fix for org.jboss.management.mejb.ManagementBean (attached) reflecting the (recent) changes to JMX. Since I don't have rw access to the JBoss repository, I'm asking if you either of you could check it in. I've tested this in the build and it appears to be OK. If there is another process I should or could use for such check-ins please let me know. -Charlton Barreto. -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: FW: fix to org.jboss.management.mejb.ManagementBean
Hi Charlton, Please keep it on the public lists so that others who are interested can take part. It looks like an overrsight. In anycase the implementation should probably be using MBeanServerConnection rather than MBeanServer. Regards, Adrian On Wed, 2004-01-14 at 19:41, Charlton Barreto wrote: Hi Adrian, Sorry, my bad, I should have sent my updated file. I will be posting soon to www.sf.net/projects/jboss (to HEAD). I was curious if there was any reason the JMX 1.2 impls were not included in ManagementBean/HEAD? Please let me know Thanks, -Charlton. On Jan 14, 2004, at 09:14, Adrian Brock wrote: Charlton, It looks like your patch (for head?) is exactly the same as the class in 3.2 with the javadocs removed and the whitespace corrupted. Is that correct? If not, post a patch/bug at www.sf.net/projects/jboss Regards, Adrian On Wed, 2004-01-14 at 16:42, Marc Fleury wrote: __ From: Charlton Barreto [mailto:[EMAIL PROTECTED] Sent: Tue 1/13/2004 8:54 PM To: Marc Fleury; Andreas Schaefer Subject: fix to org.jboss.management.mejb.ManagementBean Hello, Sorry to bother you, but I had a fix for org.jboss.management.mejb.ManagementBean (attached) reflecting the (recent) changes to JMX. Since I don't have rw access to the JBoss repository, I'm asking if you either of you could check it in. I've tested this in the build and it appears to be OK. If there is another process I should or could use for such check-ins please let me know. -Charlton Barreto. -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Moving out the core hard-coded service configuration
On Wed, 2004-01-07 at 18:04, Scott M Stark wrote: A long standing issue I have with the jmx microkernel of services that are hard-coded (ServerImpl, MainDeployer, SARDeployer, ServiceController, ...) is that there is no way to configure these services let alone replace them. So, I want to externalize these as XMBeans. Comments? Couldn't we just use an xml (xmbean) description of these services in jboss-system.jar Then use Classloader.getResource() to load it. If somebody wants to override the xml they can use the patch parameter (or add it JBOSS_CLASSPATH) to insert an alternate xml file before jboss-system.jar in the kernel's classloader. The same could be done for the hard-wired modelmbean descriptions in MBeanServerImpl. Depending upon how far you want to go, we could also provide a file that contains a list of mbeans descriptors to instantiate that forms the kernel. In principal this could all be handled by the mbean server. i.e. When creating the MBeanServer it looks in a certain location for the initial mbeans to load. Bootstrapping the server would just be to setup the classloader then create an MBeanServer. I imagine there are a number of chicken/egg problems to solve. Regards, Adrian Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-871649 ] Problem with source of JMX Notifications
Hi Jeff, You cannot implement it like this: // make a copy of the notification, replacing with the real source of the event Notification n = new Notification(notification.getType(),source,notification.getSequenceNumber(),notification.getTimeStamp(),notification.getMessage()); n.setUserData(notification.getUserData()); return this.delegate.isNotificationEnabled(n); The filter will likely rely upon the type of the Notification which is lost in this implementation. The big problem is that notifications are not required to be clonable, so the only thing you can do is setSource() on the notification with the ObjectName (changing the source for subsequent notification listeners). This is a known issue with the spec. See NotificationListenerProxy. Regards, Adrian On Tue, 2004-01-06 at 14:18, SourceForge.net wrote: Bugs item #871649, was opened at 2004-01-06 08:16 Message generated for change (Comment added) made by jhaynie You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=871649group_id=22866 Category: JBossMX Group: v3.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jeff Haynie (jhaynie) Assigned to: Jeff Haynie (jhaynie) Summary: Problem with source of JMX Notifications Initial Comment: According to the JMX spec, the source of a Notification must be of type ObjectName. At line 420 in ServerImpl: Notification msg = new Notification (START_NOTIFICATION_TYPE, this, 1); should be changed to: Notification msg = new Notification (START_NOTIFICATION_TYPE, ServerImplMBean.OBJECT_NAME, 1); We should also update JMX to check this (although I thought it did before - maybe its happening at the at a higher level in the BasicMBeanRegistry). The problem is that the ListenerRegistration in the NotificationBroadcasterSupport.sendNotification() will evaluate the NotificationFilter before being dispatched up to the listener. The listener is being wrapped at a higher level by the mbean server using the NotificationListenerProxy which sets the source - but this happens after the filter is applied -- which causes problems if you're checking the ObjectName in the filter. An easy enough fix for this particular problem is just to do above. However, I'm worried we'll still see this in other places. Another thought is to wrap the MBeanServerListenerRegistration (which creates NotificationListenerProxy) and pass in a proxy to the filter, such that it will set the appropriate source using the MBeanServerListenerRegistration and then delegate to the appropriate filter. The other thing is to enforce in our Notification implementation ObjectName in setSource and the constructor -- which according to the JMX spec we're suppose to throw an IllegalArgumentException. -- Comment By: Jeff Haynie (jhaynie) Date: 2004-01-06 09:18 Message: Logged In: YES user_id=4529 This is implemented in 3.2 branch. -- Comment By: Adrian Brock (ejort) Date: 2004-01-06 08:50 Message: Logged In: YES user_id=9459 Yes, go ahead. Regards, Adrian -- Comment By: Jeff Haynie (jhaynie) Date: 2004-01-06 08:44 Message: Logged In: YES user_id=4529 OK, looking at the JMX 1.2 spec javadoc for Notification, it states: The Notification class represents a notification emitted by an MBean. It contains a reference to the source MBean: if the notification has been forwarded through the MBean server, this is the object name of the MBean. If the listener has registered directly with the MBean, this is either the object name or a direct reference to the MBean. It is strongly recommended that notification senders use the object name rather than a reference to the MBean object as the source. In my case, and in the case for jboss mx, we're not registering directly with the mbean. I like the idea of filter proxy since it would enforce the ObjectName externally and still allow either ObjectName or direct reference in the implementation of an MBean. Is this something you would like me to apply? -- Comment By: Adrian Brock (ejort) Date: 2004-01-06 08:34 Message: Logged In: YES user_id=9459 The only requirement from the spec is that notification listeners registered through the MBeanServer receive notifications with the ObjectName they registered against. Direct notifications (i.e. where you register directly with the MBean) are not required to use the ObjectName, but direct notifications are frowned upon. You cannot setSource() a normal object but there is no such requirement on the constructor. Unless the broadcaster also implements
Re: [JBoss-dev] default entity bean locking
On Tue, 2004-01-06 at 22:19, Bill Burke wrote: Currently the default entity bean locking strategy is Commit 'B' plus pessimistic. If we're going to default to 'B', can we default to multi instance? +1 from me It doesn't make sense to serialize access to a shared instance whose data won't be reused anyway. Its only utility is read-only in CMP. i.e. ignore the server's request to reload data for an already associated bean. Regards, Adrian Bill -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Change XMBean constants case?
On Mon, 2004-01-05 at 11:45, Juha Lindfors wrote: You should check the 1.2 spec and see if they've made a decision on the case of the attribute names. -- Juha Page 96 in Predefined Descriptor Fields Field names are not case sensitive. The field descriptorType can also be referred to as DescriptorType or DESCRIPTORTYPE. The case used when a descriptor is created or updated is preserved. It is recommended that the form shown here be used consistently. So the case is unimportant. The only requirement is to preserve the case externally. Regards, Adrian On Mon, 5 Jan 2004, Scott M Stark wrote: The required ModelMBean destriptor fields like persistPolicy, persistPeriod, currencyTimeLimit are defined in ModelMBeanConstants as lower case values. These constants are used when parsing the XMBean xml descriptor attributes which need to be the case sensitive strings. Since these are converted to lowercase for the field lookups, why aren't the constants still being defined with the proper case? I'm changing this in the 3.2 version, shouldn't this be done on head as well? Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] InstanceCache - NoSuchObjectException
The interface org.jboss.ejb.plugins.InstanceCache mandates NoSuchObjectException for bean not found. This is incorrect for local invocations and leads to an EJBException wrapping the exception. Since the cache knows nothing about local/remote the obvious fix is to unwrap the NoSuchObjectException and recreate it as a NoSuchObjectLocalException wherever get() is used. Anybody see another way of doing this? Regards, Adrian -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
