[jira] Resolved: (AMQ-1067) Stomp consumer not removed if client does not send disconnect message.
[ https://issues.apache.org/activemq/browse/AMQ-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james strachan resolved AMQ-1067. - Resolution: Fixed Fix Version/s: 4.2.0 4.1.1 > Stomp consumer not removed if client does not send disconnect message. > -- > > Key: AMQ-1067 > URL: https://issues.apache.org/activemq/browse/AMQ-1067 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.1.0 > Environment: Solaris 10, Perl 5.8.4 >Reporter: Chris Knight >Priority: Critical > Fix For: 4.1.1, 4.2.0 > > Attachments: perl.tar.gz > > > Run "clearQueue.pl TEST.QUEUE" > Check in jconsole. The client will still be marked as active even when the > script is killed. This prevents any meaningful use of queues if any > consumption is done via stomp. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-1134) stomp connections in the broker don't get cleared up if the socket dies
[ https://issues.apache.org/activemq/browse/AMQ-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james strachan resolved AMQ-1134. - Resolution: Fixed > stomp connections in the broker don't get cleared up if the socket dies > --- > > Key: AMQ-1134 > URL: https://issues.apache.org/activemq/browse/AMQ-1134 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.1.1, 4.2.0 > > > it looks like there's a bug causing the connection to keep around -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1134) stomp connections in the broker don't get cleared up if the socket dies
stomp connections in the broker don't get cleared up if the socket dies --- Key: AMQ-1134 URL: https://issues.apache.org/activemq/browse/AMQ-1134 Project: ActiveMQ Issue Type: Bug Components: Broker Reporter: james strachan Assigned To: james strachan Fix For: 4.1.1, 4.2.0 it looks like there's a bug causing the connection to keep around -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1130) MySql should use LONGBLOB rather than BLOB for persisting messages to avoid the 64k limit
MySql should use LONGBLOB rather than BLOB for persisting messages to avoid the 64k limit - Key: AMQ-1130 URL: https://issues.apache.org/activemq/browse/AMQ-1130 Project: ActiveMQ Issue Type: Bug Components: Broker Reporter: james strachan Assigned To: james strachan Fix For: 4.1.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-1130) MySql should use LONGBLOB rather than BLOB for persisting messages to avoid the 64k limit
[ https://issues.apache.org/activemq/browse/AMQ-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james strachan resolved AMQ-1130. - Resolution: Fixed > MySql should use LONGBLOB rather than BLOB for persisting messages to avoid > the 64k limit > - > > Key: AMQ-1130 > URL: https://issues.apache.org/activemq/browse/AMQ-1130 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.1.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-591) add a per message authorization hook so that content-based authorization can be performed using a special plugin
[ https://issues.apache.org/activemq/browse/AMQ-591?page=comments#action_37642 ] james strachan commented on AMQ-591: Here's the latest links... http://incubator.apache.org/activemq/security.html > add a per message authorization hook so that content-based authorization can > be performed using a special plugin > > > Key: AMQ-591 > URL: https://issues.apache.org/activemq/browse/AMQ-591 > Project: ActiveMQ > Issue Type: New Feature >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.0 RC2 > > > Users may want to look in the message at headers to decide if a user can or > cannot consume a message -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1073) support selectors in virtual destinations to allow a message to be dispatched to multiple phyiscal queues if it matches the selector
support selectors in virtual destinations to allow a message to be dispatched to multiple phyiscal queues if it matches the selector Key: AMQ-1073 URL: https://issues.apache.org/activemq/browse/AMQ-1073 Project: ActiveMQ Issue Type: Improvement Components: Broker Reporter: james strachan Assigned To: james strachan Fix For: 4.2.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-1068) DestinationMap seems to use up lots of RAM if using deep hierarchies
[ https://issues.apache.org/activemq/browse/AMQ-1068?page=all ] james strachan resolved AMQ-1068. - Resolution: Fixed see the test case DestinationMapMemoryTest which used to blow up and create OutOfMemory before the patch > DestinationMap seems to use up lots of RAM if using deep hierarchies > > > Key: AMQ-1068 > URL: https://issues.apache.org/activemq/browse/AMQ-1068 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.1.0, 4.0.2 >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1068) DestinationMap seems to use up lots of RAM if using deep hierarchies
DestinationMap seems to use up lots of RAM if using deep hierarchies Key: AMQ-1068 URL: https://issues.apache.org/activemq/browse/AMQ-1068 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.1.0, 4.0.2 Reporter: james strachan Assigned To: james strachan Fix For: 4.2.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-1051) be able to interact with the broker via messaging
[ https://issues.apache.org/activemq/browse/AMQ-1051?page=all ] james strachan resolved AMQ-1051. - Fix Version/s: 4.2.0 Resolution: Fixed Its described here http://activemq.org/site/command-agent.html > be able to interact with the broker via messaging > - > > Key: AMQ-1051 > URL: https://issues.apache.org/activemq/browse/AMQ-1051 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: james strachan > Fix For: 4.2.0 > > > Send a text message over JMS, XMPP, Stomp, Ajax or REST to communicate with > the broker, query queues/topics etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-1053) allow a MessageTransformer to be registered with a producer or consumer to help transform a message going onto the bus or coming off the bus
[ https://issues.apache.org/activemq/browse/AMQ-1053?page=all ] james strachan resolved AMQ-1053. - Resolution: Fixed For documentation see here: http://activemq.org/site/message-transformation.html > allow a MessageTransformer to be registered with a producer or consumer to > help transform a message going onto the bus or coming off the bus > > > Key: AMQ-1053 > URL: https://issues.apache.org/activemq/browse/AMQ-1053 > Project: ActiveMQ > Issue Type: New Feature >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.2.0 > > > For example a user may wish to use ObjectMessage in their code - but in > deployment use a TextMessage with XStream or JAXB as the marshalling. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1053) allow a MessageTransformer to be registered with a producer or consumer to help transform a message going onto the bus or coming off the bus
[ https://issues.apache.org/activemq/browse/AMQ-1053?page=comments#action_37464 ] james strachan commented on AMQ-1053: - MessageTransformer interface is now in SVN along with an implementation, XStreamMessagegeTransformer in activemq-optional which can be used to turn ObjectMessages into XML on the bus. See the XStreamTransformTest for an example of its use > allow a MessageTransformer to be registered with a producer or consumer to > help transform a message going onto the bus or coming off the bus > > > Key: AMQ-1053 > URL: https://issues.apache.org/activemq/browse/AMQ-1053 > Project: ActiveMQ > Issue Type: New Feature >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.2.0 > > > For example a user may wish to use ObjectMessage in their code - but in > deployment use a TextMessage with XStream or JAXB as the marshalling. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-1048) Some tools from Command line not works properly
[ https://issues.apache.org/activemq/browse/AMQ-1048?page=all ] james strachan reassigned AMQ-1048: --- Assignee: Adrian Co > Some tools from Command line not works properly > --- > > Key: AMQ-1048 > URL: https://issues.apache.org/activemq/browse/AMQ-1048 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.0.1 > Environment: Tested in Windows XP Professional and Linux Debian Sarge >Reporter: Lucas GPL > Assigned To: Adrian Co >Priority: Critical > Original Estimate: 2 days > Remaining Estimate: 2 days > > Some command line not works properly, just return de prompt > Example: > query -QQueue=* > query --objname Type=Connect,BrokerName=localhost -xQNetworkConnector=* > etc... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1055) support for FileMessage to allow easy transfer of attachments
support for FileMessage to allow easy transfer of attachments - Key: AMQ-1055 URL: https://issues.apache.org/activemq/browse/AMQ-1055 Project: ActiveMQ Issue Type: New Feature Reporter: james strachan Fix For: 4.3.0 For more background see... http://weblogs.java.net/blog/guruwons/archive/2006/11/sending_large_f.html http://www.nabble.com/support-for-FileMessage--tf2641673.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-847) Memory Leaks
[ https://issues.apache.org/activemq/browse/AMQ-847?page=all ] james strachan updated AMQ-847: --- Fix Version/s: 4.0.3 (was: 4.0.2) > Memory Leaks > > > Key: AMQ-847 > URL: https://issues.apache.org/activemq/browse/AMQ-847 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Reporter: Hiram Chirino > Assigned To: Hiram Chirino > Fix For: 4.0.3 > > > 1) factoryStats in the connection factory was holding on to connections even > when they are closed. > 2) peer BrokerInfos were never removed even when the peer disconnected. > 3) messages dispatched from a Queue would retain a referece to the client > connection even after they had been acked. > 4) ScheduledThreadPoolExecutor does not always seem to release references to > canceled tasks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-1018) Tomcat JVM hangs when it tried to get ConnectionFactory object
[ https://issues.apache.org/activemq/browse/AMQ-1018?page=all ]
james strachan updated AMQ-1018:
Fix Version/s: 4.0.3
(was: 4.0.2)
> Tomcat JVM hangs when it tried to get ConnectionFactory object
> --
>
> Key: AMQ-1018
> URL: https://issues.apache.org/activemq/browse/AMQ-1018
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 4.0.1
> Environment: Tomcat 5.5.9, Activemq 4.0.1
>Reporter: Suvarna Raju Madhey
>Priority: Critical
> Fix For: 4.0.3
>
> Attachments: StackTrace
>
>
> I have deployed my application in Tomcat 5.5.9, which uses Activemq 4.0.1.
> To get ConnectionFactory I have written a method called getConnectionFactory.
> Following way i am tring to lookup..
> Context ctx = new InitialContext();
> Context ctx2= (Context) initCtx.lookup("java:comp/env");
> ConnectionFactory cf = (ConnectionFactory)
> ctx2.lookup("jms/ConnectionFactory");
> 3 iterations of start and stop works successfully. But when I start the
> application 4th time, it executes Context ctx2 =
> (Context)initCtx.lookup("java:comp/env"); then it goes to next line. After
> that it never returns ConnectionFactory. After I notice that the application
> hangs..
> Please find the stack which i got by running "kill -3
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (AMQ-1036) web-console broken (queue browsing).
[ https://issues.apache.org/activemq/browse/AMQ-1036?page=all ]
james strachan reopened AMQ-1036:
-
Could you apply this fix to the 4-1 branch too please?
https://svn.apache.org/repos/asf/incubator/activemq/branches/activemq-4.1/
> web-console broken (queue browsing).
>
>
> Key: AMQ-1036
> URL: https://issues.apache.org/activemq/browse/AMQ-1036
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: incubation
>Reporter: Dave Syer
> Assigned To: Adrian Co
> Fix For: 4.1.0
>
>
> I managed to build and launch the web-console from svn, but the queue
> browsing page is broken - queue.jsp uses properties of Queue e.g. ${row.size}
> that do not exist. When I hacked queue.jsp to remove references to those
> properties I got another error on trying to purge a queue:
> RequestURI=/activemq-web-console/purgeDestination.action
> Caused by:
> java.lang.IllegalArgumentException: Target bean must not be null
> at org.springframework.util.Assert.notNull(Assert.java:113)
> at
> org.springframework.validation.BeanPropertyBindingResult.(BeanPropertyBindingResult.java:58)
> at
> org.springframework.validation.DataBinder.initBeanPropertyAccess(DataBinder.java:167)
> at
> org.springframework.validation.DataBinder.getInternalBindingResult(DataBinder.java:186)
> at
> org.springframework.validation.DataBinder.getPropertyAccessor(DataBinder.java:196)
> at
> org.springframework.validation.DataBinder.applyPropertyValues(DataBinder.java:515)
> at org.springframework.validation.DataBinder.doBind(DataBinder.java:417)
> at
> org.springframework.web.bind.WebDataBinder.doBind(WebDataBinder.java:146)
> at
> org.springframework.web.bind.ServletRequestDataBinder.bind(ServletRequestDataBinder.java:108)
> at
> org.apache.activemq.web.handler.BindingBeanNameUrlHandlerMapping.getHandlerInternal(BindingBeanNameUrlHandlerMapping.java:43)
> ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1028) AMQ Stops dispatching messages after a period of time without errors/warnings
[ https://issues.apache.org/activemq/browse/AMQ-1028?page=comments#action_37408 ] james strachan commented on AMQ-1028: - A badly behaved consumer can't bring the entire messaging system down. Dealing with slow consumers on non-persistent messaging is a common problem though - either increase the RAM, enforce persistence or use slow consumer handling... http://incubator.apache.org/activemq/slow-consumer-handling.html > AMQ Stops dispatching messages after a period of time without errors/warnings > - > > Key: AMQ-1028 > URL: https://issues.apache.org/activemq/browse/AMQ-1028 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.0.2 > Environment: Os: Ubuntu Linux i386 - Java: J2RE SE 1.5.0_08-b03 >Reporter: Bas van Beek >Priority: Critical > Fix For: 4.0.2 > > > The ActiveMQ stand alone server seems to stop dispatching messages to topics > after a period of time. > New clients can connect... new subscriptions to topics can be made... no > errors are shown... messages are just not sent... including to and from the > new clients... > No errors or warnings can be found in the ActiveMQ.log (even in debug mode) > JConsole doesn't show the new messages coming in (EnqueueCount doesn't change) > Stomp Protocol is used exclusively -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1017) Build of current trunk with Maven2 fails
[ https://issues.apache.org/activemq/browse/AMQ-1017?page=comments#action_37375 ] james strachan commented on AMQ-1017: - I've just patched the pom for activemq-xmpp to see if that helps any - I wonder could you try give it another go please and see if this fixes it for you? > Build of current trunk with Maven2 fails > > > Key: AMQ-1017 > URL: https://issues.apache.org/activemq/browse/AMQ-1017 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.1 > Environment: Windows XP, Maven 2.0.4, Java 1.5.0_06 >Reporter: Bernhard Wellhöfer >Priority: Critical > Attachments: mvn.log, mvn.log > > > A build of a fresh checkout from > https://svn.apache.org/repos/asf/incubator/activemq/trunk with Maven2 fails. > See the attached log of the build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1020) Slow consumer terminally blocks both client and broker
[ https://issues.apache.org/activemq/browse/AMQ-1020?page=comments#action_37340 ] james strachan commented on AMQ-1020: - Are you using explicit acknowledgements or auto-ack (or transactions?). The default prefetch is only about 1000 I think for NMS which means after sending 1000 messages no more messages will be dispatched to a consumer until it receives acks. So I can see why Client1 becomes stuck pretty quickly and why client1 can no longer publish more messages. So 2 things to try... use dispatchAsync=true (on consumer info) on the consumers, so that dispatching to consumers is asynchronous in the broker. That way a producer won't get blocked waiting to dispatch to slow consumers. Also try upping the prefetch value to something large. e.g. on Java for non-persistent topics its about 32000 I think > Slow consumer terminally blocks both client and broker > -- > > Key: AMQ-1020 > URL: https://issues.apache.org/activemq/browse/AMQ-1020 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.0.2 > Environment: Broker: Windows XP, Sun JDK1.5 Client: activemq-dotnet > (Trunk) >Reporter: Rob Lugt > > I have a multi-threaded client (client1) which is acting as both a publisher > (Topic1) and subscriber (Topic2) using a single session. There is another > client process (client2) which publishes on Topic2. > I have witnessed the following repeatable scenario where both clients get > stuck, which can only be rectified by restarting the broker! :- > Client1 publishes messages to Topic1 (rate = about 30 msgs/sec). > Client2 publishes bursts of messages to Topic2 (rate = 500 msgs/sec) > Client1 is a slow subscriber on Topic2 > After running in this scenario for a couple of seconds, Client1 and Client2 > become stuck. Looking at a stack trace for Client1 I can see that it's > read_loop is stuck waiting for input, and it's publisher thread is stuck > waiting for an acknowledgement to the synchronous message send (the > acknowledgement never arrives because the broker won't sent any more > messages). > Client2 is also stuck waiting for an acknowledgement to a synchronous send. > My perception is that it appears the broker is throttling the connection > because the consumer is running slowly, but for some reason it gets into a > state where all message flow stops (even though the consumer is automatically > acknowledging messages, albeit slowly). Furthermore, if I kill Client1 the > broker doesn't recover (using a JMX console the connection remains visible). > The broker uses a vanilla configuration (i.e. no policies are set for the > topics in quedtion). > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-1015) ActiveMQ web-demo and web-console cannot be run
[ https://issues.apache.org/activemq/browse/AMQ-1015?page=all ] james strachan reassigned AMQ-1015: --- Assignee: Adrian Co (was: james strachan) I've fixed this for 4.1 - wanna backport to 4.0.x? > ActiveMQ web-demo and web-console cannot be run > --- > > Key: AMQ-1015 > URL: https://issues.apache.org/activemq/browse/AMQ-1015 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 4.1, 4.0.2 >Reporter: Adrian Co > Assigned To: Adrian Co > Fix For: 4.1, 4.0.3 > > > Let's update the maven plugin from maven-jetty-plugin to maven-jetty6-plugin > for the 4.1.x branch and the 4.0.x branch. The web-console is throwing this > exception after: > java.lang.NoSuchMethodError: > org.mortbay.jetty.webapp.WebAppClassLoader.getUrlClassPath()Ljava/lang/String; > at > org.mortbay.jetty.plugin.Jetty6MavenConfiguration.configureClassLoader(Jetty6MavenConfiguration.jav > a:62) > at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:453) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) > at > org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) > at > org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:119) > at org.mortbay.jetty.Server.doStart(Server.java:210) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) > at > org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:115) > at > org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:318) > at > org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:268) > at > org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:172) > at > org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:167) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor. > java:488) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleEx > ecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.ja > va:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > 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:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1015) ActiveMQ web-demo and web-console cannot be run
[ https://issues.apache.org/activemq/browse/AMQ-1015?page=comments#action_37328 ] james strachan commented on AMQ-1015: - I've fixed SVN HEAD so that we use an explicit version of the jetty plugin, along with using maven-jetty-plugin which should fix these issues. I also upgraded to 6.0.1 of Jetty too. We should backport this to 4.0.x too > ActiveMQ web-demo and web-console cannot be run > --- > > Key: AMQ-1015 > URL: https://issues.apache.org/activemq/browse/AMQ-1015 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 4.1, 4.0.2 >Reporter: Adrian Co > Assigned To: james strachan > Fix For: 4.1, 4.0.3 > > > Let's update the maven plugin from maven-jetty-plugin to maven-jetty6-plugin > for the 4.1.x branch and the 4.0.x branch. The web-console is throwing this > exception after: > java.lang.NoSuchMethodError: > org.mortbay.jetty.webapp.WebAppClassLoader.getUrlClassPath()Ljava/lang/String; > at > org.mortbay.jetty.plugin.Jetty6MavenConfiguration.configureClassLoader(Jetty6MavenConfiguration.jav > a:62) > at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:453) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) > at > org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) > at > org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:119) > at org.mortbay.jetty.Server.doStart(Server.java:210) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) > at > org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:115) > at > org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:318) > at > org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:268) > at > org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:172) > at > org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:167) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor. > java:488) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleEx > ecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.ja > va:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > 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:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-1015) ActiveMQ web-demo and web-console cannot be run
[ https://issues.apache.org/activemq/browse/AMQ-1015?page=all ] james strachan reassigned AMQ-1015: --- Assignee: james strachan (was: Patrick Villacorta) > ActiveMQ web-demo and web-console cannot be run > --- > > Key: AMQ-1015 > URL: https://issues.apache.org/activemq/browse/AMQ-1015 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 4.1, 4.0.2 >Reporter: Adrian Co > Assigned To: james strachan > Fix For: 4.1, 4.0.3 > > > Let's update the maven plugin from maven-jetty-plugin to maven-jetty6-plugin > for the 4.1.x branch and the 4.0.x branch. The web-console is throwing this > exception after: > java.lang.NoSuchMethodError: > org.mortbay.jetty.webapp.WebAppClassLoader.getUrlClassPath()Ljava/lang/String; > at > org.mortbay.jetty.plugin.Jetty6MavenConfiguration.configureClassLoader(Jetty6MavenConfiguration.jav > a:62) > at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:453) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) > at > org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) > at > org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:119) > at org.mortbay.jetty.Server.doStart(Server.java:210) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) > at > org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:115) > at > org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:318) > at > org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:268) > at > org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:172) > at > org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:167) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor. > java:488) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleEx > ecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.ja > va:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > 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:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1015) ActiveMQ web-demo and web-console cannot be run
[ https://issues.apache.org/activemq/browse/AMQ-1015?page=comments#action_37327 ] james strachan commented on AMQ-1015: - Please keep the maven-jetty-plugin as this is the new version. The maven-jetty6-plugin is old! > ActiveMQ web-demo and web-console cannot be run > --- > > Key: AMQ-1015 > URL: https://issues.apache.org/activemq/browse/AMQ-1015 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 4.1, 4.0.2 >Reporter: Adrian Co > Assigned To: Patrick Villacorta > Fix For: 4.1, 4.0.3 > > > Let's update the maven plugin from maven-jetty-plugin to maven-jetty6-plugin > for the 4.1.x branch and the 4.0.x branch. The web-console is throwing this > exception after: > java.lang.NoSuchMethodError: > org.mortbay.jetty.webapp.WebAppClassLoader.getUrlClassPath()Ljava/lang/String; > at > org.mortbay.jetty.plugin.Jetty6MavenConfiguration.configureClassLoader(Jetty6MavenConfiguration.jav > a:62) > at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:453) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) > at > org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) > at > org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:119) > at org.mortbay.jetty.Server.doStart(Server.java:210) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) > at > org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:115) > at > org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:318) > at > org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:268) > at > org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:172) > at > org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:167) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor. > java:488) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleEx > ecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.ja > va:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > 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:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-980) lastImageSubscriptionRecoveryPolicy does not work with wildcards
[
https://issues.apache.org/activemq/browse/AMQ-980?page=comments#action_37305 ]
james strachan commented on AMQ-980:
Now that AMQ-999 is resolved, is this issue now fixed?
> lastImageSubscriptionRecoveryPolicy does not work with wildcards
>
>
> Key: AMQ-980
> URL: https://issues.apache.org/activemq/browse/AMQ-980
> Project: ActiveMQ
> Issue Type: Bug
> Components: NMS (C# client)
>Affects Versions: 4.0.2
> Environment: Windows, JDK 1.5
>Reporter: Rob Lugt
> Fix For: 4.1
>
>
> The lastImageSubscriptionRecoveryPolicy does not appear to work with
> wildcards.
> In the following example, a new consumer only receives one message for the
> topics covered by the wildcard instead of receiving one message for each
> topic.
>
> config file:-
>
>
>
>
>
>
> consumer subscription:-
> GetTopic("PRICES.>?consumer.retrocactive=true");
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-988) Thread synchronization error in TcpTransport
[ https://issues.apache.org/activemq/browse/AMQ-988?page=all ] james strachan resolved AMQ-988. Resolution: Fixed Patch applied - thanks! > Thread synchronization error in TcpTransport > > > Key: AMQ-988 > URL: https://issues.apache.org/activemq/browse/AMQ-988 > Project: ActiveMQ > Issue Type: Bug > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Windows >Reporter: Rob Lugt > Assigned To: james strachan > Fix For: 4.1 > > Attachments: amq988-patch.txt > > > I have a problem where my C# client application crashes when placed under > load. It's taken a while to get to the bottom of it, but I believe I have > identified the problem and luckily there's a simple solution. > The AMQ .Net client uses a common pattern where a full-duplex TCP/IP > connection is established with the broker, and the client uses two threads to > concurrently read and write data to/from the underlying socket - one thread > reading from a Reader object and the other writing to a Writer object. > The TcpTransport.Start() method contains the following:- > NetworkStream networkStream = new NetworkStream(socket); > socketWriter = new OpenWireBinaryWriter(networkStream); > socketReader = new OpenWireBinaryReader(networkStream); > This pattern is explicitly allowed in Java and Win32 applications, but .Net > is a little vague on the subject. The Microsoft documentation [1] suggests > use of the asynchronous read/write calls for multithreaded applications, but > that would significantly complicate the C# client which relies on blocking > stream behaviour. On the same doc page > Microsoft does specifiy that the Socket class is thread-safe, which I take to > mean that concurrent read/write calls are permitted, however the same is not > true of NetworkStream [2]. > Perhaps it would be reasonable to expect NetworkStream to have no internal > state other than the Socket it contains, but apparently this is not the case > because I've identified that it is a corrupt NetworkStream which is causing > my application to crash under load. After some experimentation and a fair > amount of load testing, I think the solution is a simple change to the > TcpTransport.start() method to use a separate NetworkStream for input and > output operations. e.g. :- > NetworkStream inputNetworkStream = new NetworkStream(socket); > NetworkStream outputNetworkStream = new NetworkStream(socket); > socketWriter = new OpenWireBinaryWriter(inputNetworkStream); > socketReader = new OpenWireBinaryReader(outputNetworkStream); > This works for me and my test client has now been running for 16 hours > without crashing (before it would rarely last longer than 10 minutes). > Regards > Rob Lugt > [1] http://msdn2.microsoft.com/en-us/library/system.net.sockets.socket.aspx > [2] > http://msdn2.microsoft.com/en-us/library/system.net.sockets.networkstream.aspx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-995) An unhandled exception in the TcpTransports' reader thread should close the connection (and inform the app)
[ https://issues.apache.org/activemq/browse/AMQ-995?page=all ] james strachan resolved AMQ-995. Fix Version/s: 4.1 Resolution: Fixed Patch applied Rob - thanks again! :) > An unhandled exception in the TcpTransports' reader thread should close the > connection (and inform the app) > --- > > Key: AMQ-995 > URL: https://issues.apache.org/activemq/browse/AMQ-995 > Project: ActiveMQ > Issue Type: Bug > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Windows >Reporter: Rob Lugt > Assigned To: james strachan > Fix For: 4.1 > > Attachments: amq995-patch.txt, AtomicBoolean.cs > > > If the reader thread throws an exception (e.g. IOException) then the socket > should be closed to prevent further messages being sent to the broker. If an > exception is thrown during the marshalling of a message then there's no way > for the stream to be set to the beginning of the next message, so all > communication with the broker should cease at that point. Similarly, if the > broker is killed, an IOException will probably be detected in the read thread > first. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-996) IConnection requires Start(), Stop() and Close() methods
[ https://issues.apache.org/activemq/browse/AMQ-996?page=all ] james strachan resolved AMQ-996. Fix Version/s: 4.1 Resolution: Fixed Fixed by AMQ-999 > IConnection requires Start(), Stop() and Close() methods > > > Key: AMQ-996 > URL: https://issues.apache.org/activemq/browse/AMQ-996 > Project: ActiveMQ > Issue Type: Improvement > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Windows >Reporter: Rob Lugt > Assigned To: james strachan > Fix For: 4.1 > > > These three methods are needed to bring IConnection closer to the JMS > Connection interface, and also provide important capabilities. > Start() and Stop() methods should start and stop/join the underlying > transport's reader thread. Close() should perform the tasks described in the > JMS specification (ie wait for current message to be processed), whereas > Dispose should probably concern itself simply with freeing up resources. > Both Close() and Dispose() should be able to be called multiple times without > throwing an exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-999) Message dispatcher issues (use dedicated dispatching thread for each session)
[ https://issues.apache.org/activemq/browse/AMQ-999?page=all ] james strachan resolved AMQ-999. Fix Version/s: 4.1 Resolution: Fixed Patches applied with thanks Rob! I made a minor change to the patch so that the code still works on Mono 1.0; I used the class AutoResetEvent instead of EventWaitHandle to avoid compile errors in Dispatcher.cs and DispatchingThead.cs - see the TODO notes in those files in case you can think of a cleaner solution. Cheers! > Message dispatcher issues (use dedicated dispatching thread for each session) > - > > Key: AMQ-999 > URL: https://issues.apache.org/activemq/browse/AMQ-999 > Project: ActiveMQ > Issue Type: Improvement > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Windows >Reporter: Rob Lugt > Assigned To: james strachan > Fix For: 4.1 > > Attachments: amq999-patch.txt, AtomicBoolean.cs, DispatchingThread.cs > > > There are a number of issues with the dispatching of inbound messages. > - A slow consumer will potentially use and block all ThreadPool threads > - Use of a ThreadPool thread to dispatch a single message is inefficient due > to context switching > - No mechanism to suspend asynchronous delivery to a session (i.e. > Connection.Stop() is currently a no-op) > - Retroactive consumer is currently broken because retoractive messages are > delivered before the listener delegate is assigned. > - [minor] Application cannot predict which thread messages will be dispatched > on > All of these problems can simply be resolved by creating a dedicated > dispatcher thread for a session -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-826) LDAP based authorization support
[ https://issues.apache.org/activemq/browse/AMQ-826?page=comments#action_37285 ] james strachan commented on AMQ-826: Note that * is only allowed on a complete path, not regex. So STOCKS.PRICE.NYSE.* or STOCKS.PRICE.*.IBM but not STOCKS.PRICE.NYSE.*BM Thanks for the clarification on union v intersection. So yes, intersection sounds about right, sorry for my previous confusion :) > LDAP based authorization support > > > Key: AMQ-826 > URL: https://issues.apache.org/activemq/browse/AMQ-826 > Project: ActiveMQ > Issue Type: Improvement >Reporter: james strachan > Assigned To: Nikola Goran Cutura > Attachments: LdapAuth.zip > > > Patch kindly added by ngcutura - discussion thread... > http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-826) LDAP based authorization support
[ https://issues.apache.org/activemq/browse/AMQ-826?page=comments#action_37281 ] james strachan commented on AMQ-826: 1. union is probably more appropriate. If the user tries to send to 5 destinations and one of them is not available, it should generate an error and fail rather than silently just sending to the ones it can etc 2. Yes. > acts as a recursive match to any depth. http://incubator.apache.org/activemq/wildcards.html > LDAP based authorization support > > > Key: AMQ-826 > URL: https://issues.apache.org/activemq/browse/AMQ-826 > Project: ActiveMQ > Issue Type: Improvement >Reporter: james strachan > Assigned To: Nikola Goran Cutura > Attachments: LdapAuth.zip > > > Patch kindly added by ngcutura - discussion thread... > http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-992) MySQL doesn't honor lock in JDBC Master Slave configuration?
[ https://issues.apache.org/activemq/browse/AMQ-992?page=comments#action_37280 ] james strachan commented on AMQ-992: I wonder if some SQL statement like the following works for MysQL... LOCK TABLE foo IN ACCESS EXCLUSIVE MODE; > MySQL doesn't honor lock in JDBC Master Slave configuration? > > > Key: AMQ-992 > URL: https://issues.apache.org/activemq/browse/AMQ-992 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.1 > Environment: RHEL 4 > MySQL 4.x, 5.x > mysql-ab_jdbc_driver >Reporter: Steven Lotito > Attachments: mysql_obtain_lock.txt > > > I have been attempting to get the new 4.1 JDBC Master Slave configuration > working with MySQL. > The log from the first broker to start up states: > 2006-10-18 09:35:08,558 [main ] INFO DefaultDatabaseLocker > - Attempting to acquire the exclusive lock to become the Master broker > 2006-10-18 09:35:08,559 [main ] INFO DefaultDatabaseLocker > - Becoming the master on dataSource: [EMAIL PROTECTED] > The 2nd broker to start up has an identical message and both brokers listen > for connections. > The 2nd broker should be waiting for the lock and NOT accepting connections, > if I understand http://www.activemq.org/site/jdbc-master-slave.html > correctly... > Oracle exhibits the expected behavior: > When running the exact same configuration (except using an Oracle > datasource), the first broker has the same log message as above, while the > 2nd broker halts at the "Attempting to acquire the exclusive lock to become > the Master broker" message until I fail the master. Then it becomes the > master. > Is this a known issue? I was able to replicate it using both MySql 4 and 5 > (trying both the MySQL Connector/J 3.1 and MySQL Connector/J 5.0 drivers) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-931) NMS test fails against trunk version of server
[ https://issues.apache.org/activemq/browse/AMQ-931?page=all ] james strachan resolved AMQ-931. Fix Version/s: 4.1 Resolution: Fixed Things are working fine for me with the current trunk. I wonder if the bug has been fixed (we've been applying quite a few patches to NMS recently). Let us know if you still have problems and we can reopen this issue > NMS test fails against trunk version of server > -- > > Key: AMQ-931 > URL: https://issues.apache.org/activemq/browse/AMQ-931 > Project: ActiveMQ > Issue Type: Bug > Components: NMS (C# client) > Environment: Gentoo Linux EM64T, Mono 1.1.17, AMQ SVN >Reporter: Adam Wendt > Fix For: 4.1 > > > When running the test case against svn version of broker server the server > generates this error: > Exception in thread "ActiveMQ Transport: tcp:///127.0.0.1:36117" > java.lang.IllegalArgumentException: Invalid version: 0, could not load > org.apache.activemq.openwire.v0.MarshallerFactory > at > org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:328) > at > org.apache.activemq.openwire.OpenWireFormat.renegotiateWireFormat(OpenWireFormat.java:568) > at > org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:110) > at > org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:123) > at > org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:88) > at > org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:129) > at java.lang.Thread.run(Thread.java:595) > The C# test runs fine against 4.0.1 or 4.0.2RC3 server -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-992) MySQL doesn't honor lock in JDBC Master Slave configuration?
[ https://issues.apache.org/activemq/browse/AMQ-992?page=comments#action_37278 ] james strachan commented on AMQ-992: You're the first one to notice this issue. I wonder how else to create an exclusive table lock in MySQL. I wonder if they are even supported? It might be we need to use different SQL for MySQL maybe? > MySQL doesn't honor lock in JDBC Master Slave configuration? > > > Key: AMQ-992 > URL: https://issues.apache.org/activemq/browse/AMQ-992 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.1 > Environment: RHEL 4 > MySQL 4.x, 5.x > mysql-ab_jdbc_driver >Reporter: Steven Lotito > Attachments: mysql_obtain_lock.txt > > > I have been attempting to get the new 4.1 JDBC Master Slave configuration > working with MySQL. > The log from the first broker to start up states: > 2006-10-18 09:35:08,558 [main ] INFO DefaultDatabaseLocker > - Attempting to acquire the exclusive lock to become the Master broker > 2006-10-18 09:35:08,559 [main ] INFO DefaultDatabaseLocker > - Becoming the master on dataSource: [EMAIL PROTECTED] > The 2nd broker to start up has an identical message and both brokers listen > for connections. > The 2nd broker should be waiting for the lock and NOT accepting connections, > if I understand http://www.activemq.org/site/jdbc-master-slave.html > correctly... > Oracle exhibits the expected behavior: > When running the exact same configuration (except using an Oracle > datasource), the first broker has the same log message as above, while the > 2nd broker halts at the "Attempting to acquire the exclusive lock to become > the Master broker" message until I fail the master. Then it becomes the > master. > Is this a known issue? I was able to replicate it using both MySql 4 and 5 > (trying both the MySQL Connector/J 3.1 and MySQL Connector/J 5.0 drivers) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-991) ActiveMQ 4.0.1 crashes when using client from trunk.
[
https://issues.apache.org/activemq/browse/AMQ-991?page=comments#action_37263 ]
james strachan commented on AMQ-991:
There was a gremlin in trunk for a little while that made NMS not work with
older ActiveMQ brokers. Though AFAIK this should be resolved now.
> ActiveMQ 4.0.1 crashes when using client from trunk.
>
>
> Key: AMQ-991
> URL: https://issues.apache.org/activemq/browse/AMQ-991
> Project: ActiveMQ
> Issue Type: Bug
> Components: NMS (C# client)
>Reporter: Pawel Niewiadomski
>
> I tried today to use C# client from trunk agains ActiveMQ 4.0.1 server. This
> caused server to die totally. Following error message was shown by server:
> {noformat}
> Exception in thread "ActiveMQ Transport: tcp:///127.0.0.1:1699"
> java.lang.Illega
> lArgumentException: Invalid version: 2, could not load
> org.apache.activemq.openwire.v2.MarshallerFactory
> at
> org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:329)
> at
> org.apache.activemq.openwire.OpenWireFormat.renegociatWireFormat(OpenWireFormat.java:569)
> at
> org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:100)
> at
> org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122)
> at
> org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:87)
> at
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:143)
> at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.activemq.openwire.v2.MarshallerFactory
> at
> org.apache.activemq.util.ClassLoading.loadClass(ClassLoading.java:104)
> at
> org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:327)
> ... 6 more
> {noformat}
> I then used ActiveMQ 4.0.2 server and it worked. Isn't that client should
> automatically negotiate protocol with server? Why server after this error
> dies totally? (new client connecting were not handled at all, everything
> died).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-998) add support for stomp+ssl
[ https://issues.apache.org/activemq/browse/AMQ-998?page=comments#action_37260 ] james strachan commented on AMQ-998: The implementation and test case is now in trunk; just need to get the test case working and document this feature on the wiki... http://incubator.apache.org/activemq/configuring-transports.html > add support for stomp+ssl > - > > Key: AMQ-998 > URL: https://issues.apache.org/activemq/browse/AMQ-998 > Project: ActiveMQ > Issue Type: New Feature > Components: Transport >Reporter: james strachan > Fix For: 4.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-998) add support for stomp+ssl
add support for stomp+ssl - Key: AMQ-998 URL: https://issues.apache.org/activemq/browse/AMQ-998 Project: ActiveMQ Issue Type: New Feature Components: Transport Reporter: james strachan Fix For: 4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-980) lastImageSubscriptionRecoveryPolicy does not work with wildcards
[
https://issues.apache.org/activemq/browse/AMQ-980?page=comments#action_37248 ]
james strachan commented on AMQ-980:
Ah cool - thanks for the analysis Rob. As soon as we've the '1 thread per
session' change in ActiveMQ.Net we can retest that things are working fine
> lastImageSubscriptionRecoveryPolicy does not work with wildcards
>
>
> Key: AMQ-980
> URL: https://issues.apache.org/activemq/browse/AMQ-980
> Project: ActiveMQ
> Issue Type: Bug
> Components: NMS (C# client)
>Affects Versions: 4.0.2
> Environment: Windows, JDK 1.5
>Reporter: Rob Lugt
> Fix For: 4.1
>
>
> The lastImageSubscriptionRecoveryPolicy does not appear to work with
> wildcards.
> In the following example, a new consumer only receives one message for the
> topics covered by the wildcard instead of receiving one message for each
> topic.
>
> config file:-
>
>
>
>
>
>
> consumer subscription:-
> GetTopic("PRICES.>?consumer.retrocactive=true");
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-980) lastImageSubscriptionRecoveryPolicy does not work with wildcards
[
https://issues.apache.org/activemq/browse/AMQ-980?page=comments#action_37231 ]
james strachan commented on AMQ-980:
BTW I marked this resolved as a 'Cannot Reproduce' for now - if you can figure
out how to reproduce we can reopen it
> lastImageSubscriptionRecoveryPolicy does not work with wildcards
>
>
> Key: AMQ-980
> URL: https://issues.apache.org/activemq/browse/AMQ-980
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 4.0.2
> Environment: Windows, JDK 1.5
>Reporter: Rob Lugt
> Fix For: 4.1
>
>
> The lastImageSubscriptionRecoveryPolicy does not appear to work with
> wildcards.
> In the following example, a new consumer only receives one message for the
> topics covered by the wildcard instead of receiving one message for each
> topic.
>
> config file:-
>
>
>
>
>
>
> consumer subscription:-
> GetTopic("PRICES.>?consumer.retrocactive=true");
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-980) lastImageSubscriptionRecoveryPolicy does not work with wildcards
[ https://issues.apache.org/activemq/browse/AMQ-980?page=all ]
james strachan resolved AMQ-980.
Fix Version/s: 4.1
Resolution: Cannot Reproduce
I've created a JUnit test case to try reproduce the issue. I've added the test
case RetroactiveConsumerTestWithLastImagePolicyWithWildcardTest (in the
activemq-core module)
which creates a broker without persistence, sends 20 messages to different
topics, then creates a retroactive consumer using a wildcard and it receives
all 20 messages on each topic.
Am wondering how to reproduce your issue - any ideas? Does this issue only show
itself in ActiveMQ.Net?
> lastImageSubscriptionRecoveryPolicy does not work with wildcards
>
>
> Key: AMQ-980
> URL: https://issues.apache.org/activemq/browse/AMQ-980
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 4.0.2
> Environment: Windows, JDK 1.5
>Reporter: Rob Lugt
> Fix For: 4.1
>
>
> The lastImageSubscriptionRecoveryPolicy does not appear to work with
> wildcards.
> In the following example, a new consumer only receives one message for the
> topics covered by the wildcard instead of receiving one message for each
> topic.
>
> config file:-
>
>
>
>
>
>
> consumer subscription:-
> GetTopic("PRICES.>?consumer.retrocactive=true");
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-951) NMS requires the concept of a Connection Exception event to mirror rhe ExceptionListener in JMS.
[ https://issues.apache.org/activemq/browse/AMQ-951?page=all ] james strachan resolved AMQ-951. Fix Version/s: 4.1 Resolution: Fixed I've added an ExceptionListener event on the IConnection which should serve a similar purpose to ExceptionListener in JMS. Does this seem an OK solution to you? > NMS requires the concept of a Connection Exception event to mirror rhe > ExceptionListener in JMS. > > > Key: AMQ-951 > URL: https://issues.apache.org/activemq/browse/AMQ-951 > Project: ActiveMQ > Issue Type: New Feature > Components: NMS (C# client) >Affects Versions: incubation >Reporter: Rob Lugt > Assigned To: Rob Lugt > Fix For: 4.1 > > > Applications using NMS have no way of discovering problems with the > connection. JMS allws a ExceptionListener to be registered with a > Connection, NMS should provide a similar concept. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-952) .Net Client ConnectionFactory requires additional configurable attributes
[ https://issues.apache.org/activemq/browse/AMQ-952?page=comments#action_37228 ] james strachan commented on AMQ-952: So the only things left for this I think are closeTimeout and connectTimeout. For closeTimeout, we currently are not waiting for a receipt to come back from the broker when we send a ShutdownInfo - which seems fine to me. The Java client will do a timeout based request-response up to the closeTimeout - am not sure how useful that is to implement in .Net though. For connectTimeout, in Java we set that as a property on the Socket class when doing a Connect() - I don't see any way to do something similar on .Net. Though the SendTimeout and ReceiveTimeout properties can be set via the URI notation of transport.socket.sendTimeout=1234 etc > .Net Client ConnectionFactory requires additional configurable attributes > - > > Key: AMQ-952 > URL: https://issues.apache.org/activemq/browse/AMQ-952 > Project: ActiveMQ > Issue Type: New Feature > Components: NMS (C# client) >Reporter: Rob Lugt >Priority: Minor > > The Java Client has a rich set of configuration options, which should also be > available on the .Net client. > As a mimimum I believe we need:- > closeTimeout > retroactiveConsumer > Is it also worth considering a connectTimeout property - or should this be > transport specific? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-952) .Net Client ConnectionFactory requires additional configurable attributes
[ https://issues.apache.org/activemq/browse/AMQ-952?page=comments#action_37227 ] james strachan commented on AMQ-952: Incidentally, while looking at the Connection.Dispose(), we no longer call Dispose() on child sessions as they are iDisposable - by the same logic I guess we should no longer call transport.Dispose() too? > .Net Client ConnectionFactory requires additional configurable attributes > - > > Key: AMQ-952 > URL: https://issues.apache.org/activemq/browse/AMQ-952 > Project: ActiveMQ > Issue Type: New Feature > Components: NMS (C# client) >Reporter: Rob Lugt >Priority: Minor > > The Java Client has a rich set of configuration options, which should also be > available on the .Net client. > As a mimimum I believe we need:- > closeTimeout > retroactiveConsumer > Is it also worth considering a connectTimeout property - or should this be > transport specific? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-952) .Net Client ConnectionFactory requires additional configurable attributes
[
https://issues.apache.org/activemq/browse/AMQ-952?page=comments#action_37226 ]
james strachan commented on AMQ-952:
I've added API access to the various consumer related configuration options;
so you can now do things like
ISession session = ...
session.Retroactive = true
session.CreateConsumer()...
etc
Also you should be able to use the URI syntax currently...
new ActiveMQQueue("Foo.BAR?consumer.retroactive=true") etc
> .Net Client ConnectionFactory requires additional configurable attributes
> -
>
> Key: AMQ-952
> URL: https://issues.apache.org/activemq/browse/AMQ-952
> Project: ActiveMQ
> Issue Type: New Feature
> Components: NMS (C# client)
>Reporter: Rob Lugt
>Priority: Minor
>
> The Java Client has a rich set of configuration options, which should also be
> available on the .Net client.
> As a mimimum I believe we need:-
> closeTimeout
> retroactiveConsumer
> Is it also worth considering a connectTimeout property - or should this be
> transport specific?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-966) NMSDestination is null when receiving messages
[ https://issues.apache.org/activemq/browse/AMQ-966?page=all ] james strachan resolved AMQ-966. Fix Version/s: 4.1 Resolution: Fixed yes, it should be the Destination property :) Patch applied with thanks > NMSDestination is null when receiving messages > -- > > Key: AMQ-966 > URL: https://issues.apache.org/activemq/browse/AMQ-966 > Project: ActiveMQ > Issue Type: Bug > Components: NMS (C# client) >Affects Versions: 4.0.2 >Reporter: Rob Lugt > Fix For: 4.1 > > > The NMSDestination property is null when receiving messages via an > asynchronous listener. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-989) .Net Client: allow specification of wireFormat parameters in broker URI
[ https://issues.apache.org/activemq/browse/AMQ-989?page=all ] james strachan resolved AMQ-989. Fix Version/s: 4.1 Resolution: Fixed I think I've faithfully applied your patch for this issue - many thanks. This issue seemed to cut across a few other issues to do with logging; could you double check I"ve applied your patch correctly please? > .Net Client: allow specification of wireFormat parameters in broker URI > --- > > Key: AMQ-989 > URL: https://issues.apache.org/activemq/browse/AMQ-989 > Project: ActiveMQ > Issue Type: Improvement > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Windows >Reporter: Rob Lugt > Assigned To: james strachan > Fix For: 4.1 > > Attachments: amq989.txt > > > Update required to TcpTransportFactory to accept wireFormat connection > parameters in the connection URI. This is the only means for .Net client > applications to set properties such as tight/loose encoding. > Please apply the attached patch. > Best Regards > Rob Lugt -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-971) NMSTimestamp returning LocalTime instead of UTC
[ https://issues.apache.org/activemq/browse/AMQ-971?page=all ] james strachan reassigned AMQ-971: -- Assignee: Hiram Chirino > NMSTimestamp returning LocalTime instead of UTC > --- > > Key: AMQ-971 > URL: https://issues.apache.org/activemq/browse/AMQ-971 > Project: ActiveMQ > Issue Type: Improvement > Components: NMS (C# client) >Affects Versions: incubation > Environment: Windows >Reporter: Rob Lugt > Assigned To: Hiram Chirino >Priority: Minor > > The NMSTimestamp property has been changed from long to DateTime - which is a > good thing. However, the DateTime is currently being adjusted to localtime > before being returned to the client - which is probably not ideal. The > DateTime struct does not contain timezone information, therefore the > programmer has to make some assumption about what timezone the time is > expressed in. A UTC time is more in-keeping with the JMS specification - > which specifies that Timestamp is a normal Java time i.e. expressed in GMT. > This article from Microsoft also suggests using UTC as a common time where > possible: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/datetimecode.asp -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-972) NMS Client does not set NMSTimestamp
[ https://issues.apache.org/activemq/browse/AMQ-972?page=all ] james strachan resolved AMQ-972. Fix Version/s: 4.1 Resolution: Fixed Looks great to me - patch applied with thanks! > NMS Client does not set NMSTimestamp > > > Key: AMQ-972 > URL: https://issues.apache.org/activemq/browse/AMQ-972 > Project: ActiveMQ > Issue Type: Bug > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Windows client >Reporter: Rob Lugt > Assigned To: james strachan > Fix For: 4.1 > > Attachments: amq972-patch.txt, DateUtils.cs > > > MessageProducer.cs fails to set the Timestamp property on a message > regardless if the DisableMessageTimestamp feature property is set or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-985) TcpTransportFactory adds LoggingTransport after WireFormatNegotiator
[ https://issues.apache.org/activemq/browse/AMQ-985?page=all ]
james strachan resolved AMQ-985.
Fix Version/s: 4.1
Resolution: Fixed
Patch applied - thanks again :)
> TcpTransportFactory adds LoggingTransport after WireFormatNegotiator
>
>
> Key: AMQ-985
> URL: https://issues.apache.org/activemq/browse/AMQ-985
> Project: ActiveMQ
> Issue Type: Improvement
> Components: NMS (C# client)
>Affects Versions: 4.0.2
> Environment: Windows
>Reporter: Rob Lugt
> Assigned To: james strachan
>Priority: Minor
> Fix For: 4.1
>
>
> The TcpTransportFactory class will insert a LoggingTransport filter into the
> transport chain if the useLogging=true attribute is set. However, it
> currently adds the LoggingTransport after the WireFormatNegotiator, which
> means that the wire format negotiation packets are excluded from the log
> output. This can be simply rectified by adding the LoggingTransport
> immediately after the TcpTransport. e.g.
> public ITransport CreateTransport(Uri location)
> {
> // Console.WriteLine("Opening socket to: " + host + " on port: "
> + port);
> Socket socket = Connect(location.Host, location.Port);
> TcpTransport tcpTransport = new TcpTransport(socket);
> ITransport rc = tcpTransport;
> // At present the URI is parsed for options by the
> ConnectionFactory
> if (UseLogging)
> {
> rc = new LoggingTransport(rc);
> }
> rc = new WireFormatNegotiator(rc, tcpTransport.Wireformat);
> ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-974) .Net client needs centralised trace facility
[ https://issues.apache.org/activemq/browse/AMQ-974?page=all ] james strachan resolved AMQ-974. Resolution: Fixed Patch applied, thanks again! > .Net client needs centralised trace facility > > > Key: AMQ-974 > URL: https://issues.apache.org/activemq/browse/AMQ-974 > Project: ActiveMQ > Issue Type: New Feature > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Windows >Reporter: Rob Lugt > Assigned To: james strachan > Fix For: 4.1 > > Attachments: amq974-patch.txt, ITrace.cs, Tracer.cs > > > There are several classes within activemq-dotnet which need to write > log/trace information. This data is currently written to an ad-hoc mixture > of the Console and System.Diagnostics.Trace. > Neither of these detinations are suitable because System.Diagnostics.Trace is > not fully supported in the .Net compact framework and the Console is > unsuitable for severl reasons - not least of which is that output is > discarded in a Windows (i.e. non-console) application. > There are two possible solutions to this problem > 1) adopt log4net as the strategic logging/tracing platform > 2) write our own Tracing interface which can be controlled at run-time to > make use of any logging mechanism. > Log4net is an attractive proposition because it is powerful, full-featured, > reliable and is also an Apache incubator project. However, there is a strong > desire to keep activemq-dotnet as clear as possible from any external > dependencies. So far this has been successfull and as there is an > alternative solution perhaps we should not create a dependency now. > Creating a custom Tracing interface is attractive because it is stand-alone > and allows the client application to plug-in whichever trace mechanism it > requires. There don't seem to be many down sides to this solution, so I'll > post a sample impementation shortly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-988) Thread synchronization error in TcpTransport
[ https://issues.apache.org/activemq/browse/AMQ-988?page=all ] james strachan resolved AMQ-988. Fix Version/s: 4.1 Resolution: Fixed Great catch Rob! Patch applied with huge thanks > Thread synchronization error in TcpTransport > > > Key: AMQ-988 > URL: https://issues.apache.org/activemq/browse/AMQ-988 > Project: ActiveMQ > Issue Type: Bug > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Windows >Reporter: Rob Lugt > Assigned To: james strachan > Fix For: 4.1 > > > I have a problem where my C# client application crashes when placed under > load. It's taken a while to get to the bottom of it, but I believe I have > identified the problem and luckily there's a simple solution. > The AMQ .Net client uses a common pattern where a full-duplex TCP/IP > connection is established with the broker, and the client uses two threads to > concurrently read and write data to/from the underlying socket - one thread > reading from a Reader object and the other writing to a Writer object. > The TcpTransport.Start() method contains the following:- > NetworkStream networkStream = new NetworkStream(socket); > socketWriter = new OpenWireBinaryWriter(networkStream); > socketReader = new OpenWireBinaryReader(networkStream); > This pattern is explicitly allowed in Java and Win32 applications, but .Net > is a little vague on the subject. The Microsoft documentation [1] suggests > use of the asynchronous read/write calls for multithreaded applications, but > that would significantly complicate the C# client which relies on blocking > stream behaviour. On the same doc page > Microsoft does specifiy that the Socket class is thread-safe, which I take to > mean that concurrent read/write calls are permitted, however the same is not > true of NetworkStream [2]. > Perhaps it would be reasonable to expect NetworkStream to have no internal > state other than the Socket it contains, but apparently this is not the case > because I've identified that it is a corrupt NetworkStream which is causing > my application to crash under load. After some experimentation and a fair > amount of load testing, I think the solution is a simple change to the > TcpTransport.start() method to use a separate NetworkStream for input and > output operations. e.g. :- > NetworkStream inputNetworkStream = new NetworkStream(socket); > NetworkStream outputNetworkStream = new NetworkStream(socket); > socketWriter = new OpenWireBinaryWriter(inputNetworkStream); > socketReader = new OpenWireBinaryReader(outputNetworkStream); > This works for me and my test client has now been running for 16 hours > without crashing (before it would rarely last longer than 10 minutes). > Regards > Rob Lugt > [1] http://msdn2.microsoft.com/en-us/library/system.net.sockets.socket.aspx > [2] > http://msdn2.microsoft.com/en-us/library/system.net.sockets.networkstream.aspx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-987) suprious exception message when using message streams...
suprious exception message when using message streams... Key: AMQ-987 URL: https://issues.apache.org/activemq/browse/AMQ-987 Project: ActiveMQ Issue Type: Bug Components: Broker Reporter: james strachan Jerome Banks reported this... Oct 17, 2006 11:39:03 AM org.apache.activemq.broker.region.QueueSubscriptionassignGroupToMe WARNING: Failed to set boolean header: * javax.jms.MessageNotWriteableException*: Message body is read-only * javax.jms.MessageNotWriteableException*: Message body is read-only at org.apache.activemq.command.ActiveMQMessage.checkReadOnlyBody(* ActiveMQMessage.java:573*) at org.apache.activemq.command.ActiveMQBytesMessage.initializeWriting(* ActiveMQBytesMessage.java:669*) at org.apache.activemq.command.ActiveMQBytesMessage.setObjectProperty(* ActiveMQBytesMessage.java:736*) at org.apache.activemq.command.ActiveMQMessage.setBooleanProperty(* ActiveMQMessage.java:533*) at org.apache.activemq.broker.region.QueueSubscription.assignGroupToMe(* QueueSubscription.java:137*) at org.apache.activemq.broker.region.QueueSubscription.canDispatch(* QueueSubscription.java:103*) at org.apache.activemq.broker.region.PrefetchSubscription.dispatch(* PrefetchSubscription.java:293*) at org.apache.activemq.broker.region.QueueSubscription.dispatch(* QueueSubscription.java:175*) at org.apache.activemq.broker.region.PrefetchSubscription.add(* PrefetchSubscription.java:64*) at org.apache.activemq.broker.region.Queue.addSubscription(*Queue.java:163*) at org.apache.activemq.broker.region.AbstractRegion.addConsumer(* AbstractRegion.java:189*) at org.apache.activemq.broker.region.RegionBroker.addConsumer(* RegionBroker.java:308*) at org.apache.activemq.broker.BrokerFilter.addConsumer(*BrokerFilter.java:77 *) at org.apache.activemq.advisory.AdvisoryBroker.addConsumer(* AdvisoryBroker.java:77*) at org.apache.activemq.broker.MutableBrokerFilter.addConsumer(* MutableBrokerFilter.java:91*) at org.apache.activemq.broker.BrokerFilter.addConsumer(*BrokerFilter.java:77 *) at org.apache.activemq.broker.MutableBrokerFilter.addConsumer(* MutableBrokerFilter.java:91*) at org.apache.activemq.broker.AbstractConnection.processAddConsumer(* AbstractConnection.java:457*) at org.apache.activemq.command.ConsumerInfo.visit(*ConsumerInfo.java:295*) at org.apache.activemq.broker.AbstractConnection.service(* AbstractConnection.java:226*) at org.apache.activemq.broker.TransportConnection$1.onCommand(* TransportConnection.java:62*) at org.apache.activemq.transport.ResponseCorrelator.onCommand(* ResponseCorrelator.java:91*) at org.apache.activemq.transport.TransportFilter.onCommand(* TransportFilter.java:63*) at org.apache.activemq.transport.vm.VMTransport.oneway(*VMTransport.java:76* ) at org.apache.activemq.transport.MutexTransport.oneway(*MutexTransport.java :44*) at org.apache.activemq.transport.ResponseCorrelator.asyncRequest(* ResponseCorrelator.java:66*) at org.apache.activemq.transport.ResponseCorrelator.request(* ResponseCorrelator.java:71*) at org.apache.activemq.ActiveMQConnection.syncSendPacket(* ActiveMQConnection.java:1137*) at org.apache.activemq.ActiveMQInputStream.(*ActiveMQInputStream.java :112*) at org.apache.activemq.ActiveMQConnection.doCreateInputStream(* ActiveMQConnection.java:1681*) at org.apache.activemq.ActiveMQConnection.createInputStream(* ActiveMQConnection.java:1663*) at org.apache.activemq.ActiveMQConnection.createInputStream(* ActiveMQConnection.java:1659*) at org.apache.activemq.ActiveMQConnection.createInputStre -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-973) .Net client sends message acknowledgements as synchronous requests instead of asynchronous oneWay packets
[ https://issues.apache.org/activemq/browse/AMQ-973?page=all ] james strachan resolved AMQ-973. Fix Version/s: 4.1 Resolution: Fixed Patch applied - many thanks! > .Net client sends message acknowledgements as synchronous requests instead of > asynchronous oneWay packets > - > > Key: AMQ-973 > URL: https://issues.apache.org/activemq/browse/AMQ-973 > Project: ActiveMQ > Issue Type: Bug > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Windows >Reporter: Rob Lugt > Assigned To: james strachan > Fix For: 4.1 > > Attachments: amq973-patch.txt > > > The Java client sends message acknowledgements as one-way communications, but > the NMS client currently sends these as synchronous requests. This is > impacting performance and is (I believe) unnecessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-973) .Net client sends message acknowledgements as synchronous requests instead of asynchronous oneWay packets
[ https://issues.apache.org/activemq/browse/AMQ-973?page=all ] james strachan reassigned AMQ-973: -- Assignee: james strachan (was: Rob Lugt) > .Net client sends message acknowledgements as synchronous requests instead of > asynchronous oneWay packets > - > > Key: AMQ-973 > URL: https://issues.apache.org/activemq/browse/AMQ-973 > Project: ActiveMQ > Issue Type: Bug > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Windows >Reporter: Rob Lugt > Assigned To: james strachan > Attachments: amq973-patch.txt > > > The Java client sends message acknowledgements as one-way communications, but > the NMS client currently sends these as synchronous requests. This is > impacting performance and is (I believe) unnecessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-974) .Net client needs centralised trace facility
[ https://issues.apache.org/activemq/browse/AMQ-974?page=all ] james strachan resolved AMQ-974. Fix Version/s: 4.1 Resolution: Fixed Patch applied - many thanks! > .Net client needs centralised trace facility > > > Key: AMQ-974 > URL: https://issues.apache.org/activemq/browse/AMQ-974 > Project: ActiveMQ > Issue Type: New Feature > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Windows >Reporter: Rob Lugt > Assigned To: james strachan > Fix For: 4.1 > > Attachments: amq974-patch.txt, ITrace.cs, Tracer.cs > > > There are several classes within activemq-dotnet which need to write > log/trace information. This data is currently written to an ad-hoc mixture > of the Console and System.Diagnostics.Trace. > Neither of these detinations are suitable because System.Diagnostics.Trace is > not fully supported in the .Net compact framework and the Console is > unsuitable for severl reasons - not least of which is that output is > discarded in a Windows (i.e. non-console) application. > There are two possible solutions to this problem > 1) adopt log4net as the strategic logging/tracing platform > 2) write our own Tracing interface which can be controlled at run-time to > make use of any logging mechanism. > Log4net is an attractive proposition because it is powerful, full-featured, > reliable and is also an Apache incubator project. However, there is a strong > desire to keep activemq-dotnet as clear as possible from any external > dependencies. So far this has been successfull and as there is an > alternative solution perhaps we should not create a dependency now. > Creating a custom Tracing interface is attractive because it is stand-alone > and allows the client application to plug-in whichever trace mechanism it > requires. There don't seem to be many down sides to this solution, so I'll > post a sample impementation shortly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-974) .Net client needs centralised trace facility
[ https://issues.apache.org/activemq/browse/AMQ-974?page=all ] james strachan reassigned AMQ-974: -- Assignee: james strachan > .Net client needs centralised trace facility > > > Key: AMQ-974 > URL: https://issues.apache.org/activemq/browse/AMQ-974 > Project: ActiveMQ > Issue Type: New Feature > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Windows >Reporter: Rob Lugt > Assigned To: james strachan > Attachments: amq974-patch.txt, ITrace.cs, Tracer.cs > > > There are several classes within activemq-dotnet which need to write > log/trace information. This data is currently written to an ad-hoc mixture > of the Console and System.Diagnostics.Trace. > Neither of these detinations are suitable because System.Diagnostics.Trace is > not fully supported in the .Net compact framework and the Console is > unsuitable for severl reasons - not least of which is that output is > discarded in a Windows (i.e. non-console) application. > There are two possible solutions to this problem > 1) adopt log4net as the strategic logging/tracing platform > 2) write our own Tracing interface which can be controlled at run-time to > make use of any logging mechanism. > Log4net is an attractive proposition because it is powerful, full-featured, > reliable and is also an Apache incubator project. However, there is a strong > desire to keep activemq-dotnet as clear as possible from any external > dependencies. So far this has been successfull and as there is an > alternative solution perhaps we should not create a dependency now. > Creating a custom Tracing interface is attractive because it is stand-alone > and allows the client application to plug-in whichever trace mechanism it > requires. There don't seem to be many down sides to this solution, so I'll > post a sample impementation shortly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-826) LDAP based authorization support
[ https://issues.apache.org/activemq/browse/AMQ-826?page=comments#action_37159 ] james strachan commented on AMQ-826: Hi Nikola Don't worry about the maven stuff, I can try help with that - its mostly to get a unit test running that boots up an embedded ApacheDS, loads it with the necessary test data, then runs the test case. > LDAP based authorization support > > > Key: AMQ-826 > URL: https://issues.apache.org/activemq/browse/AMQ-826 > Project: ActiveMQ > Issue Type: Improvement >Reporter: james strachan > Assigned To: Nikola Goran Cutura > Attachments: LdapAuth.zip > > > Patch kindly added by ngcutura - discussion thread... > http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-947) Improve .Net client to accept URI configuration parameters for connection, consumer and producer
[ https://issues.apache.org/activemq/browse/AMQ-947?page=all ] james strachan resolved AMQ-947. Fix Version/s: 4.1 Resolution: Fixed Patch applied Rob - many thanks! > Improve .Net client to accept URI configuration parameters for connection, > consumer and producer > > > Key: AMQ-947 > URL: https://issues.apache.org/activemq/browse/AMQ-947 > Project: ActiveMQ > Issue Type: New Feature > Components: NMS (C# client) >Affects Versions: 4.x >Reporter: Rob Lugt > Assigned To: Rob Lugt > Fix For: 4.1 > > Attachments: AMQ-947.diff > > > The Java client accepts optional parameters on broker and destination URIs, > which allows client programs to configure the client using the standard JMS > interface. The .Net client does not currently support parameters (it > silently ignores them), but this is not made clear in the documentation. > URI parameters are a powerful mechanism which should ideally be rolled out to > all clients, but as this is client specific this Jira covers the .Net client > only. > Idelly the same URI configuration parameters should be used for both the Java > and .Net clients. The Java mechanism is based on introspection, so the .Net > client should ideally use a similar mechanism. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-618) create a file based servicemix-file service engine with nice support for URIs
create a file based servicemix-file service engine with nice support for URIs - Key: SM-618 URL: https://issues.apache.org/activemq/browse/SM-618 Project: ServiceMix Issue Type: New Feature Components: servicemix-components Reporter: james strachan Assigned To: james strachan Fix For: 3.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-617) make a new base class, DefaultComponent which combines the Component and Lifecycle functionality and can deal with the SpringComponent behaviour, dealing with statically conf
[ https://issues.apache.org/activemq/browse/SM-617?page=all ] james strachan resolved SM-617. --- Resolution: Fixed for an example of this base class in action, see the new refactored Saxon component in servicemix-saxon > make a new base class, DefaultComponent which combines the Component and > Lifecycle functionality and can deal with the SpringComponent behaviour, > dealing with statically configured endpoint POJOs > --- > > Key: SM-617 > URL: https://issues.apache.org/activemq/browse/SM-617 > Project: ServiceMix > Issue Type: Improvement >Reporter: james strachan > Assigned To: james strachan > Fix For: 3.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work stopped: (SM-617) make a new base class, DefaultComponent which combines the Component and Lifecycle functionality and can deal with the SpringComponent behaviour, dealing with statically
[ https://issues.apache.org/activemq/browse/SM-617?page=all ] Work on SM-617 stopped by james strachan. > make a new base class, DefaultComponent which combines the Component and > Lifecycle functionality and can deal with the SpringComponent behaviour, > dealing with statically configured endpoint POJOs > --- > > Key: SM-617 > URL: https://issues.apache.org/activemq/browse/SM-617 > Project: ServiceMix > Issue Type: Improvement >Reporter: james strachan > Assigned To: james strachan > Fix For: 3.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (SM-617) make a new base class, DefaultComponent which combines the Component and Lifecycle functionality and can deal with the SpringComponent behaviour, dealing with statically
[ https://issues.apache.org/activemq/browse/SM-617?page=all ] Work on SM-617 started by james strachan. > make a new base class, DefaultComponent which combines the Component and > Lifecycle functionality and can deal with the SpringComponent behaviour, > dealing with statically configured endpoint POJOs > --- > > Key: SM-617 > URL: https://issues.apache.org/activemq/browse/SM-617 > Project: ServiceMix > Issue Type: Improvement >Reporter: james strachan > Assigned To: james strachan > Fix For: 3.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-617) make a new base class, DefaultComponent which combines the Component and Lifecycle functionality and can deal with the SpringComponent behaviour, dealing with statically confi
make a new base class, DefaultComponent which combines the Component and Lifecycle functionality and can deal with the SpringComponent behaviour, dealing with statically configured endpoint POJOs --- Key: SM-617 URL: https://issues.apache.org/activemq/browse/SM-617 Project: ServiceMix Issue Type: Improvement Reporter: james strachan Assigned To: james strachan Fix For: 3.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-947) Imporve .Net client to accept URI configuration parameters for connection, consumer and producer
[ https://issues.apache.org/activemq/browse/AMQ-947?page=comments#action_37047 ] james strachan commented on AMQ-947: Who-hoo!! BTW you should now have sufficient JIRA karma to assign issues to yourself or edit issues if you like etc > Imporve .Net client to accept URI configuration parameters for connection, > consumer and producer > > > Key: AMQ-947 > URL: https://issues.apache.org/activemq/browse/AMQ-947 > Project: ActiveMQ > Issue Type: New Feature > Components: NMS (C# client) >Affects Versions: 4.x >Reporter: Rob Lugt > > The Java client accepts optional parameters on broker and destination URIs, > which allows client programs to configure the client using the standard JMS > interface. The .Net client does not currently support parameters (it > silently ignores them), but this is not made clear in the documentation. > URI parameters are a powerful mechanism which should ideally be rolled out to > all clients, but as this is client specific this Jira covers the .Net client > only. > Idelly the same URI configuration parameters should be used for both the Java > and .Net clients. The Java mechanism is based on introspection, so the .Net > client should ideally use a similar mechanism. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-947) Imporve .Net client to accept URI configuration parameters for connection, consumer and producer
[ https://issues.apache.org/activemq/browse/AMQ-947?page=comments#action_37044 ] james strachan commented on AMQ-947: Sounds fine with me. The main thing holding us back on this is figuring out the right .Net way to do this... http://incubator.apache.org/activemq/maven/activemq-core/xref/org/apache/activemq/util/IntrospectionSupport.html I wonder any chance you could try create an introspection/reflection helper class something like that so we could wire in a similar introspection URI handler to the connection / consumer / transport / socket stuff etc? > Imporve .Net client to accept URI configuration parameters for connection, > consumer and producer > > > Key: AMQ-947 > URL: https://issues.apache.org/activemq/browse/AMQ-947 > Project: ActiveMQ > Issue Type: New Feature > Components: NMS (C# client) >Affects Versions: 4.x >Reporter: Rob Lugt > > The Java client accepts optional parameters on broker and destination URIs, > which allows client programs to configure the client using the standard JMS > interface. The .Net client does not currently support parameters (it > silently ignores them), but this is not made clear in the documentation. > URI parameters are a powerful mechanism which should ideally be rolled out to > all clients, but as this is client specific this Jira covers the .Net client > only. > Idelly the same URI configuration parameters should be used for both the Java > and .Net clients. The Java mechanism is based on introspection, so the .Net > client should ideally use a similar mechanism. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-940) JMSXUserId not set when using a JAAS login module
[ https://issues.apache.org/activemq/browse/AMQ-940?page=all ] james strachan resolved AMQ-940. Resolution: Fixed Patch applied - many thanks! > JMSXUserId not set when using a JAAS login module > - > > Key: AMQ-940 > URL: https://issues.apache.org/activemq/browse/AMQ-940 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.1 > Environment: Linux, JDK 1.6 >Reporter: Kelly Campbell > Assigned To: james strachan >Priority: Minor > Fix For: 4.1 > > Attachments: JMSXUserID-jaas.patch > > > The JMSXUserID field is not set when using a JAAS login module. > A unit test that fails and a bugfix are attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-921) When recovering messages on startup - execution of Store.getMessage is executed as many times as many subscribers to this destination there are
[ https://issues.apache.org/activemq/browse/AMQ-921?page=all ] james strachan reassigned AMQ-921: -- Assignee: Hiram Chirino > When recovering messages on startup - execution of Store.getMessage is > executed as many times as many subscribers to this destination there are > --- > > Key: AMQ-921 > URL: https://issues.apache.org/activemq/browse/AMQ-921 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 4.1 > Environment: Any >Reporter: Nikolai Penkov > Assigned To: Hiram Chirino >Priority: Minor > > Fix of issue https://issues.apache.org/activemq/browse/AMQ-878 (when > recovering gigantic queues) come to a new performance problem. - When > recovering messages on startup - execution of Store.getMessage (from > IndirectMessageRefference.incrementReferenceCount) is executed as many times > as many subscribers to this destination there are. E.g. > 1. Start of broker with a queue A with a lot of messages > 2. Queue is recovered from database by creation of IndirectMessageRefferences > 3. 2 Subscribers connect to recovered queue with two different message > selectors. > 4. Messages are loaded from database > (IndirectMessageRefference.incrementReferenceCount -> > destinationStore.getMessage) twice - for 2 subscribers... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-916) A doc file explaining some things I learned about the comm system while working on my patch
[ https://issues.apache.org/activemq/browse/AMQ-916?page=comments#action_37023 ] james strachan commented on AMQ-916: Great stuff Sepand. I wonder how about adding it directly to the wiki? e.g. on this page... http://incubator.apache.org/activemq/code-overview.html in the developer section... http://incubator.apache.org/activemq/developers.html you can edit any content using the 'edit' link at the bottom of the page (registration with the wiki required). http://incubator.apache.org/activemq/how-do-i-edit-the-website.html > A doc file explaining some things I learned about the comm system while > working on my patch > --- > > Key: AMQ-916 > URL: https://issues.apache.org/activemq/browse/AMQ-916 > Project: ActiveMQ > Issue Type: Improvement > Components: Documentation >Reporter: Sepand Mavandadi >Priority: Minor > Attachments: activemq_comm.html > > > Hope it's useful. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-940) JMSXUserId not set when using a JAAS login module
[ https://issues.apache.org/activemq/browse/AMQ-940?page=all ] james strachan reassigned AMQ-940: -- Assignee: james strachan > JMSXUserId not set when using a JAAS login module > - > > Key: AMQ-940 > URL: https://issues.apache.org/activemq/browse/AMQ-940 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.1 > Environment: Linux, JDK 1.6 >Reporter: Kelly Campbell > Assigned To: james strachan >Priority: Minor > Fix For: 4.1 > > Attachments: JMSXUserID-jaas.patch > > > The JMSXUserID field is not set when using a JAAS login module. > A unit test that fails and a bugfix are attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-888) Licence headers missing from several source files.
[ https://issues.apache.org/activemq/browse/AMQ-888?page=all ]
james strachan resolved AMQ-888.
Resolution: Fixed
Fixed now
> Licence headers missing from several source files.
> --
>
> Key: AMQ-888
> URL: https://issues.apache.org/activemq/browse/AMQ-888
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Hiram Chirino
> Assigned To: james strachan
> Fix For: 4.1, 4.0.2
>
> Attachments: findunlicensed.pl
>
>
> robert burrell donkin reported:
> {quote}
> missing license headers from some of the files i checked at random
> gives me concerns. for example:
> maven-bundle-plugin/src/main/java/org/apache/activemq/maven/BundleMojo.java
> activemq-web-demo worries me: there are a lot of files without license
> headers and some which have them were not created at the ASF (which is
> ok but gives me concerns about the rest).
> i would like to see the issue of licenses in the source tidied up
> before this release ships. i haven't gone through every file but IMO
> this needs to be done.
> {quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-888) Licence headers missing from several source files.
[
https://issues.apache.org/activemq/browse/AMQ-888?page=comments#action_37015 ]
james strachan commented on AMQ-888:
I've fixed up activemq-web-demo and activemq-web-console
in trunk...
http://svn.apache.org/viewvc?view=rev&rev=449694
http://svn.apache.org/viewvc?view=rev&rev=449726
in 4.0 branch...
449731
> Licence headers missing from several source files.
> --
>
> Key: AMQ-888
> URL: https://issues.apache.org/activemq/browse/AMQ-888
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Hiram Chirino
> Assigned To: james strachan
> Fix For: 4.1, 4.0.2
>
> Attachments: findunlicensed.pl
>
>
> robert burrell donkin reported:
> {quote}
> missing license headers from some of the files i checked at random
> gives me concerns. for example:
> maven-bundle-plugin/src/main/java/org/apache/activemq/maven/BundleMojo.java
> activemq-web-demo worries me: there are a lot of files without license
> headers and some which have them were not created at the ASF (which is
> ok but gives me concerns about the rest).
> i would like to see the issue of licenses in the source tidied up
> before this release ships. i haven't gone through every file but IMO
> this needs to be done.
> {quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-917) Discovery Network Connector needs to clean up internal ...
[ https://issues.apache.org/activemq/browse/AMQ-917?page=all ] james strachan resolved AMQ-917. Resolution: Won't Fix Unfortunately your patch breaks 5 test cases. I wonder could you try submitting a different patch to solve your problem? > Discovery Network Connector needs to clean up internal ... > -- > > Key: AMQ-917 > URL: https://issues.apache.org/activemq/browse/AMQ-917 > Project: ActiveMQ > Issue Type: Bug > Components: Connector >Reporter: Sridhar Komandur > Assigned To: james strachan > Attachments: patchfile.txt > > > Consider the following scenario: All the brokers are using a directory > service based discovery agent (for example, DNS). Broker A comes up and tries > to connect to broker B, which is not functional yet. The Discovery Network > Connector at A adds service B to its tracking state "bridges" (list of > connected services) before activating the connection. However, if there is a > failure, the data structure is not cleaned up. When the DNS Discovery Agent > module rescans (DNS) and passes on uri for B into DNC, it simply ignores it > (as its tracking state hasn't been cleaned up upon prior failure). > The attached patch should take care of this issue (in the observed code path) > - test log below: > 2006-09-11 15:36:11,810 [main ] INFO > network.DemandForwardingBridge1 - Starting a network connection between > vm://localhost#0 and tcp://null:0 has been established. > 2006-09-11 15:36:48,158 [main ] DEBUG > network.DemandForwardingBridge1 - stopping localhost bridge to null is > disposed already ? false > 2006-09-11 15:36:48,158 [main ] INFO > ransport.vm.VMTransportFactory1 - Shutting down VM connectors for broker: > localhost > 2006-09-11 15:36:48,159 [main ] INFO > ransport.vm.VMTransportFactory1 - Shutting down VM connectors for broker: > localhost > 2006-09-11 15:36:48,162 [main ] INFO > vemq.broker.TransportConnector1 - Connector vm://localhost Stopped > 2006-09-11 15:36:48,162 [main ] DEBUG > network.DemandForwardingBridge1 - localhost bridge to null stopped > 2006-09-11 15:37:11,246 [main ] WARN > ivemq.network.NetworkConnector1 - Could not start network bridge between: > vm://localhost?network=true and: tcp://komandur-2.desktop.amazon.com:61617 > due to: java.net.ConnectException: Connection refused > java.net.ConnectException: Connection refused -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-930) Session 'consumers' hashtable susceptible to invalid operation exception
[ https://issues.apache.org/activemq/browse/AMQ-930?page=all ]
james strachan resolved AMQ-930.
Fix Version/s: 4.1
Resolution: Fixed
Patch applied to ensure consumers.Values is thread safe to fix the issue
> Session 'consumers' hashtable susceptible to invalid operation exception
>
>
> Key: AMQ-930
> URL: https://issues.apache.org/activemq/browse/AMQ-930
> Project: ActiveMQ
> Issue Type: Bug
> Components: NMS (C# client)
>Affects Versions: incubation
> Environment: Windows XP, NMS API running against a AMQ 4.0.2 provider
>Reporter: Bryan Schmidt
> Fix For: 4.1
>
>
> In a multithreaded environment that reuses the Session object, the following
> exception is thrown:
> Invalid operation exception with the text: "Collection was modified;
> enumeration operation may not execute."
> The exception is thrown when iterating through Session's consumers.Values
> collection. It appears that the lock is being ignored. Spinning up a new
> thread fixes the problem:
> --- Session.cs, DispatchAsyncMessages method ---
> public void DispatchAsyncMessages(object state)
> {
> // lets iterate through each consumer created by this session
> // ensuring that they have all pending messages dispatched
> lock (this)
> {
> // lets ensure that only 1 thread dispatches messages in a
> consumer at once
> foreach (MessageConsumer consumer in consumers.Values)
> {
> ThreadPool.QueueUserWorkItem(new
> WaitCallback(consumer.DispatchAsyncMessages));
> }
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-816) new transport for load balancing client requests across many brokers
[ https://issues.apache.org/activemq/browse/AMQ-816?page=comments#action_36940 ] james strachan commented on AMQ-816: We currently have the fanount transport which does most of this - the main thing to add is the ability to choose the broker to send a command to depending on the context. e.g. when using a transaction, choose a broker and use it for the entire transaction (unless the broker dies). When sending a MessageAck use the broker that sent the original message etc. > new transport for load balancing client requests across many brokers > > > Key: AMQ-816 > URL: https://issues.apache.org/activemq/browse/AMQ-816 > Project: ActiveMQ > Issue Type: Improvement >Reporter: james strachan > Fix For: 4.2 > > > Rather than creating store and forward networks, it might be nice to have a > kind of composite transport where... > * consumers are created on each broker found/discovered. This allows messages > to be sent to any broker and consumed by any consumer > * producers could dynmically choose which broker to send a message to (or > could just pick one broker per session/producer) > this allows for a load balancing layer at the client side which avoids the > need for store/forward networks (which results in more network traffic and > often increases load on the brokers). > So it basically pushes load back to the clients. The downside of this appoach > is that the clients have more connections to brokers - but given the linear > scalability of this, it sounds a great idea to me at least :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-878) JMX Exception: "Destination already created" when recovering gigantic queues from database
[ https://issues.apache.org/activemq/browse/AMQ-878?page=comments#action_36939 ] james strachan commented on AMQ-878: Could you confirm that the original issue is fixed now in 4.1? > JMX Exception: "Destination already created" when recovering gigantic queues > from database > -- > > Key: AMQ-878 > URL: https://issues.apache.org/activemq/browse/AMQ-878 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: incubation > Environment: Embeded broker, Any platform (OS, JDK) - currentlly > embeded in JBoss 4.0.4.GA >Reporter: Nikolai Penkov > Assigned To: Hiram Chirino > Attachments: async-recovery.patch > > > I think this issue is described in Hiram's blog: > http://blogbucket.blogspot.com/2006/05/scaling-to-gigantic-queues-and-topics.html. > E.g. when broker is stopped with a lot of messages in queue. When started - > recovery process is fired (currently on creation of a queue), and if another > subscriber requests queue - it creates a new one, because previous process > hasn't finished. > I think the simpliest solution for that problem is to start recovery process > in another thread with synchronization to sent process(sent process should be > suspended till full recovery is done) and subscriber notification method > (every sunscriber should be notified on recovery of message). > I have attached a patch to activemq-core, which I have tested with my > environment - JBoss 4.0.4.GA with Embeded Broker ActiveMQ trunk release, jdbc > persistence. > I am not a spec. in threads nor in ActiveMQ design, and I am sure that you > will find a more elegant sollution to what I have provided. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-896) allow messages to be copied, moved or deleted using a JMS selector
[ https://issues.apache.org/activemq/browse/AMQ-896?page=all ] james strachan resolved AMQ-896. Resolution: Fixed For details of the new methods see http://svn.apache.org/viewvc/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/jmx/QueueViewMBean.java?revision=436899&view=markup > allow messages to be copied, moved or deleted using a JMS selector > -- > > Key: AMQ-896 > URL: https://issues.apache.org/activemq/browse/AMQ-896 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-837) add a moveTo() method on the QueueViewMBean for doing dead letter queue processing
[ https://issues.apache.org/activemq/browse/AMQ-837?page=all ] james strachan resolved AMQ-837. Fix Version/s: 4.1 Resolution: Fixed See http://svn.apache.org/viewvc/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/jmx/QueueViewMBean.java?revision=436899&view=markup > add a moveTo() method on the QueueViewMBean for doing dead letter queue > processing > -- > > Key: AMQ-837 > URL: https://issues.apache.org/activemq/browse/AMQ-837 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-837) add a moveTo() method on the QueueViewMBean for doing dead letter queue processing
[ https://issues.apache.org/activemq/browse/AMQ-837?page=all ] james strachan updated AMQ-837: --- Component/s: Broker (was: CMS (C++ client)) Assignee: james strachan updated component > add a moveTo() method on the QueueViewMBean for doing dead letter queue > processing > -- > > Key: AMQ-837 > URL: https://issues.apache.org/activemq/browse/AMQ-837 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Reporter: james strachan > Assigned To: james strachan > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-896) allow messages to be copied, moved or deleted using a JMS selector
[ https://issues.apache.org/activemq/browse/AMQ-896?page=comments#action_36855 ] james strachan commented on AMQ-896: Providing helper methods on the Queue or the MBeans > allow messages to be copied, moved or deleted using a JMS selector > -- > > Key: AMQ-896 > URL: https://issues.apache.org/activemq/browse/AMQ-896 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: james strachan > Assigned To: james strachan > Fix For: 4.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-896) allow messages to be copied, moved or deleted using a JMS selector
allow messages to be copied, moved or deleted using a JMS selector -- Key: AMQ-896 URL: https://issues.apache.org/activemq/browse/AMQ-896 Project: ActiveMQ Issue Type: New Feature Components: Broker Reporter: james strachan Assigned To: james strachan Fix For: 4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-877) Patch: refactoring to allow alternative (using different storage interface) Destinations implementations.
[
https://issues.apache.org/activemq/browse/AMQ-877?page=comments#action_36854 ]
james strachan commented on AMQ-877:
I tried to apply this patch to the current trunk and it broke test cases. I
wonder if trunk has moved along a bit since your patch.
Could you try create another patch please and we can try again? Do the test
cases all work for you with your patch applied?
> Patch: refactoring to allow alternative (using different storage interface)
> Destinations implementations.
> -
>
> Key: AMQ-877
> URL: https://issues.apache.org/activemq/browse/AMQ-877
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 4.x
>Reporter: Maxim Fateev
> Assigned To: Rob Davies
> Fix For: 4.1
>
> Attachments: destinationFactoryActiveMQPatch.txt
>
>
> We were looking at alternate message persistence mechanisms that can co-exist
> in current ActiveMQ code base and we are thinking of a mechanism that is
> somewhat incompatible with the current MessageStore and PersistenceAdapter
> APIs. Unfortunately, the current ActiveMQ broker doesn't allow for such a
> change as the PersistenceAdapter and MessageStore interfaces are referenced
> directly by the RegionBroker and by both the Queue and Topic region
> implementations. Therefore, we are proposing a relatively small backwards
> compatible refactoring of the broker code that would eliminate all
> dependencies on the PersistenceAdapter and MessageStore interfaces from those
> classes that do not use them directly. This refactoring would also allow
> creation of a custom Destination implementation that may use an alternative
> persistence mechanism on a destination by destination basis (which is exactly
> what we need to do).
> The main idea behind the refactoring is to replace many references to
> PersistenceAdapter with a new interface: DestinationFactory:
> public abstract class DestinationFactory {
> abstract public Destination createDestination(ConnectionContext
> context, ActiveMQDestination destination, DestinationStatistics
> destinationStatistics) throws Exception;
> abstract public Set getDestinations();
> abstract public SubscriptionInfo[]
> getAllDurableSubscriptions(ActiveMQTopic topic) throws IOException;
> abstract public long getLastMessageBrokerSequenceId() throws
> IOException;
> abstract public void setRegionBroker(RegionBroker regionBroker);
> }
> Note that DestinationFactory doesn't mandate any specific persistence
> mechanism. The classes that would reference it instead of PersistenceAdapter
> are: RegionBroker, AbstractRegion, QueueRegion, and TopicRegion. Also, the
> AbstractRegion.createDestination method would be changed from abstract to an
> implementation that uses DestinationFactory to create a destination.
> BrokerService could be changed to use DestinationFactory if one is
> provided. If none is provided, it will create a DestinationFactory
> implementation that instantiates Queue and Topic using PersistenceAdapter as
> it does currently. Hence, full backwards compatibility will be maintained.
> Patch is attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-877) Patch: refactoring to allow alternative (using different storage interface) Destinations implementations.
[ https://issues.apache.org/activemq/browse/AMQ-877?page=all ]
james strachan reassigned AMQ-877:
--
Assignee: james strachan (was: Rob Davies)
> Patch: refactoring to allow alternative (using different storage interface)
> Destinations implementations.
> -
>
> Key: AMQ-877
> URL: https://issues.apache.org/activemq/browse/AMQ-877
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 4.x
>Reporter: Maxim Fateev
> Assigned To: james strachan
> Fix For: 4.1
>
> Attachments: destinationFactoryActiveMQPatch.txt
>
>
> We were looking at alternate message persistence mechanisms that can co-exist
> in current ActiveMQ code base and we are thinking of a mechanism that is
> somewhat incompatible with the current MessageStore and PersistenceAdapter
> APIs. Unfortunately, the current ActiveMQ broker doesn't allow for such a
> change as the PersistenceAdapter and MessageStore interfaces are referenced
> directly by the RegionBroker and by both the Queue and Topic region
> implementations. Therefore, we are proposing a relatively small backwards
> compatible refactoring of the broker code that would eliminate all
> dependencies on the PersistenceAdapter and MessageStore interfaces from those
> classes that do not use them directly. This refactoring would also allow
> creation of a custom Destination implementation that may use an alternative
> persistence mechanism on a destination by destination basis (which is exactly
> what we need to do).
> The main idea behind the refactoring is to replace many references to
> PersistenceAdapter with a new interface: DestinationFactory:
> public abstract class DestinationFactory {
> abstract public Destination createDestination(ConnectionContext
> context, ActiveMQDestination destination, DestinationStatistics
> destinationStatistics) throws Exception;
> abstract public Set getDestinations();
> abstract public SubscriptionInfo[]
> getAllDurableSubscriptions(ActiveMQTopic topic) throws IOException;
> abstract public long getLastMessageBrokerSequenceId() throws
> IOException;
> abstract public void setRegionBroker(RegionBroker regionBroker);
> }
> Note that DestinationFactory doesn't mandate any specific persistence
> mechanism. The classes that would reference it instead of PersistenceAdapter
> are: RegionBroker, AbstractRegion, QueueRegion, and TopicRegion. Also, the
> AbstractRegion.createDestination method would be changed from abstract to an
> implementation that uses DestinationFactory to create a destination.
> BrokerService could be changed to use DestinationFactory if one is
> provided. If none is provided, it will create a DestinationFactory
> implementation that instantiates Queue and Topic using PersistenceAdapter as
> it does currently. Hence, full backwards compatibility will be maintained.
> Patch is attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-891) InterruptedException handling tweaks
[ https://issues.apache.org/activemq/browse/AMQ-891?page=all ] james strachan reassigned AMQ-891: -- Assignee: Hiram Chirino Do you wanna handle this one - I seem to remember you doing some work on the interupted stuff? > InterruptedException handling tweaks > > > Key: AMQ-891 > URL: https://issues.apache.org/activemq/browse/AMQ-891 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.0.2 >Reporter: John Heitmann > Assigned To: Hiram Chirino >Priority: Minor > Attachments: interrupted.patch.gz > > > There were a few spots where the broker was masking the interrupt state after > handling an InterruptedException. This is a lint pass to clean some of that > up. I learned after I made this patch that it's actually slightly better > stylistically to call Thread.interrupt() instead of > Thread.currentThread().interrupt() since it's static and the interrupt state > is global(ish), but this is the version we've tested. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-889) Broker 'loses' messages and leaks resources when handling duplicate connections
[ https://issues.apache.org/activemq/browse/AMQ-889?page=all ] james strachan resolved AMQ-889. Fix Version/s: 4.1 Resolution: Fixed Patch applied - many thanks John! I had to make a minor patch to the MBeans to work with this patch (MBeanTest was failing) as we were being naughty and reusing the same consumerId on each createDurableSubscriber() MBean operation. You're right that 1, 2, 4 are a concern too - any patches in those areas are most welcome :) For 1) am thinking that the same IDs shoudl be used (so that then a broker is capable of deducing that a new connection is actually for an already existing client/subscription etc). We want to avoid tearing down and recreating a subscription if possible as for topics this could lead to message loss. I do think we need some more logic in the broker that if it receives a duplicate client, it will first check to see if the old one is dead as it seems quite common to get duplicate clientID when the client things the socket is dead and reconnects before the broker notices that the client is dead. e.g. we should maybe wait until we try to ping the old client, if that times out, kill the old connection. For 4) this seem to be a duplicate of AMQ-850 where we should timeout inactive consumers > Broker 'loses' messages and leaks resources when handling duplicate > connections > --- > > Key: AMQ-889 > URL: https://issues.apache.org/activemq/browse/AMQ-889 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.0.2 >Reporter: John Heitmann > Fix For: 4.1 > > Attachments: doubleConsumer.patch.gz > > > A client that uses a transport like the failover transport can damage the > broker's ability to deliver messages to other clients and ultimately cause > broker resource leaks and message loss. I've found 4 issues starting on the > client and ending on the broker that could be improved to make the situation > a lot better. In this issue I've provided a patch for #3. > 1) A failover client stores session metadata commands like ConsumerInfo in a > local state tracker. When failover occurs it replays these commands verbatim > to the newly connected-to broker. If the failover transport fails back to the > original broker it will replay the same commands with the same ids as it > already sent the broker. If the failover happens before the broker notices > the old connection has gone this can result in bad mojo. Clients should > probably regenerate session, consumer, and maybe connection ids. > 2) When the broker detects a duplicate ClientId being sent to it it throws an > exception saying so, but this does not stop the broker from processing > subsequent messages on that connection. The broker should tear down the > connection immediately when it sees a client thrashing about. > 3) When a broker receives a certain series of ConsumerInfo add and remove > commands with the same ConsumerId it leaks resources. One of the resources > leaked is the knowledge of lock owners on messages out in prefetch buffers. > This means those messages are stuck forever on the broker and can never be > retrieved and never be gc()ed. More below. > 4) Messages locked and out in prefetch buffers have no broker-side timeout. > If a consumer is up, saying hello to the inactivity monitor, but otherwise > doing nothing then its messages are locked forever. The broker should have a > janitor that redrives stale messages. This seems like the hardest of the 4 to > fix, but is one of the most important. > More on #3: One bad sequence of events is: > 1) Consumer 'c' connects to the broker over a failover transport. > 2) c subscribes to a queue and addConsumer() gets called. > 3) c fails away and then fails back. > 4) c replays ConsumerInfo to the broker. addConsumer() gets called again and > overwrites subscription tracking from the first. > After this the broker will eventually get a double remove and there will be > noisy JMX complaints etc., but the serious problem has already occurred in > step 4. My patch synchronizes the add step so that the broker is protected. > The individual client will still be a bit confused, and there will still be > noise when the second remove comes and JMX can't find the consumer to remove, > but the resource and message leaks are taken care of. > I'll file issues on the other 3 problems if they sound valid to you and > aren't already entered. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-892) Allow the JMX RMI server port to be hard set
[ https://issues.apache.org/activemq/browse/AMQ-892?page=all ] james strachan resolved AMQ-892. Fix Version/s: 4.1 Resolution: Fixed Patch applied John thanks! I've been thinking we should encourage folks to use the standard JMX configuration system properties and an optional security manager and policy file as opposed to the xbean.xml stuff - but its good to keep that working fine for folks who want to use it. > Allow the JMX RMI server port to be hard set > > > Key: AMQ-892 > URL: https://issues.apache.org/activemq/browse/AMQ-892 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 4.0.2 >Reporter: John Heitmann >Priority: Minor > Fix For: 4.1 > > Attachments: jmxPort.patch > > > When debugging a broker over the firewall with JMX it's often necessary to > use ssh tunneling. JMX uses 2 ports. The RMI registry port is what is > typically configured, but JMX also runs an RMI server on a different port-- > one that's typically chosen randomly. When you're ssh tunneling you need to > know what ports to tunnel to a priori so this is no good. > This patch adds a setting to allow the RMI server port to be set in addition > to the registry port. This is what it looks like in xml: > jmxDomainName="org.apache.activemq"/> > Also I snuck in a one-liner change that will create the connector if the user > configured jmx. This seems like the right thing to do, but my JMX experience > is pretty limited so it could break in something like Tomcat. Please take a > close look at that line before applying. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-890) JMX purge() fails with a ConcurrentModificationException
[ https://issues.apache.org/activemq/browse/AMQ-890?page=all ] james strachan resolved AMQ-890. Fix Version/s: 4.1 Resolution: Fixed Patch applied - many thanks! > JMX purge() fails with a ConcurrentModificationException > > > Key: AMQ-890 > URL: https://issues.apache.org/activemq/browse/AMQ-890 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.0.2 >Reporter: John Heitmann >Priority: Minor > Fix For: 4.1 > > Attachments: purge.patch.gz > > > I think this must be an issue running under jdk 1.5 only. It shows up on Mac > OS X and Linux 1.5 jvms. Remove and gc() were stumbling over each other and > invalidating the iterator. I broke them apart a bit to avoid the exception. > Thanks to Alan Robbins for help tracking this down. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-826) LDAP based authorization support
[ https://issues.apache.org/activemq/browse/AMQ-826?page=comments#action_36845 ] james strachan commented on AMQ-826: Nikola - any progress on getting a test case to work? > LDAP based authorization support > > > Key: AMQ-826 > URL: https://issues.apache.org/activemq/browse/AMQ-826 > Project: ActiveMQ > Issue Type: Improvement >Reporter: james strachan > Assigned To: Nikola Goran Cutura > Attachments: LdapAuth.zip > > > Patch kindly added by ngcutura - discussion thread... > http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-855) Add support for prefetchSize = 0
[ https://issues.apache.org/activemq/browse/AMQ-855?page=all ] james strachan reassigned AMQ-855: -- Assignee: Hiram Chirino > Add support for prefetchSize = 0 > > > Key: AMQ-855 > URL: https://issues.apache.org/activemq/browse/AMQ-855 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 4.0, 4.0.1, 4.0.2 > Environment: any >Reporter: Vadim Pesochinskiy > Assigned To: Hiram Chirino >Priority: Critical > Fix For: 4.1 > > Attachments: ActiveMQMessageConsumer.patch, > ActiveMQMessageConsumer.patch2, PrefetchSubscription.patch > > > This feature would enable to support following test case: > 2 servers are processing 3 submitted jobs with following processing times 10 > min, 1 min, 1 min. This sequence should finish in 10 minutes as one service > will pick up the 10 minutes job, meanwhile the other one should manage the > two 1 minute jobs. Since I cannot set prefetchSize=0, one of the 1 minute > jobs is sitting in prefetch buffer and the jobs are processed in 11 minutes > instead of 10. > This is simplification of the real scenario where I have about 30 consumers > submitting jobs to 20 consumers through AMQ 4.0.1. I have following problems: > Messages are sitting in prefetch buffer are not available to processors, > which results in a lot of idle time. > Order of processing is random. For some reason Job # 20 is processed after > Job # 1500. Since senders are synchronously blocked this can result in > time-outs. > Some requests are real-time, i.e. there is a user waiting, so the system > cannot wait, so AMQ-850 does not fix this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-895) JMS to JMS Bridge never reconnects under remote broker restarts.
[
https://issues.apache.org/activemq/browse/AMQ-895?page=comments#action_36844 ]
james strachan commented on AMQ-895:
I've tried adding a fix to SVN trunk. I wonder could you try it out for me to
see if it fixes your issue? Basically I've patched the code to try reconnecting
(by default a maximum of 10 times per message) if the send() fails before
stopping the bridge.
Grab the latest code here...
http://incubator.apache.org/activemq/source.html
then build it...
http://incubator.apache.org/activemq/building.html
> JMS to JMS Bridge never reconnects under remote broker restarts.
>
>
> Key: AMQ-895
> URL: https://issues.apache.org/activemq/browse/AMQ-895
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 4.0 RC2, 4.0.1
>Reporter: Manuel Teira
>
> I'm using ActiveMQ (4.0.1) JMS to JMS Bridge functionality to connect to a
> SunMQ JMS Broker (3.6 SP3 (Build 02-A)). I'm using two queues, an input and
> an output one, with the following configuration:
>
>
>
>
>
>
>
>
>
>
> The system works really well until the SunMQ broker needed to be restarted.
> This is what I found:
> 1.-ActiveMQ is not aware of the remote broker shutdown. I waited for a while,
> but no log on ActiveMQ indicates knowledge about the new situation.
> 2.-When I send a message to the output queue SUNRECV, ActiveMQ complains that
> the producer is closed:
> [ERROR][2006/08/25.09:47:12.039][ActiveMQ Session Task]failed to forward
> message: ActiveMQTextMessage {commandId = 5, responseRequired = false,
> messageId = ID:trabucco-43457-1156491843149-3:4:1:1:1, originalDestination =
> null, originalTransactionId = null, producerId =
> ID:trabucco-43457-1156491843149-3:4:1:1, destination = queue://SUNRECV,
> transactionId = null, expiration = 0, timestamp = 1156492032027, arrival = 0,
> correlationId = null, replyTo = null, persistent = false, type = null,
> priority = 0, groupID = null, groupSequence = 0, targetConsumerId = null,
> compressed = false, userID = null, content = null, marshalledProperties =
> null, dataStructure = null, redeliveryCounter = 0, size = 2, properties =
> null, readOnlyProperties = true, readOnlyBody = true, text = 1}([C4064]:
> Cannot perform operation, producer is closed.)
> After this, it is automatically queueing messages without sending them,
> showing the log:
> [DEBUG][2006/08/25.09:47:42.721][RMI TCP Connection(4)-10.95.89.20]No
> subscriptions registered, will not dispatch message at this time.
> Even if SunMQ is started again, ActiveMQ is not detecting the new situation,
> and continues queueing messages sent to SUNRECV.
> Please, make me know if more information is needed to understand the
> situation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-515) Add option so that producer.send() throws an exception if it would block due to the queue/broker being full.
[ https://issues.apache.org/activemq/browse/AMQ-515?page=all ] james strachan resolved AMQ-515. Fix Version/s: 4.1 (was: 4.2) Resolution: Fixed Patch applied with thanks John. BTW I made a minor change of the name of the property on usageManager in an attempt to make it a bit easier to understand what it did and what setting it to true means - so I called it sendFailIfNoSpace > Add option so that producer.send() throws an exception if it would block due > to the queue/broker being full. > > > Key: AMQ-515 > URL: https://issues.apache.org/activemq/browse/AMQ-515 > Project: ActiveMQ > Issue Type: New Feature > Components: JMS client, Broker >Affects Versions: 4.0.2 >Reporter: Hiram Chirino > Assigned To: John Heitmann > Fix For: 4.1 > > Attachments: blockFreeBroker.patch.gz > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-878) JMX Exception: "Destination already created" when recovering gigantic queues from database
[ https://issues.apache.org/activemq/browse/AMQ-878?page=comments#action_36842 ] james strachan commented on AMQ-878: FWIW the issue with 2 destinations being created due to concurrency issues should now be fixed. Not sure yet if we still need asynchronous recovery - but the original issue should be resolved > JMX Exception: "Destination already created" when recovering gigantic queues > from database > -- > > Key: AMQ-878 > URL: https://issues.apache.org/activemq/browse/AMQ-878 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: incubation > Environment: Embeded broker, Any platform (OS, JDK) - currentlly > embeded in JBoss 4.0.4.GA >Reporter: Nikolai Penkov > Assigned To: Hiram Chirino > Attachments: async-recovery.patch > > > I think this issue is described in Hiram's blog: > http://blogbucket.blogspot.com/2006/05/scaling-to-gigantic-queues-and-topics.html. > E.g. when broker is stopped with a lot of messages in queue. When started - > recovery process is fired (currently on creation of a queue), and if another > subscriber requests queue - it creates a new one, because previous process > hasn't finished. > I think the simpliest solution for that problem is to start recovery process > in another thread with synchronization to sent process(sent process should be > suspended till full recovery is done) and subscriber notification method > (every sunscriber should be notified on recovery of message). > I have attached a patch to activemq-core, which I have tested with my > environment - JBoss 4.0.4.GA with Embeded Broker ActiveMQ trunk release, jdbc > persistence. > I am not a spec. in threads nor in ActiveMQ design, and I am sure that you > will find a more elegant sollution to what I have provided. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-439) servicemix-beanflow - Workflow.joinAll failure to register onStop callback if first Activity stops during start handler
[ https://issues.apache.org/activemq/browse/SM-439?page=all ]
james strachan resolved SM-439.
---
Resolution: Fixed
OK I think I've fixed it for good this time :)
This test case managed to bring to light a few timing issues in the code.
Basically the Workflow class was a little too complex for its own good so I've
simplified that a bit. Also there was a chance that in JoinSupport things could
get started twice which is now fixed. Finally the one that really took me a
while to figure out was that sometimes activities stop before they have
completely finished starting; so the AbstractActivity start() method now only
sets the status to Start if it is Starting (to avoid overwriting the
Stopped/Failed status)
> servicemix-beanflow - Workflow.joinAll failure to register onStop callback if
> first Activity stops during start handler
> ---
>
> Key: SM-439
> URL: https://issues.apache.org/activemq/browse/SM-439
> Project: ServiceMix
> Issue Type: Bug
> Components: beanflow
>Affects Versions: incubation
> Environment: osx, jdk 1.5
>Reporter: Jason Anderson
> Assigned To: james strachan
> Fix For: 3.0-M3
>
>
> if the following code is run the JoinFlow.stop state will never be thrown
> because the internal JoinAll state is set to stopped after forking the first
> activity in the JoinSupport(Activity ...) constructor before the onStop
> callback is registered in WorkFlow.join
> public class JoinTest extends TestCase {
> public static class JoinFlow extends Workflow {
> public static enum Step {
> first, stop
> }
> public JoinFlow() {
> super(Step.first);
> }
> public void first() {
> final Activity a = new TimeoutActivity() {
> protected void onValidStateChange() {
> System.out.println("in a");
> stop();
> }
> };
> final Activity b = new TimeoutActivity() {
> protected void onValidStateChange() {
> System.out.println("in b");
> stop();
> }
> };
> System.out.println("in first");
> joinAll(Step.stop, 1, a, b);
> System.out.println("after join");
> }
> }
> public void testJoin() throws Exception {
> JoinFlow flow = new JoinFlow();
> flow.start();
> flow.join();
> }
> }
> I believe if the JoinSupport were to add all the activities to the children
> list before forking them it would prevent the JoinAll.onChildStateChange from
> being called prematurely with childCount=1, stoppedCount=1 when there should
> be 2 children but I cannot currently get the maven build to run to test this
> thoery
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (XBEAN-46) cannot configure properties of type java.util.Date using XML attributes (as Date is not coerced to a String)
[ http://issues.apache.org/jira/browse/XBEAN-46?page=all ] james strachan updated XBEAN-46: Summary: cannot configure properties of type java.util.Date using XML attributes (as Date is not coerced to a String) (was: add a DateEditor so that java.util.Date types can be auto-coerced from Strings in the XML) Issue Type: Bug (was: New Feature) Fix Version/s: 2.6 Description: add a DateEditor so that java.util.Date types can be auto-coerced from Strings in the XML Changed to a bug rather than a new feature as its a trivial ommission in the type coercion library > cannot configure properties of type java.util.Date using XML attributes (as > Date is not coerced to a String) > > > Key: XBEAN-46 > URL: http://issues.apache.org/jira/browse/XBEAN-46 > Project: XBean > Issue Type: Bug > Components: spring >Reporter: james strachan > Fix For: 2.6 > > > add a DateEditor so that java.util.Date types can be auto-coerced from > Strings in the XML -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-884) Ajax should support non-XML messages
[ https://issues.apache.org/activemq/browse/AMQ-884?page=all ]
james strachan reassigned AMQ-884:
--
Assignee: Greg Wilkins
> Ajax should support non-XML messages
>
>
> Key: AMQ-884
> URL: https://issues.apache.org/activemq/browse/AMQ-884
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 4.0.1
>Reporter: Danilo Tuler
> Assigned To: Greg Wilkins
> Attachments: _amq.js.patch
>
>
> _amq.js should not make an assumption that the received message is in XML
> format.
> I'm using a plain text message and it was not being handled to my handler.
> The user handler must be aware of the type of object it receives.
> Patch below.
> Index: _amq.js
> ===
> --- _amq.js (revision 419888)
> +++ _amq.js (working copy)
> @@ -46,11 +46,7 @@
> {
>for (var j = 0; j < responseElement.childNodes.length; j++)
>{
> -var child = responseElement.childNodes[j]
> -if (child.nodeType == 1)
> -{
> - handler(child);
> -}
> +handler(responseElement.childNodes[j]);
> }
> }
>}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-829) use some INFO level logging in failover: transport when a transport error occurs and when the transport is resumed
[ https://issues.apache.org/activemq/browse/AMQ-829?page=all ] james strachan resolved AMQ-829. Resolution: Fixed Done - we log using INFO level logging whenever a transport fails and reconnection starts > use some INFO level logging in failover: transport when a transport error > occurs and when the transport is resumed > -- > > Key: AMQ-829 > URL: https://issues.apache.org/activemq/browse/AMQ-829 > Project: ActiveMQ > Issue Type: Improvement >Affects Versions: 4.0.1 >Reporter: james strachan > Fix For: 4.1 > > > So choose a few log statements and make them info by default -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-893) on solaris you cannot easily kill a slave broker when using JDBC Master Slave
on solaris you cannot easily kill a slave broker when using JDBC Master Slave - Key: AMQ-893 URL: https://issues.apache.org/activemq/browse/AMQ-893 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.1 Environment: Solaris, T2 Reporter: james strachan Assigned To: james strachan Fix For: 4.1 Seems to hang in a tight loop -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-882) TopicPublisher.publish(topicSession.createTextMessage("Hello World") hangs and throws a JMSException
[ https://issues.apache.org/activemq/browse/AMQ-882?page=all ]
james strachan resolved AMQ-882.
Fix Version/s: 4.1
4.0.2
4.0.1
Resolution: Fixed
This problem looks like the socket is being closed for some reason on your
network. Not sure why - could be a dodgy router or some intermittent issue.
The workaround is to enable failover (putting failover: before the tcp:)
http://incubator.apache.org/activemq/how-can-i-support-auto-reconnection.html
> TopicPublisher.publish(topicSession.createTextMessage("Hello World") hangs
> and throws a JMSException
>
>
> Key: AMQ-882
> URL: https://issues.apache.org/activemq/browse/AMQ-882
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
>Affects Versions: 4.0.1
> Environment: Server: Suse Linux 2.6.5-7.244-smp, JDK 1.5.0_07
> Client: Windows XP SP2, JDK 1.5.0_06
>Reporter: Kai Pruente
> Fix For: 4.1, 4.0.2, 4.0.1
>
>
> Scenario:
> ActiveMQ and the publisher process running on the same server.
> Several clients are running on several Windows-XP clients
> Publisher code:
> {code}
> // initializing
> connection = msgFactory.createTopicConnection();
> connection.setExceptionListener(new JMSExceptionListener());
> connection.start();
> topicSession = connection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);
> topic = topicSession.createTopic(MFS_LOCATION_CHANGE_EVENT_TOPIC);
> publisher = topicSession.createPublisher(topic);
> publisher.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
> [...]
> // sending several times with the same topic
> try {
> publisher.publish(topicSession.createTextMessage(location.getName()));
> } catch (JMSException e) {
> log.fatal("Problems during informing Workplace topic:" +
> location.getName(), e);
> [...]
> {code}
> Subscriber code:
> {code}
> topicConnection = msgFactory.createTopicConnection();
> topicConnection.start();
> topicConnection.setExceptionListener(new JMSExceptionListener(listeners,
> this));
> topicSession = topicConnection.createTopicSession(false,
> Session.AUTO_ACKNOWLEDGE);
> Topic topic =
> topicSession.createTopic(EventSender.MFS_LOCATION_CHANGE_EVENT_TOPIC);
> topicSubscriber = topicSession.createSubscriber(topic);
> topicSubscriber.setMessageListener(new MessageListener() {
> public void onMessage(Message message) {
> if (message instanceof TextMessage) {
> [...]
> topicConnection.start();
> {code}
> After some thound of messages publish hangs for more than 1 minute and then
> throws a JMSException (see logs below). After searching in ActiveMQ mailing
> lists I changed the broker url of the publisher from:
> * tcp://arvwms:61616
> to
> *
> tcp://arvwms:61616?soTimeout=2000&connectionTimeout=1&socketBufferSize=1024&wireFormat.maxInactivityDuration=0
> This works some days fine, but now we get the exceptions again.
> Is this a problem between topic publisher and ActiveMQ or could it be also a
> problem between ActiveMQ and topic subscriber? If it is real a problem
> between publisher and ActiveMQ it can't be a network problem, becuase it is
> the same server.
> This problems occur about 10 times the day. With the exception and losing of
> 10 messages the day I could live, but the hanging about 1 minute is terrible
> for our application.
> The Exception:
> {code}
> DEBUG 2006-08-17 12:45:53.738 portConfirmationDefaultHandler :-: -
> handle telegram: [EMAIL
> PROTECTED],loadUnit=01900,lastLocation=SCS_CS,weight=,orientation=0,infoType=COMPLETE,wmsID=1039340,reason=OK]
> FATAL 2006-08-17 12:47:12.534 EventSender:-: -
> Problems during informing Workplace topic:SCS_CS
> javax.jms.JMSException: Broken pipe
> at
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:57)
> at
> org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:1094)
> at org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1553)
> at
> org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:462)
> at
> org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:356)
> at
> org.apache.activemq.ActiveMQTopicPublisher.publish(ActiveMQTopicPublisher.java:128)
> at
> com.ssn.acx.extensions.logistics.mfsadapter.event.EventSender.sendLocationChangeEvent(EventSender.java:150)
> at
> com.ssn.acx.extensions.logistics.mfsadapter.MFSTransactionWithSendingTrigger.commit(MFSTransactionWithSendingTrigger.java:109)
> at
> com.ssn.acx.core.common.transaction.GlobalTransactionImpl.commit(GlobalTransactionImpl.java:198)
> at
> com.ssn.acx.core.common.adapterservice.TelegramDispatcher.handleTelegram(TelegramDispatcher.java:306)
> at
> com.ssn.acx.core.common.adapte
[jira] Resolved: (AMQ-865) C# Client's Listener doesn't receive messages if you don't explicitly call Subscribe
[ https://issues.apache.org/activemq/browse/AMQ-865?page=all ]
james strachan resolved AMQ-865.
Fix Version/s: 4.1
Resolution: Fixed
Patch applied in SVN trunk if you want to try along with the test cases for
this issue and the related AMQ-883
> C# Client's Listener doesn't receive messages if you don't explicitly call
> Subscribe
>
>
> Key: AMQ-865
> URL: https://issues.apache.org/activemq/browse/AMQ-865
> Project: ActiveMQ
> Issue Type: Bug
> Components: NMS (C# client)
> Environment: Windows XP, VS 2005, ActiveMQ 4.0.1
>Reporter: Denis Abramov
> Fix For: 4.1
>
>
> Easiest way to reproduce the bug would be to start the consumer using the
> following code and then AFTER the consumer starts, start some producer
> (either java or C#) and you will notice that the consumer will not get any
> messages (through trial and error I found that calling Receive() on the
> consumer at least once will make you lose a message but the listener will
> kick back in):
> using System;
> using ActiveMQ;
> using ActiveMQ.Commands;
> using NMS;
> namespace JMSClient
> {
> ///
> /// Summary description for Class1.
> ///
> class Class1
> {
> ///
> /// The main entry point for the application.
> ///
> [STAThread]
> static void Main(string[] args)
> {
> IConnectionFactory factory = new ConnectionFactory(new
> Uri("tcp://localhost:61616?jms.useAsyncSend=true"));
> using (IConnection connection = factory.CreateConnection())
> {
> Console.WriteLine("Created a connection!");
> ISession session = connection.CreateSession();
> IDestination destination =
> session.GetQueue("EXCEL.TESTQUEUE");
> Console.WriteLine("Using destination: " + destination);
> // lets create a consumer and producer
> IMessageConsumer consumer =
> session.CreateConsumer(destination);
> consumer.Listener += new MessageListener(consumer_Listener);
> while (true);
> }
> }
> static void consumer_Listener(IMessage message)
> {
> if (message == null)
> {
> Console.WriteLine("No message received!");
> }
> else
> {
> Console.WriteLine("Received message with text: " +
> ((ActiveMQTextMessage)message).Text);
> }
> }
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-883) NMS asynchronous consumption of queued messages
[ https://issues.apache.org/activemq/browse/AMQ-883?page=all ] james strachan resolved AMQ-883. Fix Version/s: 4.1 Resolution: Fixed Thanks for the suggestions and ideas on how to fix it! :) I've added a bunch more test cases to AsyncConsumeTest to test out creating the consumer before the send, after it or before the send with adding the listener after it and they all are now working fine. > NMS asynchronous consumption of queued messages > --- > > Key: AMQ-883 > URL: https://issues.apache.org/activemq/browse/AMQ-883 > Project: ActiveMQ > Issue Type: Bug > Components: NMS (C# client) >Affects Versions: 4.0.2 > Environment: Win XP, AMQ 4.0.2 standalone broker, Java message sender > (JMS), C# (NMS) receiver >Reporter: Bryan Schmidt > Fix For: 4.1 > > > 1. Several messages are sent to a queue > 2. NMS client subscribes > 3. Queued messages are not received by NMS client > 4. Another message is sent to the queue (while the NMS client is subscribed) > 5. NMS client receives all messages > Same setup using Java publisher and subscriber behaves properly (queued > messages are sent to the subscriber immediately). > Editting the AsyncConsumeTest unit test can reproduce the problem and cause > the test to fail: > In the textMessageSRExample test, move the consumer logic below the producer > logic. (I.e. have the message sent to a queue before the consumer > subscribes). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-855) Add support for prefetchSize = 0
[ https://issues.apache.org/activemq/browse/AMQ-855?page=all ] james strachan updated AMQ-855: --- Patch Info: [Patch Available] setting the patch available flag > Add support for prefetchSize = 0 > > > Key: AMQ-855 > URL: https://issues.apache.org/activemq/browse/AMQ-855 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 4.0, 4.0.1, 4.0.2 > Environment: any >Reporter: Vadim Pesochinskiy >Priority: Critical > Fix For: 4.1 > > Attachments: ActiveMQMessageConsumer.patch, > ActiveMQMessageConsumer.patch2, PrefetchSubscription.patch > > > This feature would enable to support following test case: > 2 servers are processing 3 submitted jobs with following processing times 10 > min, 1 min, 1 min. This sequence should finish in 10 minutes as one service > will pick up the 10 minutes job, meanwhile the other one should manage the > two 1 minute jobs. Since I cannot set prefetchSize=0, one of the 1 minute > jobs is sitting in prefetch buffer and the jobs are processed in 11 minutes > instead of 10. > This is simplification of the real scenario where I have about 30 consumers > submitting jobs to 20 consumers through AMQ 4.0.1. I have following problems: > Messages are sitting in prefetch buffer are not available to processors, > which results in a lot of idle time. > Order of processing is random. For some reason Job # 20 is processed after > Job # 1500. Since senders are synchronously blocked this can result in > time-outs. > Some requests are real-time, i.e. there is a user waiting, so the system > cannot wait, so AMQ-850 does not fix this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
