September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBAS-1485) JMS ResourceAdapter makes unnecessary temporary delete requests

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1485?page=all ] Adrian Brock updated JBAS-1485: ------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 > JMS ResourceAdapter makes unnecessary temporary delete requests > --------------------------------------------------------------- > > Key: JBAS-1485 > URL: http://jira.jboss.com/jira/browse/JBAS-1485 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.1 SP1 > Reporter: Adrian Brock > Priority: Optional > Fix For: JBossAS-4.0.6.CR1 > > > The JMS ResourceAdaptor keeps track of temporaries created on a connection > (org.jboss.resource.adapter.jms.JMSSessionFactoryImpl) > and deletes them. > This is because we cannot expect the real JMS implementation to do this > because the connection is pooled and not closed. > However, if the user is deleting the temporaries themselves > (good practice in terms of resource usage), > the JMS ResourceAdapter does not know about this > and tries to repeat the delete at connection.close(); > Solution: > Add some wrapping processing for the temporary queues and topics > so we can trap temporary.delete(). That way we will know we don't > need to do it on close() > IMPORTANT: Invocations like send() or JMSMessage.setJMSReplyTo will > also need to trap these destinations to do the necessary wrapping/unwrapping. > It is also possible to retrieve a temporary destination with Session.createQueue/Topic. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1908) listMessageCounter issue with JMS subscriptions containing certain message selector characters

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1908?page=all ] Adrian Brock updated JBAS-1908: ------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 > listMessageCounter issue with JMS subscriptions containing certain message selector characters > ---------------------------------------------------------------------------------------------- > > Key: JBAS-1908 > URL: http://jira.jboss.com/jira/browse/JBAS-1908 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.2 Final > Environment: Windows XP Professional, JDK1.4.2_06, JBoss 4.0.2 > Reporter: Jaco Joubert > Priority: Minor > Fix For: JBossAS-4.0.6.CR1 > > Attachments: DestinationManager.txt, DestinationMBeanSupport.txt, listCounter.jar, MessageCounter.txt, test-topic-service.xml > > > When the message selector query for a subscription to a JMS topic looks someting like "field in ('A', 'B', 'C')", two failures occur on JMS MBeans: > 1. The listMessageCounter operation on jboss.mq:service=DestinationManager fails with a NumberFormatException: > Caused by: java.lang.NumberFormatException: For input string: " 'ghi'" > at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) > at java.lang.Integer.parseInt(Integer.java:468) > at java.lang.Integer.parseInt(Integer.java:518) > at org.jboss.mq.server.jmx.DestinationManager.listMessageCounter(DestinationManager.java:477) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) > ... 44 more > This is because the getCounterAsString() method is used on the MessageCounter to get the details and then traversed with > a StringTokenizer tokenizing on commas, but the subscription name also contains commas in this case. > 2. The listMessageCounter operation on jboss.mq.destination:name=[topicName],service=Topic works, but the resulting HTML > table has some of the selector values populating the counter columns. The problem is because of the same issue as above. > > This can be reproduced by following these steps: > 1. Startup a JBoss4.0.2 with default configuration. > 2. Deploy the attached 'test-topic-service.xml'. This will create a JMS topic called 'counterTestTopic'. > 3. Run the attached client (source included in jar). The only jar needed on classpath is the 'jbossall-client.jar': > java -cp "[path]\jbossall-client.jar;.\listCounter.jar" za.co.jdj.jbossmq.testcounter.TestListCounter > This will do the following: > 3.1. Connect to the JMS server running locally. > 3.2. Create a publisher and durable subscriber on the 'counterTestTopic' already deployed. > The subscriber has a message selector in the format already described > 3.3. Invoke the listMessageCounter operation on jboss.mq:service=DestinationManager, printing the error. > 3.4. Wait for the client to look at the html table created by the topic in a browser. > 3.5. Remove the subscription and exit. > > Suggested fixes for the problem includes: > 1. Add a getDestinationTypeDescription() method to org.jboss.mq.server.MessageCounter. (See MessageCounter.txt attached) > 2. Change the listMessageCounter method on org.jboss.mq.server.jmx.DestinationManager to not use the getCounterAsString() method > on org.jboss.mq.server.MessageCounter, but rather extract the values itself for the html table. > (See the DestinationManager.txt file attached). > 3. Change the listMessageCounter method on org.jboss.mq.server.jmx.DestinationMBeanSupport to do the same as above. > (See the DestinationMBeanSupport.txt file attached). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-744) unify and improve the messaging and scheduler implementation

by Tom Baeyens (JIRA)

unify and improve the messaging and scheduler implementation ------------------------------------------------------------ Key: JBPM-744 URL: http://jira.jboss.com/jira/browse/JBPM-744 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Reporter: Tom Baeyens Assigned To: Tom Baeyens Fix For: jBPM 3.2 alpha 1 * unify the scheduler and messaging implementation around the notion of a job * add support for multiple concurrent threads competing for job execution. synchronization is to be done by acquiring locks. acquiring the locks is done with optimistic locking so that it also works for hsqldb -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
1
0 / 0

[JBoss JIRA] Updated: (JBPM-617) keep the processdefinition.xml in the database

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-617?page=all ] Tom Baeyens updated JBPM-617: ----------------------------- Fix Version/s: jBPM 3.2 alpha 2 (was: jBPM 3.2 alpha 1) > keep the processdefinition.xml in the database > ---------------------------------------------- > > Key: JBPM-617 > URL: http://jira.jboss.com/jira/browse/JBPM-617 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Affects Versions: jBPM 3.1, jBPM 3.2 alpha 1, jBPM 3.1.1, jBPM 3.1.2 > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > Fix For: jBPM 3.2 alpha 2, jBPM 3.1.3 > > > the processdefinition.xml source should be added as a file when a process is deployed. > this file filtering behaviour should be configurable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1053) WSRP URLs are improperly un-escaped in situations where they should be.

by Chris Laprun (JIRA)

WSRP URLs are improperly un-escaped in situations where they should be. ----------------------------------------------------------------------- Key: JBPORTAL-1053 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1053 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal WSRP Affects Versions: 2.4 Final, 2.6.Alpha1 Reporter: Chris Laprun Assigned To: Chris Laprun Fix For: 2.4.1 Final, 2.6.Alpha1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBAS-3377) Multiple JMS subscriber performance in same VM

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3377?page=all ] Adrian Brock closed JBAS-3377. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > Multiple JMS subscriber performance in same VM > ---------------------------------------------- > > Key: JBAS-3377 > URL: http://jira.jboss.com/jira/browse/JBAS-3377 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.4.GA > Reporter: floe fliep > Priority: Optional > > Consider the following JMS publish/subscribe setup in JB AS 4.0.4GA: > - one JMS topic publisher running in the AS VM > - several JMS subscribers to the same topic, running on several threads in one client VM, sharing a single TopicConnection > While debugging through the JBoss AS 4.0.4GA code, it seems, and as far I was able to see, that the AS sends for each message sent through the TopicPublisher.publish(msg) several identical instances of org.jboss.mq.ReceiveRequest over the network connection, i.e. as many instances as we have subscriptions on the client side. This induces considerable network overhead with larger messages any many clients. > One workaround to it is to make a client-side construction where there is only subscriber consuming messages, which in its turn distributes them locally. But this feels a bit like building your own JMS. > Would there be a way to improve this or is this related to constraints imposed by the JMS spec.? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1346) JDBC StateManager

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1346?page=all ] Adrian Brock closed JBAS-1346. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > JDBC StateManager > ----------------- > > Key: JBAS-1346 > URL: http://jira.jboss.com/jira/browse/JBAS-1346 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-3.2.7 Final, JBossAS-4.0.1 Final > Reporter: Adrian Brock > Priority: Minor > > The JDBC StateManager should have operations to create/delete users and subscriptions in the > database, just like the old File StateManager did. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1347) Improved management

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1347?page=all ] Adrian Brock closed JBAS-1347. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > Improved management > ------------------- > > Key: JBAS-1347 > URL: http://jira.jboss.com/jira/browse/JBAS-1347 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final > 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-3035) Can't proxy JMS Queues with org.springframework.jndi.JndiObjectFactoryBean

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3035?page=all ] Adrian Brock closed JBAS-3035. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > Can't proxy JMS Queues with org.springframework.jndi.JndiObjectFactoryBean > -------------------------------------------------------------------------- > > Key: JBAS-3035 > URL: http://jira.jboss.com/jira/browse/JBAS-3035 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.2 Final, JBossAS-4.0.4RC1, JBossAS-4.0.3 SP1 > Environment: SpringFramework 1.2.7 > Reporter: Marian Noga > Priority: Minor > > Proxying of mq destinations is impossible because of lack of Interface for SpyDestination.class > Even proxying with CGLib won't work because SpyDestination.class has no public constructor. > Following configuration: > <bean id="deadLetterQueue" class="org.springframework.jndi.JndiObjectFactoryBean"> > <property name="jndiName" value="queue/DLQ" /> > <property name="cache" value="false" /> > <property name="proxyInterface" value="javax.jms.Queue" /> > </bean> > produces output: > org.springframework.jms.InvalidDestinationException: Destination is not an instance of SpyDestination QUEUE.DLQ; nested exception is javax.jms.InvalidDestinationException: Destination is not an instance of SpyDestination QUEUE.DLQ; nested exception is javax.jms.InvalidDestinationException: Destination is not an instance of SpyDestination QUEUE.DLQ > javax.jms.InvalidDestinationException: Destination is not an instance of SpyDestination QUEUE.DLQ > at org.jboss.mq.SpyMessageProducer.send(SpyMessageProducer.java:225) > at org.jboss.mq.SpyMessageProducer.send(SpyMessageProducer.java:212) > at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:519) > at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:504) > at org.springframework.jms.core.JmsTemplate$2.doInJms(JmsTemplate.java:479) > at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:432) > at org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:477) > at org.springframework.jms.core.JmsTemplate.convertAndSend(JmsTemplate.java:543) > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > changing proxyInterface to: javax.jms.Destination > Code: > <bean id="responseQueue" class="org.springframework.jndi.JndiObjectFactoryBean" lazy-init="false"> > <property name="jndiName" value="queue/konektor_out" /> > <property name="cache" value="false" /> > <property name="proxyInterface" value="javax.jms.Destination" /> > </bean> > produces following output: > java.lang.ClassCastException: $Proxy1 > at org.jboss.mq.SpySession.createProducer(SpySession.java:657) > at org.springframework.jms.core.JmsTemplate.doCreateProducer(JmsTemplate.java:807) > at org.springframework.jms.core.JmsTemplate.createProducer(JmsTemplate.java:788) > at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:498) > at org.springframework.jms.core.JmsTemplate$2.doInJms(JmsTemplate.java:479) > at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:432) > at org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:477) > at org.springframework.jms.core.JmsTemplate.convertAndSend(JmsTemplate.java:543) > can anyone tell is it possible to change behaviour of this code: > SpyMessageProducer.class > if (destination == null || (destination instanceof SpyDestination) == false) > throw new InvalidDestinationException("Destination is not an instance of SpyDestination " + destination); > if SpyDestination was an interface in the code above, everything would be fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-2120) JBossMQ should use the <type-mapping> from the DataSource

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2120?page=all ] Adrian Brock closed JBAS-2120. ------------------------------ Resolution: Deferred Closing features that are (or will be) implemented in JBoss Messaging. http://jira.jboss.com/jira/browse/JBMESSAGING If anybody wants to provide a patch that implements these, the issue can be reopened. Duplicates of these issues will be closed unless they provide an implementation/patch. Patches should first be discussed in the development forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=153 if there isn't already a forum link attached to this issue. > JBossMQ should use the <type-mapping> from the DataSource > --------------------------------------------------------- > > Key: JBAS-2120 > URL: http://jira.jboss.com/jira/browse/JBAS-2120 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.3RC1 > Reporter: Adrian Brock > Priority: Minor > > Currently JBossMQ's > JDBC2 persistence manager (http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQJDBC2Persistence) > JDBC statemanager (http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQStateJDBC) > have their SQL configured through a big map of system properties. > This means that you need different configurations for each backend DB. > See docs/examples/jms or http://www.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQDB > Instead, we should use the <type-mapping> from the DataSource which uses the standardjbosscmp-jdbc.xml > to map queries to the database. > The only configuration required, would then be > * The DataSource > * Table Names > * Column Names > with default names for each. > This should be done as a "fork", e.g. create a JDBC4 > since we still want to support people with the old configurations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2006