[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] [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] 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] 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] 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: (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] Updated: (JBAS-65) MDB Deployment ignores activation-config
[ http://jira.jboss.com/jira/browse/JBAS-65?page=history ] Adrian Brock updated JBAS-65: - Assign To: Adrian Brock (was: Scott M Stark) Version: JBossAS-4.0.1RC1 (was: JBossAS-4.0.1 Final) 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] Commented: (JBAS-65) MDB Deployment ignores activation-config
[ http://jira.jboss.com/jira/browse/JBAS-65?page=comments#action_12310840 ] Adrian Brock commented on JBAS-65: -- Yes, but the JMS inbound RA needs proper stress testing before we recommend it as the default container configuration. See the linked task. http://jira.jboss.com/jira/browse/JBJCA-6 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] Commented: (JBJCA-6) JMS Message Inflow
[ http://jira.jboss.com/jira/browse/JBJCA-6?page=comments#action_12310841 ] Adrian Brock commented on JBJCA-6: -- As Scott suggested here: http://jira.jboss.com/jira/browse/JBAS-65 the container invoker should be based on the version from the deployment descriptor. 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 Fix For: JBossAS-4.0.2 Final 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] Commented: (JBJCA-6) JMS Message Inflow
[ http://jira.jboss.com/jira/browse/JBJCA-6?page=comments#action_12310856 ] Adrian Brock commented on JBJCA-6: -- You mean make the JMSContainerInvoker parse the activation-config if it is present? That should work. The full list of standard parameters is in appendix B of the JCA 1.5 spec or on the top section of here: http://www.jboss.org/wiki/Wiki.jsp?page=ConfigJMSMessageListener We could also anticipate the parameters provided by the generic jms inflow resource adapter which would remove the need to create a custom invoker-proxy-binding in jboss.xml to override the default parameters. You should also be aware that I allow activation-config in both jboss.xml and standardjboss.xml on the invoker-proxy-binding: See the Alternate MDB proxy factory section on the above link. I don't know which should take precedence when both the old config and the activation-config are present, probably the latter? If this is what you mean, it should really be a separate task in JIRA to this one. You can assign it to me. I need to do some coding. I'm getting so bored doing design work, I'm answering forum posts :-) 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 Fix For: JBossAS-4.0.2 Final 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] Commented: (JBAS-57) Need the ability to disable ha invoker local optimization path
[ http://jira.jboss.com/jira/browse/JBAS-57?page=comments#action_12310861 ] Adrian Brock commented on JBAS-57: -- I remember Sacha saying this check was actually redundant since the Invoker Interceptor does the isLocal() checks and this check stops that interceptor or its subclasses overriding the policy. I'll ping him to see whether he remembers this discussion. Need the ability to disable ha invoker local optimization path -- Key: JBAS-57 URL: http://jira.jboss.com/jira/browse/JBAS-57 Project: JBoss Application Server Type: Feature Request Components: Clustering Versions: JBossAS-3.2.6 Final, JBossAS-4.0.0 Final Reporter: Scott M Stark Assignee: Adrian Brock Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.1 Final The ha invoker proxies currently perform a check for a collocated call, and if this check is statisfied, the ha invoker channel is ignored. A frequent request is to disable this. Because this logic is embedded in the ha invoker proxy instead of the InvokerInterceptor, this cannot be easily done. In lieu of a refactoring of the ha proxy, there should be a flag which simply disables the optimization done within the proxy. One might even argue that this check should be removed altogether since it does already exist at the InvokerInterceptor 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] Updated: (JBJCA-6) JMS Message Inflow
[ http://jira.jboss.com/jira/browse/JBJCA-6?page=history ] Adrian Brock updated JBJCA-6: - Fix Version: JBossAS-4.0.2 Final 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 Fix For: JBossAS-4.0.2 Final 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] Updated: (JBJCA-5) Interceptors
[ http://jira.jboss.com/jira/browse/JBJCA-5?page=history ] Adrian Brock updated JBJCA-5: - Fix Version: JBossAS-5.0 Beta Interceptors Key: JBJCA-5 URL: http://jira.jboss.com/jira/browse/JBJCA-5 Project: JBoss JCA Type: Task Reporter: Adrian Brock Priority: Minor Fix For: JBossAS-5.0 Beta 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: (JBJCA-3) RAR MetaData Repository
RAR MetaData Repository --- Key: JBJCA-3 URL: http://jira.jboss.com/jira/browse/JBJCA-3 Project: JBoss JCA Type: Task Reporter: Adrian Brock Priority: Minor Forums Discussion Thread: http://www.jboss.org/index.html?module=bbop=viewtopict=48681 Implement a RAR MetaData repository. There are two use cases of this object: * A tool wants to retrieve information about how to configure a RAR deployment either inbound/outbound or admin object * Avoiding the need to specify the rar-name in jboss.xml, -ds.xml or admin object deployments when only one rar implements the connection definition or message listener. Design: 1) When a RAR is deployed/undeployed update the repository with information about the RAR including cross references by * ConnectionDefinition * MessageListener * AdminObject 2) When an MDB is deployed without identifying the rar, use the repository to try to guess the RAR 3) When a ConnectionFactory is deployed without identifying the rar, use the repository to try to guess the RAR 4) When an AdminObject is deployed without identifying the rar, use the repository to try to guess the RAR The algorithm to guess the RAR is a) Is there only one RAR implementing the object b) If there is more than one RAR, is there a specific RAR in the same top level deployment (EAR) as the referencing deployment -- 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-14) Clustered Invocation Layer
[ http://jira.jboss.com/jira/browse/JBMQ-14?page=history ] Adrian Brock updated JBMQ-14: - Component: Transport 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: (JBJCA-4) Improved management
Improved management --- Key: JBJCA-4 URL: http://jira.jboss.com/jira/browse/JBJCA-4 Project: JBoss JCA Type: Task Reporter: Adrian Brock 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: (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: Done Fixed for 4.0.1 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.0 Final Environment: Sun JVM 5 JBOSS: 4.0.1 RC1 Reporter: Michael Kopp Assignee: Adrian Brock Fix For: JBossAS-4.0.1 Final 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] Commented: (JBAS-57) Need the ability to disable ha invoker local optimization path
[ http://jira.jboss.com/jira/browse/JBAS-57?page=comments#action_12310875 ] Adrian Brock commented on JBAS-57: -- Since we've decided the colocation check is not redundant. I've put the proposed solution in the forums for discussion. Need the ability to disable ha invoker local optimization path -- Key: JBAS-57 URL: http://jira.jboss.com/jira/browse/JBAS-57 Project: JBoss Application Server Type: Feature Request Components: Clustering Versions: JBossAS-3.2.6 Final, JBossAS-4.0.0 Final Reporter: Scott M Stark Assignee: Adrian Brock Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.1 Final The ha invoker proxies currently perform a check for a collocated call, and if this check is statisfied, the ha invoker channel is ignored. A frequent request is to disable this. Because this logic is embedded in the ha invoker proxy instead of the InvokerInterceptor, this cannot be easily done. In lieu of a refactoring of the ha proxy, there should be a flag which simply disables the optimization done within the proxy. One might even argue that this check should be removed altogether since it does already exist at the InvokerInterceptor 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] Updated: (JBAS-57) Need the ability to disable ha invoker local optimization path
[ http://jira.jboss.com/jira/browse/JBAS-57?page=history ] Adrian Brock updated JBAS-57: - JBoss Forum Reference: http://www.jboss.org/index.html?module=bbop=viewtopict=57830 Need the ability to disable ha invoker local optimization path -- Key: JBAS-57 URL: http://jira.jboss.com/jira/browse/JBAS-57 Project: JBoss Application Server Type: Feature Request Components: Clustering Versions: JBossAS-3.2.6 Final, JBossAS-4.0.0 Final Reporter: Scott M Stark Assignee: Adrian Brock Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.1 Final The ha invoker proxies currently perform a check for a collocated call, and if this check is statisfied, the ha invoker channel is ignored. A frequent request is to disable this. Because this logic is embedded in the ha invoker proxy instead of the InvokerInterceptor, this cannot be easily done. In lieu of a refactoring of the ha proxy, there should be a flag which simply disables the optimization done within the proxy. One might even argue that this check should be removed altogether since it does already exist at the InvokerInterceptor 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: (JBMICROCONT-4) Virtual File System service
[ http://jira.jboss.com/jira/browse/JBMICROCONT-4?page=comments#action_12310879 ] Adrian Brock commented on JBMICROCONT-4: Guys, maybe we shouldn't call it a VFS. Perhaps (VDF) Virtual Deployment Framework is a better name. The purpose of the coponent isn't to abstract away the protocol (though that will be a part of it). In fact for the osgi facade there will be a requirement for a component to get URLHandlers. The purpose of the VDF is to abstract away: 1) The meta data location 2) The real urls that make up the classpath 3) Identifying subdeployments 4) The unpacking of the subdeployments into a temporary location 5) The downloading of remote deployments to the temporary location 6) Unpacked/packed deployments 7) The logical urls that make up the codebase for security checks Virtual File System service --- Key: JBMICROCONT-4 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-4 Project: JBoss MicroContainer Type: Feature Request Reporter: Ivelin Ivanov Assignee: Dimitris Andreadis Priority: Critical Fix For: JBossMC_1_0_0M2 [Adrian] Ok, here is the design I have in mind for the new deployer aspects. This will be part of JBoss Kernel M2 release due by end of January. Deploying Deployers: First you have to be able to deploy a deployer. Not an easy task as I imagine the deployer will have dependencies on other services. The aim will be to minimize these dependencies to ease the problem. Basic Architecture: The basic architecture of the aspectized deployer is that the deployments work with a tree of DeploymentInfo objects just like the deployers do now. There are two major differences: 1) The deployers do not deal with urls, they deal with VFS contexts 2) The deployers do not create objects directly, instead they create kernel MetaData objects and submit them to the kernel for instantiation/configuration to obtain correct ordering of startup/shutdown Deployment Mode: The deployers work in two different modes 1) The first step is to ask who recognises the VFS context. This is so the responsible deployer can correctly decide which part of the context takes part in the classloading and where the metadata is located. Additionally, this may introduce subdeployments (VFS contexts) if the deployment allows/contains them. 2) The second step (the main chain) allows each deployer to augment the kernel metadata with its own config. Deployer Ordering: Since the deployers are working on a metadata model rather than constructing objects directly, there should be less problem with ordering. Most ordering will be in the classloader/instantiation/config stage, the deployer should insert that ordering in the form of dependencies in the metadata. The only ordering required of the deployer chain is where one deployer needs to work on the kernel metadata output of another deployer. Killing two birds with one stone: The problems mentioned with the deployer requiring other services and the first tasks performed by package specific deployers, i.e. identifying the deployment and its structure can be easily solved by splitting the deployers into two classes 1) A structural component that says I recognise this deployment and this is how it is structured 2) An interpretive component that creates the kernel metadata from the package. -- 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] 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] 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] 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] Commented: (JBAOP-56) Better handling of unused import package by Javassist at runtime
[ http://jira.jboss.com/jira/browse/JBAOP-56?page=comments#action_12310908 ] Adrian Brock commented on JBAOP-56: --- No, the correct solution is to remove all the dependencies on the JBoss server projects for the standalone product. JBossAS/JBossCache integration should be an optional jar. If necessary (and I would advise), create a separate project for the JBossAS integration to enforce this. You shouldn't need (don't want) any of these imports to build the core/standalone jboss cache product. from cache/build.xml path refid=jboss.system.classpath/ path refid=jboss.naming.classpath/ path refid=jboss.messaging.classpath/ path refid=jboss.server.classpath/ path refid=jboss.security.classpath/ path refid=jboss.jmx.classpath/ path refid=jboss.management.classpath/ path refid=jboss.transaction.classpath/ I don't see why you would need to directly reference the jnp implementation anyway? Better handling of unused import package by Javassist at runtime Key: JBAOP-56 URL: http://jira.jboss.com/jira/browse/JBAOP-56 Project: JBoss AOP Type: Feature Request Reporter: Ben Wang Assignee: Bill Burke Fix For: 1.1 We run into this problem in JBossCache and I have seen this at a customer site as well. In JBossCache, for example, we import a jboss jndi package since we need to expose jndi inside JBoss AS. However, this code path is not used when running as a standalone. So once it is compiled properly inside JBoss, I can still run JBossCache outside the container. But this will generate error when running JBossCacheAop as a standalone. The reason is that Javassist will try to byte-code generate every single import package specified in the class. If not found, an exception will be thrown and stopped. In the aforementioned example, I should expect to see Javassist to just generate a warning against this and keep going. So I see two possible enhancements: 1. Generate better debugging message so user realize what's going on. Current one is burried inside a huge stack trace. 2. Have a switch somewhere (can be inside aopc) that allows the user to carry forward. -- 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 JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-73) Singleton and/or deployer is too brittle
[ http://jira.jboss.com/jira/browse/JBAS-73?page=history ] Adrian Brock updated JBAS-73: - Component: Clustering (was: CMP service) Singleton and/or deployer is too brittle Key: JBAS-73 URL: http://jira.jboss.com/jira/browse/JBAS-73 Project: JBoss Application Server Type: Bug Components: Clustering Versions: JBossAS-3.2.6 Final Reporter: Adrian Brock Assignee: Scott M Stark Trying to bootstrap two JBoss servers, but the cluster join failed because the message took too long (long garbage collection/paging on my computer?) Server 2: GMS: address is htimes2:32925 (additional data: 14 bytes) --- 2004-12-21 15:14:30,909 DEBUG [org.jboss.ha.framework.server.ClusterPartition] Starting channel 2004-12-21 15:14:30,910 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] get nodeName 2004-12-21 15:14:30,990 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Get current members 2004-12-21 15:14:30,991 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Number of cluster members: 1 2004-12-21 15:14:30,992 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Other members: 0 2004-12-21 15:14:30,992 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Fetching state (will wait for 6 milliseconds): 2004-12-21 15:14:30,999 INFO [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.DefaultPartition] New cluster view for partition DefaultPartition (id: 0, delta: 0) : [127.0.0.1:1199] 2004-12-21 15:14:31,008 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] membership changed from 1 to 1 2004-12-21 15:14:31,009 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Begin notifyListeners, viewID: 0 2004-12-21 15:14:31,009 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] I am (null) received membershipChanged event: 2004-12-21 15:14:31,010 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] Dead members: 0 ([]) 2004-12-21 15:14:31,010 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] New Members : 0 ([]) 2004-12-21 15:14:31,010 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] All Members : 1 ([127.0.0.1:1199]) 2004-12-21 15:14:31,011 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] End notifyListeners, viewID: 0 2004-12-21 15:14:31,058 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] State could not be retrieved, (must be first member of group) 2004-12-21 15:14:31,137 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] setState called 2004-12-21 15:14:31,138 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] state is null 2004-12-21 15:14:31,139 DEBUG [org.jboss.ha.framework.server.ClusterPartition] Started ClusterPartition: DefaultPartition The message was rejected by the other server (too late?) but the cluster eventually joined together Server 1: 15:13:05,825 INFO [Server] JBoss (MX MicroKernel) [3.2.7RC2 (build: CVSTag=Branch_3_2 date=200411160220)] Started in 4m:43s:249ms 15:15:39,184 WARN [NAKACK] [htimes2:32920 (additional data: 14 bytes)] discarded message from non-member htimes2:32925 (additional data: 14 bytes) 15:15:41,080 WARN [NAKACK] [htimes2:32920 (additional data: 14 bytes)] discarded message from non-member htimes2:32925 (additional data: 14 bytes) 15:15:55,106 INFO [DefaultPartition] New cluster view for partition DefaultPartition (id: 1, delta: 1) : [127.0.0.1:1099, 127.0.0.1:1199] 15:15:55,107 INFO [DefaultPartition] Merging partitions... 15:15:55,107 INFO [DefaultPartition] Dead members: 0 This meant that server2 tried to bootstrap the deploy-hasingleton but part way through doing that (when it eventually joined the cluster) it was told to undeploy it. Since the original deploy hadn't finished, this caused havoc in particular trying to use a classloader that no longer existed: 2004-12-21 15:16:28,614 ERROR [org.jboss.mq.sm.jdbc.JDBCStateManager] Starting failed JDBCStateManager org.jboss.mq.SpyJMSException: Error creating connection to the database.; - nested throwable: (java.lang.NullPointerException) at org.jboss.mq.sm.jdbc.JDBCStateManager$JDBCSession.init(JDBCStateManager.java:542) at org.jboss.mq.sm.jdbc.JDBCStateManager.initDB(JDBCStateManager.java:432) at org.jboss.mq.sm.jdbc.JDBCStateManager.startService(JDBCStateManager.java:399) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:271) at
[JBoss-dev] [JBoss JIRA] Created: (JBAS-73) Singleton and/or deployer is too brittle
Singleton and/or deployer is too brittle Key: JBAS-73 URL: http://jira.jboss.com/jira/browse/JBAS-73 Project: JBoss Application Server Type: Bug Components: Clustering Versions: JBossAS-3.2.6 Final Reporter: Adrian Brock Assigned to: Scott M Stark Trying to bootstrap two JBoss servers, but the cluster join failed because the message took too long (long garbage collection/paging on my computer?) Server 2: GMS: address is htimes2:32925 (additional data: 14 bytes) --- 2004-12-21 15:14:30,909 DEBUG [org.jboss.ha.framework.server.ClusterPartition] Starting channel 2004-12-21 15:14:30,910 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] get nodeName 2004-12-21 15:14:30,990 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Get current members 2004-12-21 15:14:30,991 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Number of cluster members: 1 2004-12-21 15:14:30,992 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Other members: 0 2004-12-21 15:14:30,992 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Fetching state (will wait for 6 milliseconds): 2004-12-21 15:14:30,999 INFO [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.DefaultPartition] New cluster view for partition DefaultPartition (id: 0, delta: 0) : [127.0.0.1:1199] 2004-12-21 15:14:31,008 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] membership changed from 1 to 1 2004-12-21 15:14:31,009 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Begin notifyListeners, viewID: 0 2004-12-21 15:14:31,009 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] I am (null) received membershipChanged event: 2004-12-21 15:14:31,010 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] Dead members: 0 ([]) 2004-12-21 15:14:31,010 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] New Members : 0 ([]) 2004-12-21 15:14:31,010 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] All Members : 1 ([127.0.0.1:1199]) 2004-12-21 15:14:31,011 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] End notifyListeners, viewID: 0 2004-12-21 15:14:31,058 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] State could not be retrieved, (must be first member of group) 2004-12-21 15:14:31,137 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] setState called 2004-12-21 15:14:31,138 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] state is null 2004-12-21 15:14:31,139 DEBUG [org.jboss.ha.framework.server.ClusterPartition] Started ClusterPartition: DefaultPartition The message was rejected by the other server (too late?) but the cluster eventually joined together Server 1: 15:13:05,825 INFO [Server] JBoss (MX MicroKernel) [3.2.7RC2 (build: CVSTag=Branch_3_2 date=200411160220)] Started in 4m:43s:249ms 15:15:39,184 WARN [NAKACK] [htimes2:32920 (additional data: 14 bytes)] discarded message from non-member htimes2:32925 (additional data: 14 bytes) 15:15:41,080 WARN [NAKACK] [htimes2:32920 (additional data: 14 bytes)] discarded message from non-member htimes2:32925 (additional data: 14 bytes) 15:15:55,106 INFO [DefaultPartition] New cluster view for partition DefaultPartition (id: 1, delta: 1) : [127.0.0.1:1099, 127.0.0.1:1199] 15:15:55,107 INFO [DefaultPartition] Merging partitions... 15:15:55,107 INFO [DefaultPartition] Dead members: 0 This meant that server2 tried to bootstrap the deploy-hasingleton but part way through doing that (when it eventually joined the cluster) it was told to undeploy it. Since the original deploy hadn't finished, this caused havoc in particular trying to use a classloader that no longer existed: 2004-12-21 15:16:28,614 ERROR [org.jboss.mq.sm.jdbc.JDBCStateManager] Starting failed JDBCStateManager org.jboss.mq.SpyJMSException: Error creating connection to the database.; - nested throwable: (java.lang.NullPointerException) at org.jboss.mq.sm.jdbc.JDBCStateManager$JDBCSession.init(JDBCStateManager.java:542) at org.jboss.mq.sm.jdbc.JDBCStateManager.initDB(JDBCStateManager.java:432) at org.jboss.mq.sm.jdbc.JDBCStateManager.startService(JDBCStateManager.java:399) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:271) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:221) at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-75) Test Server Binding Manager
[ http://jira.jboss.com/jira/browse/JBAS-75?page=history ] Adrian Brock updated JBAS-75: - Assign To: Adrian Brock (was: Ryan Campbell) Test Server Binding Manager Key: JBAS-75 URL: http://jira.jboss.com/jira/browse/JBAS-75 Project: JBoss Application Server Type: Task Components: Test Suite Reporter: Ryan Campbell Assignee: Adrian Brock There needs to be a regression test for the service binding functionality in the testsuite. A custom configuration will need to be created which uses the service binding manager to configures listners on non-standard ports. There will be at least one testcase for this configuration which will check that each service is listening on its assigned port. -- 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 JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-75) Test Server Binding Manager
[ http://jira.jboss.com/jira/browse/JBAS-75?page=history ] Adrian Brock updated JBAS-75: - Version: JBossAS-3.2.6 Final Fix Version: JBossAS-3.2.7 Final Test Server Binding Manager Key: JBAS-75 URL: http://jira.jboss.com/jira/browse/JBAS-75 Project: JBoss Application Server Type: Task Components: Test Suite Versions: JBossAS-3.2.6 Final Reporter: Ryan Campbell Assignee: Adrian Brock Fix For: JBossAS-3.2.7 Final There needs to be a regression test for the service binding functionality in the testsuite. A custom configuration will need to be created which uses the service binding manager to configures listners on non-standard ports. There will be at least one testcase for this configuration which will check that each service is listening on its assigned port. -- 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 JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-75) Test Server Binding Manager
[ http://jira.jboss.com/jira/browse/JBAS-75?page=history ] Adrian Brock closed JBAS-75: Resolution: Done Added regression test test-example-binding-manager Test Server Binding Manager Key: JBAS-75 URL: http://jira.jboss.com/jira/browse/JBAS-75 Project: JBoss Application Server Type: Task Components: Test Suite Versions: JBossAS-3.2.6 Final Reporter: Ryan Campbell Assignee: Adrian Brock Fix For: JBossAS-3.2.7 Final There needs to be a regression test for the service binding functionality in the testsuite. A custom configuration will need to be created which uses the service binding manager to configures listners on non-standard ports. There will be at least one testcase for this configuration which will check that each service is listening on its assigned port. -- 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 JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-57) Need the ability to disable ha invoker local optimization path
[ http://jira.jboss.com/jira/browse/JBAS-57?page=history ] Adrian Brock closed JBAS-57: Resolution: Done Done Need the ability to disable ha invoker local optimization path -- Key: JBAS-57 URL: http://jira.jboss.com/jira/browse/JBAS-57 Project: JBoss Application Server Type: Feature Request Components: Clustering Versions: JBossAS-3.2.6 Final, JBossAS-4.0.0 Final Reporter: Scott M Stark Assignee: Adrian Brock Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.1 Final The ha invoker proxies currently perform a check for a collocated call, and if this check is statisfied, the ha invoker channel is ignored. A frequent request is to disable this. Because this logic is embedded in the ha invoker proxy instead of the InvokerInterceptor, this cannot be easily done. In lieu of a refactoring of the ha proxy, there should be a flag which simply disables the optimization done within the proxy. One might even argue that this check should be removed altogether since it does already exist at the InvokerInterceptor 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 JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBJMX-3) Fix ClassCastException in javax.management.monitor.Monitor.getObservedObjects()
[ http://jira.jboss.com/jira/browse/JBJMX-3?page=history ]
Adrian Brock closed JBJMX-3:
Resolution: Rejected
All the latest branches I have (3.2.7RC2, 4.0.1RC3, 5.0.0alpha)
use the keySet()
If you want to reopen this issue, please provide the CVS version
of the source you think is both the latest version and wrong.
Fix ClassCastException in
javax.management.monitor.Monitor.getObservedObjects()
---
Key: JBJMX-3
URL: http://jira.jboss.com/jira/browse/JBJMX-3
Project: JBoss JMX
Type: Patch
Environment: At least from Jboss 3.2.5. Still in HEAD.
Reporter: Christopher Day
Assignee: Adrian Brock
When trying to access a StringMonitor from jmx-console, I get a
ClassCastException from
javax.management.monitor.Monitor.getObservedObjects(). This is because the
method incorrectly iterates over the keys of the observedObjects HashMap,
rather than the values. The Exception is raised when the iterator.next() is
cast to an ObservedObject, since the keys are ObjectNames. The following
patch fixes the problem.
--- Monitor.java2004-12-22 16:57:52.207142400 -0800
+++
/cygdrive/c/jboss-3.2.5-src/jmx/src/main/javax/management/monitor/Monitor.java
2004-01-02 13:56:54.0 -0800
@@ -181,7 +181,7 @@
public ObjectName[] getObservedObjects()
{
-Set set = new HashSet(observedObjects.values());
+Set set = new HashSet(observedObjects.keySet());
elementCount = set.size();
ObjectName[] result = new ObjectName[set.size()];
alreadyNotifieds = new int[set.size()];
--
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
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBJMX-3) Fix ClassCastException in javax.management.monitor.Monitor.getObservedObjects()
[ http://jira.jboss.com/jira/browse/JBJMX-3?page=comments#action_12310929 ]
Adrian Brock commented on JBJMX-3:
--
It is a good job you are awake Scott. :-)
Fix ClassCastException in
javax.management.monitor.Monitor.getObservedObjects()
---
Key: JBJMX-3
URL: http://jira.jboss.com/jira/browse/JBJMX-3
Project: JBoss JMX
Type: Patch
Environment: At least from Jboss 3.2.5. Still in HEAD.
Reporter: Christopher Day
Assignee: Scott M Stark
When trying to access a StringMonitor from jmx-console, I get a
ClassCastException from
javax.management.monitor.Monitor.getObservedObjects(). This is because the
method incorrectly iterates over the keys of the observedObjects HashMap,
rather than the values. The Exception is raised when the iterator.next() is
cast to an ObservedObject, since the keys are ObjectNames. The following
patch fixes the problem.
--- Monitor.java2004-12-22 16:57:52.207142400 -0800
+++
/cygdrive/c/jboss-3.2.5-src/jmx/src/main/javax/management/monitor/Monitor.java
2004-01-02 13:56:54.0 -0800
@@ -181,7 +181,7 @@
public ObjectName[] getObservedObjects()
{
-Set set = new HashSet(observedObjects.values());
+Set set = new HashSet(observedObjects.keySet());
elementCount = set.size();
ObjectName[] result = new ObjectName[set.size()];
alreadyNotifieds = new int[set.size()];
--
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
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Reopened: (JBJMX-3) Fix ClassCastException in javax.management.monitor.Monitor.getObservedObjects()
[ http://jira.jboss.com/jira/browse/JBJMX-3?page=history ]
Adrian Brock reopened JBJMX-3:
--
Fix ClassCastException in
javax.management.monitor.Monitor.getObservedObjects()
---
Key: JBJMX-3
URL: http://jira.jboss.com/jira/browse/JBJMX-3
Project: JBoss JMX
Type: Patch
Environment: At least from Jboss 3.2.5. Still in HEAD.
Reporter: Christopher Day
Assignee: Scott M Stark
When trying to access a StringMonitor from jmx-console, I get a
ClassCastException from
javax.management.monitor.Monitor.getObservedObjects(). This is because the
method incorrectly iterates over the keys of the observedObjects HashMap,
rather than the values. The Exception is raised when the iterator.next() is
cast to an ObservedObject, since the keys are ObjectNames. The following
patch fixes the problem.
--- Monitor.java2004-12-22 16:57:52.207142400 -0800
+++
/cygdrive/c/jboss-3.2.5-src/jmx/src/main/javax/management/monitor/Monitor.java
2004-01-02 13:56:54.0 -0800
@@ -181,7 +181,7 @@
public ObjectName[] getObservedObjects()
{
-Set set = new HashSet(observedObjects.values());
+Set set = new HashSet(observedObjects.keySet());
elementCount = set.size();
ObjectName[] result = new ObjectName[set.size()];
alreadyNotifieds = new int[set.size()];
--
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
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBJMX-3) Fix ClassCastException in javax.management.monitor.Monitor.getObservedObjects()
[ http://jira.jboss.com/jira/browse/JBJMX-3?page=history ]
Adrian Brock updated JBJMX-3:
-
Version: JBossAS-3.2.5
Fix ClassCastException in
javax.management.monitor.Monitor.getObservedObjects()
---
Key: JBJMX-3
URL: http://jira.jboss.com/jira/browse/JBJMX-3
Project: JBoss JMX
Type: Patch
Versions: JBossAS-3.2.5
Environment: At least from Jboss 3.2.5. Still in HEAD.
Reporter: Christopher Day
Assignee: Scott M Stark
When trying to access a StringMonitor from jmx-console, I get a
ClassCastException from
javax.management.monitor.Monitor.getObservedObjects(). This is because the
method incorrectly iterates over the keys of the observedObjects HashMap,
rather than the values. The Exception is raised when the iterator.next() is
cast to an ObservedObject, since the keys are ObjectNames. The following
patch fixes the problem.
--- Monitor.java2004-12-22 16:57:52.207142400 -0800
+++
/cygdrive/c/jboss-3.2.5-src/jmx/src/main/javax/management/monitor/Monitor.java
2004-01-02 13:56:54.0 -0800
@@ -181,7 +181,7 @@
public ObjectName[] getObservedObjects()
{
-Set set = new HashSet(observedObjects.values());
+Set set = new HashSet(observedObjects.keySet());
elementCount = set.size();
ObjectName[] result = new ObjectName[set.size()];
alreadyNotifieds = new int[set.size()];
--
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
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBJTA-1) Transaction Recovery
[ http://jira.jboss.com/jira/browse/JBJTA-1?page=history ] Adrian Brock updated JBJTA-1: - Description: 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() was: 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() Environment: JBoss Forum Reference: http://www.jboss.org/index.html?module=bbop=viewtopict=58285 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 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
[JBoss-dev] [JBoss JIRA] Commented: (JBMICROCONT-4) Virtual File System service
[ http://jira.jboss.com/jira/browse/JBMICROCONT-4?page=comments#action_12314483 ] Adrian Brock commented on JBMICROCONT-4: Webdav support be optional like it is with the current kernel. Virtual File System service --- Key: JBMICROCONT-4 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-4 Project: JBoss MicroContainer Type: Feature Request Reporter: Ivelin Ivanov Assignee: Dimitris Andreadis Priority: Critical Fix For: JBossMC_1_0_0M2 [Adrian] Ok, here is the design I have in mind for the new deployer aspects. This will be part of JBoss Kernel M2 release due by end of January. Deploying Deployers: First you have to be able to deploy a deployer. Not an easy task as I imagine the deployer will have dependencies on other services. The aim will be to minimize these dependencies to ease the problem. Basic Architecture: The basic architecture of the aspectized deployer is that the deployments work with a tree of DeploymentInfo objects just like the deployers do now. There are two major differences: 1) The deployers do not deal with urls, they deal with VFS contexts 2) The deployers do not create objects directly, instead they create kernel MetaData objects and submit them to the kernel for instantiation/configuration to obtain correct ordering of startup/shutdown Deployment Mode: The deployers work in two different modes 1) The first step is to ask who recognises the VFS context. This is so the responsible deployer can correctly decide which part of the context takes part in the classloading and where the metadata is located. Additionally, this may introduce subdeployments (VFS contexts) if the deployment allows/contains them. 2) The second step (the main chain) allows each deployer to augment the kernel metadata with its own config. Deployer Ordering: Since the deployers are working on a metadata model rather than constructing objects directly, there should be less problem with ordering. Most ordering will be in the classloader/instantiation/config stage, the deployer should insert that ordering in the form of dependencies in the metadata. The only ordering required of the deployer chain is where one deployer needs to work on the kernel metadata output of another deployer. Killing two birds with one stone: The problems mentioned with the deployer requiring other services and the first tasks performed by package specific deployers, i.e. identifying the deployment and its structure can be easily solved by splitting the deployers into two classes 1) A structural component that says I recognise this deployment and this is how it is structured 2) An interpretive component that creates the kernel metadata from the package. -- 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 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBMICROCONT-4) Virtual File System service
[ http://jira.jboss.com/jira/browse/JBMICROCONT-4?page=comments#action_12314485 ] Adrian Brock commented on JBMICROCONT-4: Can we put discussions in the forums and reserve JIRA for conclusions? Virtual File System service --- Key: JBMICROCONT-4 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-4 Project: JBoss MicroContainer Type: Feature Request Reporter: Ivelin Ivanov Assignee: Dimitris Andreadis Priority: Critical Fix For: JBossMC_1_0_0M2 [Adrian] Ok, here is the design I have in mind for the new deployer aspects. This will be part of JBoss Kernel M2 release due by end of January. Deploying Deployers: First you have to be able to deploy a deployer. Not an easy task as I imagine the deployer will have dependencies on other services. The aim will be to minimize these dependencies to ease the problem. Basic Architecture: The basic architecture of the aspectized deployer is that the deployments work with a tree of DeploymentInfo objects just like the deployers do now. There are two major differences: 1) The deployers do not deal with urls, they deal with VFS contexts 2) The deployers do not create objects directly, instead they create kernel MetaData objects and submit them to the kernel for instantiation/configuration to obtain correct ordering of startup/shutdown Deployment Mode: The deployers work in two different modes 1) The first step is to ask who recognises the VFS context. This is so the responsible deployer can correctly decide which part of the context takes part in the classloading and where the metadata is located. Additionally, this may introduce subdeployments (VFS contexts) if the deployment allows/contains them. 2) The second step (the main chain) allows each deployer to augment the kernel metadata with its own config. Deployer Ordering: Since the deployers are working on a metadata model rather than constructing objects directly, there should be less problem with ordering. Most ordering will be in the classloader/instantiation/config stage, the deployer should insert that ordering in the form of dependencies in the metadata. The only ordering required of the deployer chain is where one deployer needs to work on the kernel metadata output of another deployer. Killing two birds with one stone: The problems mentioned with the deployer requiring other services and the first tasks performed by package specific deployers, i.e. identifying the deployment and its structure can be easily solved by splitting the deployers into two classes 1) A structural component that says I recognise this deployment and this is how it is structured 2) An interpretive component that creates the kernel metadata from the package. -- 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 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1262) MBean for ear not deregistered when deploy fails
[ http://jira.jboss.com/jira/browse/JBAS-1262?page=comments#action_12314506 ] Adrian Brock commented on JBAS-1262: I proposed the correct way to fix this on this dev forum post: http://www.jboss.org/index.html?module=bbop=viewtopict=53623 MBean for ear not deregistered when deploy fails Key: JBAS-1262 URL: http://jira.jboss.com/jira/browse/JBAS-1262 Project: JBoss Application Server Type: Bug Components: EJBs Versions: JBossAS-4.0.1 Final Environment: Win2k, JDK 1.4.2, default-configuration as supplied. Reporter: Heiko W. Rupp Assignee: Scott M Stark 1) deploy an ear that has a ejb-jar in it that fails verification 2) redeploy the same ear (either with or without changed jar). 3) you will get an exception: 21:55:12,206 INFO [EARDeployer] Init J2EE application: file:/D:/jboss401/server /small/deploy/adb.ear 21:55:12,296 INFO [EARDeployment] Registration is not done - stop 21:55:12,296 ERROR [MainDeployer] Could not initialise deployment: file:/D:/jboss401/server/small/deploy/adb.ear org.jboss.deployment.DeploymentException: Error in accessing application metadata: ; - nested throwable: javax.management.InstanceAlreadyExistsException: jboss.j2ee:service=EARDeployment,url='adb.ear' already registered.) 4) Go to jmx-console jboss.j2ee * service=EARDeployer * service=EARDeployment,url='adb.ear' 5) go into the ,url=... MBean 6) MBean is in state 8 (registered) 7) call stop() and/or destroy() 22:01:47,795 WARN [ServiceController] Ignoring request to destroy nonexistent service: jboss.j2ee:service=EARDeployment,url='adb.ear' 8) redeploy ear - same exception again 9) call unregister over twiddle: D: d:\jboss401\bin\twiddle unregister jboss.j2ee:service=EARDeployment,url='adb.ear' 10) MBean is gone in MBean-List, ear can be deployed as usual. -- 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 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1269) toString called on EJB
[ http://jira.jboss.com/jira/browse/JBAS-1269?page=comments#action_12314539 ] Adrian Brock commented on JBAS-1269: There are two errors here: 1) The provider of the EJB must know that toString() should not throw an exception and that using getPrimaryKey() is not allowed in all contexts. e.g. the ejb instance may be being used on a home invocation. 2) The logging within JBoss should cause the operation to fail. It can be easily fixed in this case since all we are interested in is identifying the ejb instance so we can just use the default toString() implementation: -log.trace(new stack for key: + rawKey); +log.trace(new stack for key: + rawKey.getClass().getName() + @ + Integer.getAsHexString(System.identityHashCode(rawKey))); toString called on EJB -- Key: JBAS-1269 URL: http://jira.jboss.com/jira/browse/JBAS-1269 Project: JBoss Application Server Type: Bug Components: EJBs Versions: JBossAS-4.0.1 Final Environment: Linux, J2SE 1.4.2_06 Reporter: Michael Lipp Assignee: Scott M Stark Priority: Critical org.jboss.resource.connectionmanager.CachedConnectionManager calls toString() on EJBs (e.g. line 250, where rawKey is an EJB. The toString() method of an EJB may, however, be overwritten, as is appropriate for the type of EJB. Such a toString() method may use getPrimaryKey() as it will usually be called from the business methods, i.e. from a context where this call is legal. CachedConnectionManager calls toString() during create, i.e. in a context where the call to getPrimaryKey is illegal, which results in an IllegalStateException. In order to avoid this kind of problem, the application server should never call toString() on 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 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1269) toString called on EJB
[ http://jira.jboss.com/jira/browse/JBAS-1269?page=history ] Adrian Brock updated JBAS-1269: --- Version: JBossAS-3.2.6 Final toString called on EJB -- Key: JBAS-1269 URL: http://jira.jboss.com/jira/browse/JBAS-1269 Project: JBoss Application Server Type: Bug Components: EJBs Versions: JBossAS-4.0.1 Final, JBossAS-3.2.6 Final Environment: Linux, J2SE 1.4.2_06 Reporter: Michael Lipp Assignee: Adrian Brock Priority: Critical org.jboss.resource.connectionmanager.CachedConnectionManager calls toString() on EJBs (e.g. line 250, where rawKey is an EJB. The toString() method of an EJB may, however, be overwritten, as is appropriate for the type of EJB. Such a toString() method may use getPrimaryKey() as it will usually be called from the business methods, i.e. from a context where this call is legal. CachedConnectionManager calls toString() during create, i.e. in a context where the call to getPrimaryKey is illegal, which results in an IllegalStateException. In order to avoid this kind of problem, the application server should never call toString() on 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 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1269) toString called on EJB
[ http://jira.jboss.com/jira/browse/JBAS-1269?page=history ] Adrian Brock updated JBAS-1269: --- Assign To: Adrian Brock (was: Scott M Stark) toString called on EJB -- Key: JBAS-1269 URL: http://jira.jboss.com/jira/browse/JBAS-1269 Project: JBoss Application Server Type: Bug Components: EJBs Versions: JBossAS-4.0.1 Final Environment: Linux, J2SE 1.4.2_06 Reporter: Michael Lipp Assignee: Adrian Brock Priority: Critical org.jboss.resource.connectionmanager.CachedConnectionManager calls toString() on EJBs (e.g. line 250, where rawKey is an EJB. The toString() method of an EJB may, however, be overwritten, as is appropriate for the type of EJB. Such a toString() method may use getPrimaryKey() as it will usually be called from the business methods, i.e. from a context where this call is legal. CachedConnectionManager calls toString() during create, i.e. in a context where the call to getPrimaryKey is illegal, which results in an IllegalStateException. In order to avoid this kind of problem, the application server should never call toString() on 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 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1269) toString called on EJB
[ http://jira.jboss.com/jira/browse/JBAS-1269?page=comments#action_12314540 ] Adrian Brock commented on JBAS-1269: - 2) The logging within JBoss should cause the operation to fail. + 2) The logging within JBoss should NOT cause the operation to fail. toString called on EJB -- Key: JBAS-1269 URL: http://jira.jboss.com/jira/browse/JBAS-1269 Project: JBoss Application Server Type: Bug Components: EJBs Versions: JBossAS-4.0.1 Final Environment: Linux, J2SE 1.4.2_06 Reporter: Michael Lipp Assignee: Scott M Stark Priority: Critical org.jboss.resource.connectionmanager.CachedConnectionManager calls toString() on EJBs (e.g. line 250, where rawKey is an EJB. The toString() method of an EJB may, however, be overwritten, as is appropriate for the type of EJB. Such a toString() method may use getPrimaryKey() as it will usually be called from the business methods, i.e. from a context where this call is legal. CachedConnectionManager calls toString() during create, i.e. in a context where the call to getPrimaryKey is illegal, which results in an IllegalStateException. In order to avoid this kind of problem, the application server should never call toString() on 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 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1269) toString called on EJB
[ http://jira.jboss.com/jira/browse/JBAS-1269?page=comments#action_12314542 ] Adrian Brock commented on JBAS-1269: I also believe you'll find that the other places in the ejb container that are interested in logging the ejb dump the ejb context to the log rather than the ejb instance. toString called on EJB -- Key: JBAS-1269 URL: http://jira.jboss.com/jira/browse/JBAS-1269 Project: JBoss Application Server Type: Bug Components: EJBs Versions: JBossAS-4.0.1 Final, JBossAS-3.2.6 Final Environment: Linux, J2SE 1.4.2_06 Reporter: Michael Lipp Assignee: Adrian Brock Priority: Critical org.jboss.resource.connectionmanager.CachedConnectionManager calls toString() on EJBs (e.g. line 250, where rawKey is an EJB. The toString() method of an EJB may, however, be overwritten, as is appropriate for the type of EJB. Such a toString() method may use getPrimaryKey() as it will usually be called from the business methods, i.e. from a context where this call is legal. CachedConnectionManager calls toString() during create, i.e. in a context where the call to getPrimaryKey is illegal, which results in an IllegalStateException. In order to avoid this kind of problem, the application server should never call toString() on 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 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBMQ-17) Fix for Use of Non-Serializable Xid Implementations
[ http://jira.jboss.com/jira/browse/JBMQ-17?page=history ] Adrian Brock updated JBMQ-17: - Attachment: JBossMQXid.java Fix for Use of Non-Serializable Xid Implementations --- Key: JBMQ-17 URL: http://jira.jboss.com/jira/browse/JBMQ-17 Project: JBoss MQ Type: Patch Components: Transport, Persistence Versions: JBossAS-3.2.6 Environment: WebSphere Application Server 5.0.2 Reporter: Daniel Ramagem Assignee: Adrian Brock Attachments: JBossMQXid.java, JBossMQXid.java, TransactionRequest.java.diff A java.io.NotSerializableException is thrown when using JBossMQ as a transactional Generic JMS Provider under IBM WebSphere Application Server 5.0.2. The IBM class com.ibm.ejs.jts.jta.XID is not serializable and causes the SpyXAResourceManager.prepare(...) method to fail. The solution is to: 1) Clone (deep copy) the non-serializable Xid to a new a new serializable Xid wrapper: JBossMQXid.java. 2) The org.jboss.mq.TransactionRequest class' writeExternal(...) method must be modified to perform the wrapping 3) The JBossMQXid class must now be available under both client and server. I think the packaging jboss-3.2.6-src product needs to be modified so that upon a build the JBossMQXid class gets made available in the jbossmq server (created when /jboss-3.2.6/docs/examples/jms/standalone/build.xml is run). I had to manually add the jbossmq-client.jar to servers/jbossmq/lib to make it work. -- 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 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBMQ-17) Fix for Use of Non-Serializable Xid Implementations
[ http://jira.jboss.com/jira/browse/JBMQ-17?page=history ] Adrian Brock updated JBMQ-17: - Attachment: TransactionRequest.java Fix for Use of Non-Serializable Xid Implementations --- Key: JBMQ-17 URL: http://jira.jboss.com/jira/browse/JBMQ-17 Project: JBoss MQ Type: Patch Components: Transport, Persistence Versions: JBossAS-4.0.1 Environment: WebSphere Application Server 5.0.2 Reporter: Daniel Ramagem Assignee: Adrian Brock Attachments: JBossMQXid.java, JBossMQXid.java, TransactionRequest.java, TransactionRequest.java.diff A java.io.NotSerializableException is thrown when using JBossMQ as a transactional Generic JMS Provider under IBM WebSphere Application Server 5.0.2. The IBM class com.ibm.ejs.jts.jta.XID is not serializable and causes the SpyXAResourceManager.prepare(...) method to fail. The solution is to: 1) Clone (deep copy) the non-serializable Xid to a new a new serializable Xid wrapper: JBossMQXid.java. 2) The org.jboss.mq.TransactionRequest class' writeExternal(...) method must be modified to perform the wrapping 3) The JBossMQXid class must now be available under both client and server. I think the packaging jboss-3.2.6-src product needs to be modified so that upon a build the JBossMQXid class gets made available in the jbossmq server (created when /jboss-3.2.6/docs/examples/jms/standalone/build.xml is run). I had to manually add the jbossmq-client.jar to servers/jbossmq/lib to make it work. -- 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 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBMQ-17) Fix for Use of Non-Serializable Xid Implementations
[ http://jira.jboss.com/jira/browse/JBMQ-17?page=history ] Adrian Brock updated JBMQ-17: - Description: A java.io.NotSerializableException is thrown when using JBossMQ as a transactional Generic JMS Provider under IBM WebSphere Application Server 5.0.2. The IBM class com.ibm.ejs.jts.jta.XID is not serializable and causes the SpyXAResourceManager.prepare(...) method to fail. The solution is to: 1) Clone (deep copy) the non-serializable Xid to a new a new serializable Xid wrapper: JBossMQXid.java. 2) The org.jboss.mq.TransactionRequest class' writeExternal(...) method must be modified to perform the wrapping 3) The JBossMQXid class must now be available under both client and server. I think the packaging jboss-3.2.6-src product needs to be modified so that upon a build the JBossMQXid class gets made available in the jbossmq server (created when /jboss-3.2.6/docs/examples/jms/standalone/build.xml is run). I had to manually add the jbossmq-client.jar to servers/jbossmq/lib to make it work. was: A java.io.NotSerializableException is thrown when using JBossMQ as a transactional Generic JMS Provider under IBM WebSphere Application Server 5.0.2. The IBM class com.ibm.ejs.jts.jta.XID is not serializable and causes the SpyXAResourceManager.prepare(...) method to fail. The solution is to: 1) Clone (deep copy) the non-serializable Xid to a new a new serializable Xid wrapper: JBossMQXid.java. 2) The org.jboss.mq.TransactionRequest class' writeExternal(...) method must be modified to perform the wrapping 3) The JBossMQXid class must now be available under both client and server. I think the packaging jboss-3.2.6-src product needs to be modified so that upon a build the JBossMQXid class gets made available in the jbossmq server (created when /jboss-3.2.6/docs/examples/jms/standalone/build.xml is run). I had to manually add the jbossmq-client.jar to servers/jbossmq/lib to make it work. Version: JBossAS-4.0.1 (was: JBossAS-3.2.6) Fix for Use of Non-Serializable Xid Implementations --- Key: JBMQ-17 URL: http://jira.jboss.com/jira/browse/JBMQ-17 Project: JBoss MQ Type: Patch Components: Transport, Persistence Versions: JBossAS-4.0.1 Environment: WebSphere Application Server 5.0.2 Reporter: Daniel Ramagem Assignee: Adrian Brock Attachments: JBossMQXid.java, JBossMQXid.java, TransactionRequest.java, TransactionRequest.java.diff A java.io.NotSerializableException is thrown when using JBossMQ as a transactional Generic JMS Provider under IBM WebSphere Application Server 5.0.2. The IBM class com.ibm.ejs.jts.jta.XID is not serializable and causes the SpyXAResourceManager.prepare(...) method to fail. The solution is to: 1) Clone (deep copy) the non-serializable Xid to a new a new serializable Xid wrapper: JBossMQXid.java. 2) The org.jboss.mq.TransactionRequest class' writeExternal(...) method must be modified to perform the wrapping 3) The JBossMQXid class must now be available under both client and server. I think the packaging jboss-3.2.6-src product needs to be modified so that upon a build the JBossMQXid class gets made available in the jbossmq server (created when /jboss-3.2.6/docs/examples/jms/standalone/build.xml is run). I had to manually add the jbossmq-client.jar to servers/jbossmq/lib to make it work. -- 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 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBMQ-17) Fix for Use of Non-Serializable Xid Implementations
[ http://jira.jboss.com/jira/browse/JBMQ-17?page=comments#action_12314543 ] Adrian Brock commented on JBMQ-17: -- I've applied your fix for 3.2.7 with some modifications. I would appreciate it if you could test the attached source against WAS 5.0.2 Fix for Use of Non-Serializable Xid Implementations --- Key: JBMQ-17 URL: http://jira.jboss.com/jira/browse/JBMQ-17 Project: JBoss MQ Type: Patch Components: Transport, Persistence Versions: JBossAS-4.0.1 Environment: WebSphere Application Server 5.0.2 Reporter: Daniel Ramagem Assignee: Adrian Brock Attachments: JBossMQXid.java, JBossMQXid.java, TransactionRequest.java, TransactionRequest.java.diff A java.io.NotSerializableException is thrown when using JBossMQ as a transactional Generic JMS Provider under IBM WebSphere Application Server 5.0.2. The IBM class com.ibm.ejs.jts.jta.XID is not serializable and causes the SpyXAResourceManager.prepare(...) method to fail. The solution is to: 1) Clone (deep copy) the non-serializable Xid to a new a new serializable Xid wrapper: JBossMQXid.java. 2) The org.jboss.mq.TransactionRequest class' writeExternal(...) method must be modified to perform the wrapping 3) The JBossMQXid class must now be available under both client and server. I think the packaging jboss-3.2.6-src product needs to be modified so that upon a build the JBossMQXid class gets made available in the jbossmq server (created when /jboss-3.2.6/docs/examples/jms/standalone/build.xml is run). I had to manually add the jbossmq-client.jar to servers/jbossmq/lib to make it work. -- 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 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1269) toString called on EJB
[ http://jira.jboss.com/jira/browse/JBAS-1269?page=history ] Adrian Brock closed JBAS-1269: -- Resolution: Done Fix Version: JBossAS-3.2.7 Final JBossAS-4.0.2RC1 toString called on EJB -- Key: JBAS-1269 URL: http://jira.jboss.com/jira/browse/JBAS-1269 Project: JBoss Application Server Type: Bug Components: EJBs Versions: JBossAS-4.0.1 Final, JBossAS-3.2.6 Final Environment: Linux, J2SE 1.4.2_06 Reporter: Michael Lipp Assignee: Adrian Brock Priority: Critical Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.2RC1 org.jboss.resource.connectionmanager.CachedConnectionManager calls toString() on EJBs (e.g. line 250, where rawKey is an EJB. The toString() method of an EJB may, however, be overwritten, as is appropriate for the type of EJB. Such a toString() method may use getPrimaryKey() as it will usually be called from the business methods, i.e. from a context where this call is legal. CachedConnectionManager calls toString() during create, i.e. in a context where the call to getPrimaryKey is illegal, which results in an IllegalStateException. In order to avoid this kind of problem, the application server should never call toString() on 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 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBMQ-102) SpyObjectMessage.setObject(null) throws an Exception
[ http://jira.jboss.com/jira/browse/JBMQ-102?page=history ] Adrian Brock closed JBMQ-102: - Resolution: Done Fix Version: JBossAS-3.2.7 JBossAS-4.0.2RC1 SpyObjectMessage.setObject(null) throws an Exception Key: JBMQ-102 URL: http://jira.jboss.com/jira/browse/JBMQ-102 Project: JBoss MQ Type: Bug Versions: JBossAS-4.0.0, JBossAS-3.2.6 Reporter: Adrian Brock Assignee: Adrian Brock Fix For: JBossAS-3.2.7, JBossAS-4.0.2RC1 -- 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 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBMQ-17) Fix for Use of Non-Serializable Xid Implementations
[ http://jira.jboss.com/jira/browse/JBMQ-17?page=history ] Adrian Brock closed JBMQ-17: Resolution: Done Fix Version: JBossAS-3.2.7 JBossAS-4.0.2RC1 5.0 Alpha Fix for Use of Non-Serializable Xid Implementations --- Key: JBMQ-17 URL: http://jira.jboss.com/jira/browse/JBMQ-17 Project: JBoss MQ Type: Patch Components: Transport, Persistence Versions: JBossAS-4.0.1 Environment: WebSphere Application Server 5.0.2 Reporter: Daniel Ramagem Assignee: Adrian Brock Fix For: 5.0 Alpha, JBossAS-3.2.7, JBossAS-4.0.2RC1 Attachments: JBossMQXid.java, JBossMQXid.java, TransactionRequest.java, TransactionRequest.java.diff A java.io.NotSerializableException is thrown when using JBossMQ as a transactional Generic JMS Provider under IBM WebSphere Application Server 5.0.2. The IBM class com.ibm.ejs.jts.jta.XID is not serializable and causes the SpyXAResourceManager.prepare(...) method to fail. The solution is to: 1) Clone (deep copy) the non-serializable Xid to a new a new serializable Xid wrapper: JBossMQXid.java. 2) The org.jboss.mq.TransactionRequest class' writeExternal(...) method must be modified to perform the wrapping 3) The JBossMQXid class must now be available under both client and server. I think the packaging jboss-3.2.6-src product needs to be modified so that upon a build the JBossMQXid class gets made available in the jbossmq server (created when /jboss-3.2.6/docs/examples/jms/standalone/build.xml is run). I had to manually add the jbossmq-client.jar to servers/jbossmq/lib to make it work. -- 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 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBJMX-81) javax.management.monitor.Monitor.getObservedObjects() throws
[ http://jira.jboss.com/jira/browse/JBJMX-81?page=comments#action_12314547
]
Adrian Brock commented on JBJMX-81:
---
Didn't you already fix this Scott?
javax.management.monitor.Monitor.getObservedObjects() throws
Key: JBJMX-81
URL: http://jira.jboss.com/jira/browse/JBJMX-81
Project: JBoss JMX
Type: Bug
Reporter: SourceForge User
Assignee: Adrian Brock
SourceForge Submitter: ctday .
When I try to access a StringMonitor MBean through
jmx-console, I get a ClassCastException from
javax.management.monitor.Monitor.getObservedObjects
(). The code in the HEAD of CVS reads:
public ObjectName[] getObservedObjects()
{
Set set = new HashSet(observedObjects.keySet());
elementCount = set.size();
ObjectName[] result = new ObjectName[set.size()];
alreadyNotifieds = new int[set.size()];
int count = 0;
for (Iterator i = set.iterator(); i.hasNext();)
{
ObservedObject object = (ObservedObject) i.next
();
result[count] = object.getObjectName();
alreadyNotifieds[count++] =
object.getAlreadyNotified();
}
return result;
}
The Exception is raised from the (ObservedObject)
i.next, which is an ObjectName, not an ObservedObject.
The error appears to be in the initialization of set. The
keySet of the observedObjects HashMap is being used,
which is a set of ObjectNames, rather than the valueSet
of observedObjects, which is a set of ObservedObjects.
The code has been this way since at least 3.2.5.
--
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
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1231) CachedConnectionManager - inUseConnections not correct
[ http://jira.jboss.com/jira/browse/JBAS-1231?page=history ] Adrian Brock closed JBAS-1231: -- Resolution: Done Fix Version: JBossAS-3.2.7 Final CachedConnectionManager - inUseConnections not correct -- Key: JBAS-1231 URL: http://jira.jboss.com/jira/browse/JBAS-1231 Project: JBoss Application Server Type: Bug Components: JCA service Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Adrian Brock Fix For: JBossAS-3.2.7 Final SourceForge Submitter: prudrakshala . Environment: Windows XP SP2, JDK 1.4.2_05, JBoss 3.2.6 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 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
