Re: STOMP and JMSType
On 6/13/06, Nathan Mittler [EMAIL PROTECTED] wrote: So it sounds like we're all in agreement on the content-type header. For text, it would be something like text There could be a few values of Content-type which map to text (text/xml, application/soap, application/xml etc). Incidentally the default implementation for sending an ObjectMessage / MapMessage to a Stomp client could be to use XStream to turn it into XML and mark it as text/xml. Otherwise its gonna be extremely hard for a typical Stomp client to read the message. and for bytes it would be application/octet-stream. So this would not be an application-level header, but would be used by my stomp client code to determine which message type to create. If we're all in agreement with that, then it seems to make sense that the default functionality of the broker be modified to handle content-type in this way. And if that's true, then it seems like this particular issue is resolved. This way, we get it into the 4.1 release with no problems. We can create another issue to do the refactoring as you've suggested ... which will probably take a little more time and several conversations to get right. How does this sound? Sounds great. -- James --- http://radio.weblogs.com/0112098/
Re: STOMP and JMSType
On 6/14/06, Brian McCallister [EMAIL PROTECTED] wrote: On Jun 13, 2006, at 3:06 PM, Nathan Mittler wrote: So it sounds like we're all in agreement on the content-type header. For text, it would be something like text and for bytes it would be application/octet-stream. So this would not be an application-level header, but would be used by my stomp client code to determine which message type to create. Content-type is application level. I was suggesting it for your use case where you want to know what to convert a bytes message into in your C++ library =) Agreed! the app in this use case is the C++ client lib. so the c++ client lib could set the content-type to control a custom transformer so that sent JMS messages are exactly as the C++ stomp lib wants them to look like. So I'm starting to think there are 2 main use cases: 1) I want to have portable STOMP client that work on other providers. Then you accept that you can not tightly integrate with an existing JMS network in a portable way. For example they would not be able to send and receive JMS Map messages. Since stomp does not specify what those messages would look like on the wire. This means that STOMP needs to define how a portable mapping of JMS ByteMessage and TextMessage to STOMP Messages. I think what we have today is very close to this. We may just need to formalize it a little more in a document so that other providers could implement the same STOMP to JMS mapping. Of course, this mapping has to stay simple. 2) You have a STOMP client that does not mind intimately knowing about ActiveMQ. Then it can request transformation on the the send and receives. That transformation could totally change all the STOMP rules about the headers for for the messages coming in and out. It might use the content-type to hold the JMS message type: bytes, text, object, map, etc. and other headers like jms.Type to hold the JMSType headers. Also the payload encoding could be fancier. So by default, I think it should work like case #1, if you want to use case#2, then you use the transform header options. This gives us backward compatibility but for your C++ stomp client that exposes a JMS like API use case, I would think it falls under use case #2. Also, as offshoot idea on #2, is a provider allowed able to expose additional verbs/operations to clients? Kinda like how SVN/DAV does for HTTP? If we're all in agreement with that, then it seems to make sense that the default functionality of the broker be modified to handle content- type in this way. No. activemq-transformer would provide the JMS type mapping to override the default. I suggested that you use content-type (not required by stomp) to decide if something is text or a byte stream. Transfer-encoding is also useful for this. :-) And if that's true, then it seems like this particular issue is resolved. This way, we get it into the 4.1 release with no problems. We can create another issue to do the refactoring as you've suggested ... which will probably take a little more time and several conversations to get right. How does this sound? Nate On 6/13/06, Brian McCallister [EMAIL PROTECTED] wrote: On Jun 13, 2006, at 1:50 PM, Nathan Mittler wrote: Could you guys point me to a place in AMQ where this sort of thing is being done? That would save me a lot of searching =) I'm viewing this problem from the client side - the Stomp C++ client that Tim Bish and I are writing currently supports text and bytes messages. Within a general Stomp client, I would suggest that switching on JMS message types is not a productive goal. Using Content-type here makes a lot more sense, I think. . It would make a lot of sense to set it for text messages going out to Stomp if there is not one already supplied. Stomp is a protocol, like HTTP or SMTP -- hardwiring a client to a specific server implementation is probably not a general solution (though is fine if it is specifically an activemq client which happens to use stomp for transport). So when I get a stomp frame in, I need to map it back to a text or bytes message. We chose to do this for a couple of reasons: 1) to give JMS users a familiar interface and 2) to provide a simple interface for reading and writing text messages (e.g. xml). Content-type: text/xml -- Content-type: application/octet-stream With that said, I'm not seeing how I can do that mapping if the transformer is provided only in the SUBSCRIBE. A client could potentially get a variety of message types from a single subscription. I think it would have to be part of the MESSAGE frame, rather than the SUBSCRIBE. SUBSCRIBE activemq-transformer: com.example.ContentTypeMapper Here are the use cases I see: s/transformer/activemq-transformer/g I like the namespace. Client-Server 1) SEND\n...\ntransformer:text (client tells server it's a text message) +1 2)
Re: STOMP and JMSType
On 6/14/06, Mittler, Nathan [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Wednesday, June 14, 2006 12:40 PM To: activemq-dev@geronimo.apache.org Subject: Re: STOMP and JMSType On 6/14/06, Brian McCallister [EMAIL PROTECTED] wrote: On Jun 13, 2006, at 3:06 PM, Nathan Mittler wrote: So it sounds like we're all in agreement on the content-type header. For text, it would be something like text and for bytes it would be application/octet-stream. So this would not be an application-level header, but would be used by my stomp client code to determine which message type to create. Content-type is application level. I was suggesting it for your use case where you want to know what to convert a bytes message into in your C++ library =) Agreed! the app in this use case is the C++ client lib. so the c++ client lib could set the content-type to control a custom transformer so that sent JMS messages are exactly as the C++ stomp lib wants them to look like. Ok, so application-level is referring to the C++ library, not the user of the library? If so that eliminates the need for another header like amq-msg-type. How do we make this become part of the stomp spec? When we do, we should define the list of valid values for it (e.g. text and bytes). So here's a link to everything that is in the spec currently: http://stomp.codehaus.org/Protocol It's a WIKI so you can edit it and improve the spec. I think that a the big missing piece in the spec is that there is no specification of how STOMP messages get mapped to JMS messages. Since this is missing, there is no provider independent way of sending JMS messages from STOMP. Since every implementation could map a STOMP message to JMS messages differently. I think we need to add a STOMP Message to JMS Message Mapping section that providers SHOULD comply with if the provider also implements a JMS interface. The great part is since this is missing, you can make this whatever you want! So I'm starting to think there are 2 main use cases: 1) I want to have portable STOMP client that work on other providers. Then you accept that you can not tightly integrate with an existing JMS network in a portable way. For example they would not be able to send and receive JMS Map messages. Since stomp does not specify what those messages would look like on the wire. This means that STOMP needs to define how a portable mapping of JMS ByteMessage and TextMessage to STOMP Messages. I think what we have today is very close to this. We may just need to formalize it a little more in a document so that other providers could implement the same STOMP to JMS mapping. Of course, this mapping has to stay simple. 2) You have a STOMP client that does not mind intimately knowing about ActiveMQ. Then it can request transformation on the the send and receives. That transformation could totally change all the STOMP rules about the headers for for the messages coming in and out. It might use the content-type to hold the JMS message type: bytes, text, object, map, etc. and other headers like jms.Type to hold the JMSType headers. Also the payload encoding could be fancier. So by default, I think it should work like case #1, if you want to use case#2, then you use the transform header options. This gives us backward compatibility but for your C++ stomp client that exposes a JMS like API use case, I would think it falls under use case #2. So right now, I'm just concerned with #1. I'd like to make the first crack at our client as STOMP vendor independent as possible ... and we're only doing text and bytes messages for the first cut. Ok great! If we're in agreement that the two use cases you've identified are two separate JIRA issues, then we can just create a second JIRA for #2, and I can go off and implement #1 in the broker. Sure! BTW, what is the timeframe for 4.1? I like to aim for 1 month, and accept slipping a month or two :) I would say it's mostly dependent on new feature progress and code stability. Also, as offshoot idea on #2, is a provider allowed able to expose additional verbs/operations to clients? Kinda like how SVN/DAV does for HTTP? If we're all in agreement with that, then it seems to make sense that the default functionality of the broker be modified to handle content- type in this way. No. activemq-transformer would provide the JMS type mapping to override the default. I suggested that you use content-type (not required by stomp) to decide if something is text or a byte stream. Transfer-encoding is also useful for this. :-) And if that's true, then it seems like this particular issue is resolved. This way, we get it into the 4.1 release with no problems. We can create another issue to do the refactoring as you've suggested ... which
[jira] Assigned: (AMQ-699) Add PropertyPlaceholderConfigurer to default activemq.xml
[ https://issues.apache.org/activemq/browse/AMQ-699?page=all ]
Hiram Chirino reassigned AMQ-699:
-
Assign To: Hiram Chirino
Add PropertyPlaceholderConfigurer to default activemq.xml
-
Key: AMQ-699
URL: https://issues.apache.org/activemq/browse/AMQ-699
Project: ActiveMQ
Type: Improvement
Components: Broker
Versions: 4.0 RC3, 4.0 RC2, 4.0 M4
Reporter: Jason Dillon
Assignee: Hiram Chirino
Fix For: 4.0.1, 4.1
The default activemq.xml should include a Spring
PropertyPlaceholderConfigurer to allow the activemq.home property to be used
to root directories.
For example, this configuration will save data to $\{activemq.home}/var/data
always, no matter where the script was run from.
{code:xml}
beans xmlns=http://activemq.org/config/1.0;
bean
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=systemPropertiesModeName
value=SYSTEM_PROPERTIES_MODE_OVERRIDE/
/bean
broker useJmx=true
persistenceAdapter
journaledJDBC journalLogFiles=5
dataDirectory=${activemq.home}/var/data/
/persistenceAdapter
transportConnectors
transportConnector name=default uri=tcp://localhost:16161
discoveryUri=multicast://default/
/transportConnectors
/broker
/beans
{code}
Also, the default Log4j configuration should be augmented to use this
property for the out appender:
{code}
# File appender
log4j.appender.out=org.apache.log4j.RollingFileAppender
log4j.appender.out.file=${activemq.home}/var/log/activemq.log
log4j.appender.out.maxFileSize=1024KB
log4j.appender.out.maxBackupIndex=5
log4j.appender.out.append=true
log4j.appender.out.layout=org.apache.log4j.PatternLayout
log4j.appender.out.layout.ConversionPattern=%d [%-15.15t] %-5p %-30.30c{1} -
%m%n
{code}
--
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-658) allow support for 'remote destinations' allowing clients to send to /consume from a destination on a specified remote broker
[ https://issues.apache.org/activemq/browse/AMQ-658?page=all ] Hiram Chirino updated AMQ-658: -- Fix Version: 4.2 Might be a bit complex to implement.. putting this out for 4.2, perhpas someone will get interested in this issue and bump it up to 4.1? allow support for 'remote destinations' allowing clients to send to /consume from a destination on a specified remote broker Key: AMQ-658 URL: https://issues.apache.org/activemq/browse/AMQ-658 Project: ActiveMQ Type: New Feature Components: Broker Reporter: james strachan Fix For: 4.2 It could be the local broker A could talk to a remote broker B; so a client on A talks to destination [EMAIL PROTECTED] Extra brownie points for broker A connected to B connected to C such that A can't see C and sending to [EMAIL PROTECTED] on a client on A would make it to C -- 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-657) FailoverTransport inhibits exception-listener and transport-listener
[ https://issues.apache.org/activemq/browse/AMQ-657?page=all ] Hiram Chirino updated AMQ-657: -- Component: (was: Connector) Hi Kevin, could you re test this issue against 4.0 final? The failover transport should bre reaisnt those interupted and resumed events now. FailoverTransport inhibits exception-listener and transport-listener Key: AMQ-657 URL: https://issues.apache.org/activemq/browse/AMQ-657 Project: ActiveMQ Type: Bug Versions: incubation Reporter: Kevin Yaussy When using failover, it looks to me like my ExceptionListener (set via TopicConnection.setExceptionListener) gets removed, or at least never called when there is an exception on the connection. Additionally, I've tried using the ActiveMQConnection.addTransportListener, and failover transport seems to keep onException, transportInterupted and transportResumed from being called. -- 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-543) TEST org.apache.activemq.broker.ft.QueueMasterSlaveTest FAILS
[ https://issues.apache.org/activemq/browse/AMQ-543?page=all ] Hiram Chirino updated AMQ-543: -- type: Test (was: Bug) TEST org.apache.activemq.broker.ft.QueueMasterSlaveTest FAILS - Key: AMQ-543 URL: https://issues.apache.org/activemq/browse/AMQ-543 Project: ActiveMQ Type: Test Components: Test Cases Versions: 4.0 RC2 Environment: winxp Reporter: Adrian Co Assignee: Adrian Co -- 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-544) TEST org.apache.activemq.broker.ft.TopicMasterSlaveTest FAILS
[ https://issues.apache.org/activemq/browse/AMQ-544?page=all ] Hiram Chirino updated AMQ-544: -- type: Test (was: Bug) TEST org.apache.activemq.broker.ft.TopicMasterSlaveTest FAILS - Key: AMQ-544 URL: https://issues.apache.org/activemq/browse/AMQ-544 Project: ActiveMQ Type: Test Components: Test Cases Versions: 4.0 RC2 Environment: winxp Reporter: Adrian Co Assignee: Adrian Co -- 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-746) JournalPersistenceAdapterGBean needs to resolve the persistence adapter directory via serverInfo.resolveServer
[ https://issues.apache.org/activemq/browse/AMQ-746?page=all ] Hiram Chirino updated AMQ-746: -- Fix Version: 3.2.5 (was: 3.2.4) JournalPersistenceAdapterGBean needs to resolve the persistence adapter directory via serverInfo.resolveServer -- Key: AMQ-746 URL: https://issues.apache.org/activemq/browse/AMQ-746 Project: ActiveMQ Type: Bug Components: Geronimo Integration Versions: 3.2.4 Reporter: Gianny DAMOUR Fix For: 3.2.5 Attachments: GERONIMO-1638-AMQ.patch The current implementation resolves the persistence adapter directory via serverInfo.resolve. This causes a problem with the multi-server feature: the journal is located at var/activemq/journal instead of server name/var/activemq/journal -- 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-367) Axis/JMS/ActiveMQ demo
[ https://issues.apache.org/activemq/browse/AMQ-367?page=all ] Hiram Chirino updated AMQ-367: -- Fix Version: 3.2.5 (was: 3.2.4) Axis/JMS/ActiveMQ demo -- Key: AMQ-367 URL: https://issues.apache.org/activemq/browse/AMQ-367 Project: ActiveMQ Type: New Feature Versions: 3.1 Reporter: Chris Berry Fix For: 3.2.5 Attachments: axis-jms-demo.zip I have created a self-contained demo of using Axis/JMS/ActiveMQ James suggested that I pass it along for possible inclusion in the examples All of the code is in the enclosed ZIP Cheers, -- Chris -- 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-319) ActiveMQ hangs when initial connection to broker fails using reliable transport
[ https://issues.apache.org/activemq/browse/AMQ-319?page=all ] Hiram Chirino updated AMQ-319: -- Fix Version: 3.2.5 (was: 3.2.4) ActiveMQ hangs when initial connection to broker fails using reliable transport Key: AMQ-319 URL: https://issues.apache.org/activemq/browse/AMQ-319 Project: ActiveMQ Type: Improvement Components: JMS client Versions: 3.0 Reporter: Ramzi Saba Fix For: 3.2.5 Make these changes in the JMS client to avoid blocking on startup in case all brokers are down: 1- Start the reliable tcp channel in its own thread (seems there was an attempt to do so anyway) 2- Synchronous and asynchronous client calls (via session, consumer, etc.) to the reliable tcp channel should simply verify if a reliable channel has been already established, else throw a JMSException, alternatively allow the client to configure a timeout (currently it's hardcoded for synchronous calls only I believe). 3- Other than starting the reliable channel, the client should not be responsible of reestablishing a lost or unavailable channel. I would delegate reliability to the reliable channel itself. 4- Look into adding a listener to allow for a silent client startup and reconnect behind the scene once the broker is up -- 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-122) add support for priority message ordering
[ https://issues.apache.org/activemq/browse/AMQ-122?page=all ] Hiram Chirino updated AMQ-122: -- Fix Version: 3.2.5 (was: 3.2.4) add support for priority message ordering - Key: AMQ-122 URL: https://issues.apache.org/activemq/browse/AMQ-122 Project: ActiveMQ Type: New Feature Components: JMS client Versions: 4.0 Environment: Solaris 8, Linux, Windows , Java 1.4.2 Reporter: Etienne Araya Assignee: Ramzi Saba Fix For: 3.2.5 Original Estimate: 8 hours Remaining: 8 hours messages with higher priority is not consumed first ActiveMQ doesn't yet support priorities. messages with greater priority are not consumed first but that are consumed in the arrival order. -- 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-445) Erroneous extra linefeed in STOMP
[ https://issues.apache.org/activemq/browse/AMQ-445?page=all ] Hiram Chirino resolved AMQ-445: --- Resolution: Won't Fix The STOMP protocol actually states that all white space after the frame terminator but before the next command should be ignored. Erroneous extra linefeed in STOMP - Key: AMQ-445 URL: https://issues.apache.org/activemq/browse/AMQ-445 Project: ActiveMQ Type: Bug Components: Transport Versions: 3.2 Environment: WinXP RHEL4 Reporter: MF Attachments: log.txt Erroneous extra linefeeds (0x0A) are sent by the server after the terminating zero character in a server frame, see attached communication log. -- 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-482) Error in connection, probable race condition.
[ https://issues.apache.org/activemq/browse/AMQ-482?page=all ] Hiram Chirino resolved AMQ-482: --- Fix Version: 4.0 Resolution: Fixed Assign To: Hiram Chirino Race conditions have been resolved in 4.0. I encourage you to upgrade. Error in connection, probable race condition. - Key: AMQ-482 URL: https://issues.apache.org/activemq/browse/AMQ-482 Project: ActiveMQ Type: Bug Components: Connector Versions: 3.2.1 Environment: java version 1.5.0_04 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05) Java HotSpot(TM) Server VM (build 1.5.0_04-b05, mixed mode) Reporter: tyler ward Assignee: Hiram Chirino Fix For: 4.0 This appears to just be a race condition. I'm using version 3.2.1. 06:13:12,247 INFO [STDOUT] Exception in thread TcpTransportChannel: Socket[addr=/65.202.163.15,port=58475,localport=61616] 06:13:12,249 INFO [STDOUT] java.lang.NegativeArraySizeException 06:13:12,249 INFO [STDOUT] at org.activemq.io.impl.DefaultWireFormat.readPacket(DefaultWireFormat.java:129) 06:13:12,249 INFO [STDOUT] at org.activemq.io.impl.AbstractDefaultWireFormat.readPacket(AbstractDefaultWireFormat.java:175) 06:13:12,249 INFO [STDOUT] at org.activemq.io.AbstractWireFormat.readPacket(AbstractWireFormat.java:235) 06:13:12,250 INFO [STDOUT] at org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:313) 06:13:12,250 INFO [STDOUT] at java.lang.Thread.run(Thread.java:595) -- 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-443) ReliableTransport / KeepAlive algorithm does not work properly.
[ https://issues.apache.org/activemq/browse/AMQ-443?page=all ]
Hiram Chirino resolved AMQ-443:
---
Fix Version: 4.0
Resolution: Fixed
4.0 Has implemented a more robust keepalive solution. KeepAlive packets are
only sent when the transport has been idle. Also, while the transport is
performing a blocking opperation it is not considered idle.
ReliableTransport / KeepAlive algorithm does not work properly.
---
Key: AMQ-443
URL: https://issues.apache.org/activemq/browse/AMQ-443
Project: ActiveMQ
Type: Bug
Components: Transport, Broker
Versions: 3.2, 3.2.1
Environment: Solaris 8 / 10. JDK 1.5
Reporter: Kevin Yaussy
Fix For: 4.0
Attachments: KeepAliveDaemon.java, ReliableTransportChannel.java
The current implementation of KeepAliveDaemon.java will sometimes force
disconnections on well behaved connections. The problem may arrise if there
is a connection which goes away, and the KeepAlive send to that channel
blocks while attempting to reconnect. If this reconnection takes a while,
then other channels that were responding fine may get their connections
broken. This happens due to the following code in KeepAliveDaemon.java:
if ((channel.getLastReceiptTimestamp() +
channel.getKeepAliveTimeout() * 2) System.currentTimeMillis()) {
or
} else if ((channel.getLastReceiptTimestamp() +
channel.getKeepAliveTimeout()) System.currentTimeMillis()) {
The fact that the receipt timestamp is checked against
System.currentTimeMillis() causes the code to break otherwise good
connections. If a KeepAlive send (in examineChannel) for a broken channel
takes longer than some good channel's KeepAliveTimeout, then the good
connection gets broken.
This can, in turn, cause some pretty bad behavior in the Broker. While
testing and diagnosing this problem, I could some brokers in a network of
brokers stuck. The sequence of events during recovery, which get interrupted
due to closing the connections, would sometimes lead to the broker hanging
waiting for a receipt, such as during an addConsumer (which eventually calls
syncSendWithReceipt).
I have redone the logic in KeepAliveDaemon.java (which required a small
change to ReliableTransportChannel as well). This now seems to work.
I'm a bit concerned about the blocking calls, though. This may be a
different issue / bug. I thought it looked like there was a mechanism to
cancel outstanding receipt waiters - but, every once in a while that
mechanism would not get called. This results in the broker basically getting
stuck, and does not ever really recover.
--
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-438) MSMQ - ActiveMQ Bridge
[ https://issues.apache.org/activemq/browse/AMQ-438?page=all ] Hiram Chirino updated AMQ-438: -- Fix Version: 4.3 Since MSMQ is bit crappy anyways, this seems like a nice to have. Puting on the 4.3 roadmap. MSMQ - ActiveMQ Bridge Key: AMQ-438 URL: https://issues.apache.org/activemq/browse/AMQ-438 Project: ActiveMQ Type: New Feature Reporter: james strachan Fix For: 4.3 Use the C# for Stomp or the C# version of OpenWire to consume from MSMQ and publish to ActiveMQ. We could avoid XA support for now and just do duplicate detection in ActiveMQ. -- 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-421) Spelling error on startup of broker
[ https://issues.apache.org/activemq/browse/AMQ-421?page=all ] Hiram Chirino resolved AMQ-421: --- Fix Version: 3.2.5 Resolution: Fixed Thanks! Fixed in next release. Spelling error on startup of broker --- Key: AMQ-421 URL: https://issues.apache.org/activemq/browse/AMQ-421 Project: ActiveMQ Type: Improvement Components: Broker Versions: 3.1 Reporter: Paul Smith Priority: Trivial Fix For: 3.2.5 I have a developer who can spot spelling and grammatical errors from 50,000ft. She reports that the startup sequence bugs her (see highlighted bit below) C:\activemq-3.1\binactivemq ActiveMQ Message Broker (http://activemq.org/) Loading -*Mesaage*- Broker from activemq.xml on the CLASSPATH 08:47:53 INFO JDK 1.4+ collections available 08:47:53 INFO ActiveMQ 3.1 JMS Message Broker (ID:alice-1590-1132696072488-0:0) is starting :) -- 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-562) TEST TwoMulticastDiscoveryBrokerTopicSendReceiveTest failed
[ https://issues.apache.org/activemq/browse/AMQ-562?page=all ] Hiram Chirino updated AMQ-562: -- type: Test (was: Bug) TEST TwoMulticastDiscoveryBrokerTopicSendReceiveTest failed --- Key: AMQ-562 URL: https://issues.apache.org/activemq/browse/AMQ-562 Project: ActiveMQ Type: Test Components: Test Cases Versions: 4.0 Reporter: Hiram Chirino disabled for now. -- 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-540) TEST org.apache.activemq.usecases.TwoBrokerMessageNotSentToRemoteWhenNoConsumerTest FAILED
[ https://issues.apache.org/activemq/browse/AMQ-540?page=all ] Hiram Chirino updated AMQ-540: -- type: Test (was: Bug) TEST org.apache.activemq.usecases.TwoBrokerMessageNotSentToRemoteWhenNoConsumerTest FAILED -- Key: AMQ-540 URL: https://issues.apache.org/activemq/browse/AMQ-540 Project: ActiveMQ Type: Test Components: Test Cases Versions: 4.0 Reporter: Hiram Chirino -- 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-539) TEST org.apache.activemq.usecases.ThreeBrokerQueueNetworkUsingTcpTest FAILED
[ https://issues.apache.org/activemq/browse/AMQ-539?page=all ] Hiram Chirino updated AMQ-539: -- type: Test (was: Bug) TEST org.apache.activemq.usecases.ThreeBrokerQueueNetworkUsingTcpTest FAILED Key: AMQ-539 URL: https://issues.apache.org/activemq/browse/AMQ-539 Project: ActiveMQ Type: Test Components: Test Cases Versions: 4.0 Reporter: Hiram Chirino -- 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
Re: Nested MapMessage
One could allow Map or MapMessage or both as the second argument. The real issue is that nested MapMessage should be allowed. I have no quibble with a JMS provider allowing a Map as the second argument - as long as MapMessage entries were accepted. -- View this message in context: http://www.nabble.com/Nested-MapMessage-t1788442.html#a4877006 Sent from the ActiveMQ - Dev forum at Nabble.com.
[jira] Resolved: (AMQ-370) Sleeping time between redeliveries
[ https://issues.apache.org/activemq/browse/AMQ-370?page=all ]
Hiram Chirino resolved AMQ-370:
---
Fix Version: 4.0
Resolution: Fixed
Exponential redeliveries are now implemented on the client side correctly in
activemq 4.0. I would recommend you upgrade to 4.0.
Sleeping time between redeliveries
--
Key: AMQ-370
URL: https://issues.apache.org/activemq/browse/AMQ-370
Project: ActiveMQ
Type: Improvement
Reporter: Daniel Aioanei
Fix For: 4.0
The method org.activemq.service.impl.SubscriptionImpl.getMessagesToDispatch
seems to wait synchronously until the next redelivery is due for each message
to be retried. This means that for each message that needs be redelivered
let's say the next day, there will be a thread that's going to be sleeping
for a whole day. I think there is a lot of space for improvement here, but
please correct me if I didn't understand the code correctly.
if (redeliveryPolicy.isBackOffMode()
msg.getDeliveryCount()
redeliveryPolicy.getMaximumRetryCount()) {
long sleepTime =
redeliveryPolicy.getInitialRedeliveryTimeout();
sleepTime *= (msg.getDeliveryCount() *
redeliveryPolicy.getBackOffIncreaseRate());
try {
Thread.sleep(sleepTime);
}
catch (InterruptedException e) {
}
}
--
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-379) Duplicate message received
[ https://issues.apache.org/activemq/browse/AMQ-379?page=all ] Hiram Chirino resolved AMQ-379: --- Fix Version: 4.0 3.2.4 Resolution: Fixed This should work properly in 4.0, and I think 3.2 also fixed. Could you please test and re-open this issue if there is still a problem? Duplicate message received -- Key: AMQ-379 URL: https://issues.apache.org/activemq/browse/AMQ-379 Project: ActiveMQ Type: Bug Components: Broker Versions: 3.1 Environment: SUN JVM 5 Update 4 Reporter: Leo Chan Fix For: 4.0, 3.2.4 Attachments: test.rar I found if the Recevier and Sender start almost the same time. The Receiver will receiver the same message twise. I have included my Testing program run by java -classpath .;..\activemq-3.1.jar;..\lib\geronimo-spec-jms-1.1-rc4.jar;..\lib\geronimo-spec-j2ee-management-1.0-rc4.jar;..\lib\commons-logging-1.0.3.jar;..\lib\log4j-1.2.8.jar;..\lib\concurrent-1.3.4.jar;..\conf;..\lib\spring-1.2.2.jar TestJmsSender I have test by restarted the program ~10 times and around 40% chance of have the error of receiver rec same message twise -- 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-303) Pooled XAConnectionFactory for use with Spring
[ https://issues.apache.org/activemq/browse/AMQ-303?page=all ] Hiram Chirino reassigned AMQ-303: - Assign To: james strachan James, perhaps we should close this issue out and open one against jencks? Pooled XAConnectionFactory for use with Spring -- Key: AMQ-303 URL: https://issues.apache.org/activemq/browse/AMQ-303 Project: ActiveMQ Type: Improvement Components: Connector, JMS client, JCA Container Environment: ActiveMQ 3 Reporter: Andy DePue Assignee: james strachan Priority: Minor Attachments: PooledSpringXAConnectionFactory_7_14_05.zip Work is currently underway to provide a JCA Container implementation for Spring, which would allow fully transaction aware usage of ActiveMQ in Spring. Current Spring JCA Container implementations work well for consumers, but are not quite mature for producers. I've thrown together (as in, just a couple hours of work) an implementation of XAConnectionFactory that is both pooled and automatically detects and participates in surrounding JTA transactions. There are some caveats to this, however: 1. This is considered a temporary solution until Spring JCA Container implementations have matured to the point where one can access pooled producers that automatically participate in the (optional) surrounding JTA transaction, even if the transaction was started by a 3rd party (as opposed to being started by ActiveMQ in response to consuming a message). 2. This was thrown together by copying out ActiveMQ's PooledConnectionFactory code and modifying as needed. Because of this, there is much code duplication between PooledConnectionFactory and PooledSpringXAConnectionFactory. Also, the code ends up being ugly. :) 3. This implementation depends on both JTA and Spring. It requires JTA in order to properly enlist and handle XA connections/sessions/etc, and it requires Spring in order to manage XASession resources associated with the current transaction. 4. We are still in the process of testing this code. We are moving our current code base to Spring 1.2.2 as we need some of the transaction bug fixes made in 1.2.2. Until we are fully ported, we will not be able to fully test this code. If we run into problems/bugs, we will post updates to this JIRA issue. With all that out of the way, usage is very similar to PooledConnectionFactory. First, I'll comment on usage, and then show a sample Spring configuration. As far as usage is concerned, you must not hold onto sessions and/or producers for long periods of time, especially across transaction boundaries. In other words, do not write code that opens a session and then leaves it open for the duration of your application. Instead, your code should do this every time it needs to produce: 1. Open a new connection: connectionFactory.createConnection(). 2. Create a new session: connection.createSessions(...) 3. Create a producer: session.createProducer(...) 4. Produce messages 5. close producer, close session, close connection. This pattern may seem heavyweight, but because you are using PooledSpringXAConnectionFactory, it is actually quite light and efficient. The following will hold true if you use this pattern: 1. You will be using pooled connections, sessions, and producers - so you will be avoiding the cost of opening/creating them every time, even though you are calling create and close methods. 2. These sessions will automatically participate in any surrounding JTA transaction. 3. All these objects will be properly managed for thread safety. 4. If there is a surrounding JTA transaction, then for each thread, the same actual XASession will be used for the remainder of the transaction. Finally, here is an example Spring configuration: !-- This bean automatically handles pooling and transaction management -- bean id=jmsConnectionFactory class=com.marathon.jms.PooledSpringXAConnectionFactory property name=connectionFactory !-- Actual transaction aware connection factory. -- bean class=org.activemq.ActiveMQXAConnectionFactory property name=brokerURLvalue... broker URL goes here .../value/property /bean /property property name=jtaTransactionManager ref=transactionManager/ /bean Note that PooledSpringXAConnectionFactory needs access to a JTA TransactionManager, and there are two ways to provide it. If you have exposed the actual JTA javax.transaction.TransactionManager as a bean in your Spring config, then you would set the transactionManager property: property name=transactionManager ref=beanNameOfTransactionManager/ If you have exposed a Spring org.springframework.transaction.jta.JtaTransactionManager in your config, then you could set the jtaTransactionManager property: property
[jira] Commented: (AMQ-361) duplicate delivery, already consumed messages are reconsumed after server restart
[ https://issues.apache.org/activemq/browse/AMQ-361?page=comments#action_36360 ] Hiram Chirino commented on AMQ-361: --- Could you see if your still having the same issues with ActiveMQ 4.0? The queue browsing has been improved tremendously since 3.x duplicate delivery, already consumed messages are reconsumed after server restart - Key: AMQ-361 URL: https://issues.apache.org/activemq/browse/AMQ-361 Project: ActiveMQ Type: Bug Components: Broker, Message Store, JCA Container Versions: 3.1 Environment: windows xp, jdk 1.5, embedded activemq 3.1 broker, jboss 4.02, persistent messages with derby db. Reporter: Gokturk Ozer Attachments: 1.log I am running an embedded activemq broker inside jboss server, I send 1000 messages with ~10K size each to a queue, these messages are consumed by MDBs. After all the messages are consumed, I check the queue via hermes, it also shows no message in the queue. Everything works perfect up to this point. I observe the problem after I stop the jboss server. I connect to derby database via networkserver, I still see some messages in activemq_msgs table. I shutdown derby networkserver and start jboss again, I see from the log that some of the messages which were consumed previously, are being consumed again. If I start the server without deploying the MDB and check the queue via hermes, I see some but not all the messages which were consumed previously still in the queue, before restart hermes was showing no messages. -- 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-365) MySQL 4.1 isn't supported because SQL for old messages uses subselects
[ https://issues.apache.org/activemq/browse/AMQ-365?page=all ] Hiram Chirino resolved AMQ-365: --- Resolution: Duplicate dup MySQL 4.1 isn't supported because SQL for old messages uses subselects Key: AMQ-365 URL: https://issues.apache.org/activemq/browse/AMQ-365 Project: ActiveMQ Type: Improvement Components: Message Store Versions: 3.1 Reporter: Al Maw Priority: Minor store.jdbc.adapter.getFindOldMessagesStatment() store.jdbc.adapter.getDeleteOldMessagesStatment() Both of these use subselects, which quite a few databases (including MySQL prior to version 4.1) don't support. -- 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
Re: Nested MapMessage
There are a lot of real-world applications that need the ability to send structured data via JMS. For example, take an application that wants to publish a portfolio of bonds (or stocks - take your pick). The logical way to do it would be to have a portfolio container message with zero or more (nested) bond messages. The alternative, breaking a portfolio into a series of bond messages, is VERY cumbersome and requires that the consumer reconstruct the portfolio. This is but one instance of a real-world need to publish arbitrary message structures. Nested MapMessage addresses this need directly and elegantly. -- View this message in context: http://www.nabble.com/Nested-MapMessage-t1788442.html#a4877171 Sent from the ActiveMQ - Dev forum at Nabble.com.
[jira] Resolved: (AMQ-308) Scoping JNDI properties
[ https://issues.apache.org/activemq/browse/AMQ-308?page=all ] Hiram Chirino resolved AMQ-308: --- Resolution: Won't Fix breaking compatibility is not really an option at this time. Too bad we did not do this for 4.0 perhaps for 5.x we can do this. Scoping JNDI properties --- Key: AMQ-308 URL: https://issues.apache.org/activemq/browse/AMQ-308 Project: ActiveMQ Type: Improvement Versions: 3.0 Reporter: Stephane Bailliez Priority: Trivial It would be better to have scope over ActiveMQ JNDI properties, ie: activemq.useEmbeddedBroker= ... activemq.queue.MyQueue= ... This will break backward compatibility. You could eventually deprecate the original syntax for a release and remove support for the next one. -- 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-174) Use of Connection.ExceptionListener defeats reliable transport
[ https://issues.apache.org/activemq/browse/AMQ-174?page=all ] Hiram Chirino resolved AMQ-174: --- Fix Version: 4.0 Resolution: Fixed This has all been fixed in 4.0 Use of Connection.ExceptionListener defeats reliable transport -- Key: AMQ-174 URL: https://issues.apache.org/activemq/browse/AMQ-174 Project: ActiveMQ Type: Improvement Components: Transport Versions: 2.0 Environment: W2K java version 1.4.2_05 Reporter: Dennis Cook Fix For: 4.0 If an ExceptionListener is registered with a Connection and it is triggered by the loss of connection to a broker, the additional checks for other brokers in the list that the reliable transport usually provides is bypassed and the Connection is terminated. -- 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-268) Queue + Transaction: ordering/redelivery
[ https://issues.apache.org/activemq/browse/AMQ-268?page=all ] Hiram Chirino resolved AMQ-268: --- Fix Version: 4.0 Resolution: Fixed 4.0 gives it back to you in the same order. Queue + Transaction: ordering/redelivery Key: AMQ-268 URL: https://issues.apache.org/activemq/browse/AMQ-268 Project: ActiveMQ Type: Improvement Versions: 3.1, 3.0 Reporter: Paul Smith Fix For: 4.0 Attachments: TransactionRollbackTest.zip [This was posted directly to the [EMAIL PROTECTED] mailing list while JIRA was down, reposting here] My understanding is that Queue's are ordered, FIFO things. We have an interesting scenario here processing a message from a Queue can periodically cause an error because of local conditions. What we'd assumed is that we could get the message out of the queue using transactions, and should the error processing the message fail, rollback, wait a bit, then go again. In our current scenario it is not critical of the ordering, but this has highlighted something that may be required for a different scenario later on. We set this up using ActiveMQ 3.0 and also tested using the latest snapshot, but after a failure (rollback), messages after the failure message get delivered first, and then when it does get around to redelivering the failure message it is always the wrong message redelivered. we setup a test case to reproduce the scenario. Now, this could well highlight a vague area of the spec, or even our programming errors. All comments appreciated. (see attached test case, with log output you get when you run it, you will see that Message 3 is rolled back, but it redelivers message 2 instead, and only after putting Message 4 5 through) cheers, Paul Smith -- 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-192) error when starting up broker for the first time
[ https://issues.apache.org/activemq/browse/AMQ-192?page=all ] Hiram Chirino resolved AMQ-192: --- Fix Version: 4.0 Resolution: Fixed ActiveMQ 4.0 now only need 1 jar in the classpath to startup, it will take care of setting the right classpath up for activemq. error when starting up broker for the first time Key: AMQ-192 URL: https://issues.apache.org/activemq/browse/AMQ-192 Project: ActiveMQ Type: Improvement Components: Broker Versions: 2.0 Environment: win2K (any other can provide as necessary) Reporter: vijay venkatesh Priority: Minor Fix For: 4.0 Downloaded activemq2.0 and tried running activemq(just default startup mode) and got the following error: ** C:\activemq\activemq-release-2.0activemq The input line is too long. :gotAllArgs was unexpected at this time. ** Didnt see this in any faq/errors, so dont know if I didnt install correctly? Thanks much, V -- 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-192) error when starting up broker for the first time
[ https://issues.apache.org/activemq/browse/AMQ-192?page=all ] Hiram Chirino reassigned AMQ-192: - Assign To: Hiram Chirino error when starting up broker for the first time Key: AMQ-192 URL: https://issues.apache.org/activemq/browse/AMQ-192 Project: ActiveMQ Type: Improvement Components: Broker Versions: 2.0 Environment: win2K (any other can provide as necessary) Reporter: vijay venkatesh Assignee: Hiram Chirino Priority: Minor Fix For: 4.0 Downloaded activemq2.0 and tried running activemq(just default startup mode) and got the following error: ** C:\activemq\activemq-release-2.0activemq The input line is too long. :gotAllArgs was unexpected at this time. ** Didnt see this in any faq/errors, so dont know if I didnt install correctly? Thanks much, V -- 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-288) Allow the RA do customize the clientID using a clientID prefix then a counter after that for each connection it creates.
[ https://issues.apache.org/activemq/browse/AMQ-288?page=all ] Hiram Chirino resolved AMQ-288: --- Resolution: Won't Fix It does not look like there is much interest in changing how the RA does client id handling. The issue really did not make much sense to me. Allow the RA do customize the clientID using a clientID prefix then a counter after that for each connection it creates. Key: AMQ-288 URL: https://issues.apache.org/activemq/browse/AMQ-288 Project: ActiveMQ Type: New Feature Components: Connector Reporter: james strachan enhance the RA to have a clientIDPrefix property in the ActiveMQConnectionRequestInfo class (with a similar getter/setter on the RA class too) so that you could specify your own clientID prefix - then the RA/MC could create a new client ID for each connection it makes by appending 1, 2, 3, 4 to the clientID. more background... On 6 Jul 2005, at 09:44, Roos, Robin wrote: Hi All I set the clientid element in ra.xml, but when I started the JBoss server with this deployment the ActiveMQ connection pool tried to create multiple connections with the same clientid. Naturally that failed. config-property descriptionThe client id that will be set on the connection that is established to the ActiveMQ server./description config-property-nameClientid/config-property-name config-property-typejava.lang.String/config-property-type config-property-valueGenesisApplicationServer/config-property-value /config-property I was hoping that I could differentiate between different clients when reviewing activemq.log. I set the clientid to GenesisApplicationServer. With a pooling policy it would be convenient if the connections in the pool became known as GenesisApplicationServer-n where n is the instance number in the pool. But perhaps setting clientid is inappropriate in this case Files activemq3.log and ra.xml are attached. Kind regards, Robin. -- 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-241) References to ActiveMQConnectorGBean cannot be added to other GBeans
[ https://issues.apache.org/activemq/browse/AMQ-241?page=all ] Hiram Chirino resolved AMQ-241: --- Resolution: Won't Fix GBean modules will soon be moving into the geronimo project since they more more closely related. References to ActiveMQConnectorGBean cannot be added to other GBeans - Key: AMQ-241 URL: https://issues.apache.org/activemq/browse/AMQ-241 Project: ActiveMQ Type: Improvement Components: Geronimo Integration Reporter: Dondi Imperial Cannot add org.activemq.gbean.ActiveMQConnectorGBean as references to other GBeans in geronimo. I think this is because it does not have a default constructor or implement an interface. -- 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-45) JCA 1.0 outbound support for publishing to JMS on legacy app servers
[ https://issues.apache.org/activemq/browse/AMQ-45?page=all ] Hiram Chirino resolved AMQ-45: -- Resolution: Won't Fix resolving issue due to lack of contributor interest to implement this feature. The longer we wait the less interest there will be since JCA 1.0 is getting OLD. JCA 1.0 outbound support for publishing to JMS on legacy app servers Key: AMQ-45 URL: https://issues.apache.org/activemq/browse/AMQ-45 Project: ActiveMQ Type: New Feature Reporter: james strachan Priority: Minor It'd be handy for folks stil stuck on containers like WL7 to provide a JCA 1.0 outbound implementation which publishes on ActiveMQ with XA support connection pooling 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] Updated: (AMQ-73) Provide a REST view onto a queue browser
[ https://issues.apache.org/activemq/browse/AMQ-73?page=all ] Hiram Chirino updated AMQ-73: - Fix Version: 4.2 Should not be too hard to implement.. Putting out for 4.2 Provide a REST view onto a queue browser Key: AMQ-73 URL: https://issues.apache.org/activemq/browse/AMQ-73 Project: ActiveMQ Type: New Feature Reporter: james strachan Priority: Minor Fix For: 4.2 So that a REST client can view whats on the queue, then view each message then consume/delete items on the queue in a reliable REST fashion -- 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-62) support XStream alternative to serialization?
[ https://issues.apache.org/activemq/browse/AMQ-62?page=all ] Hiram Chirino resolved AMQ-62: -- Fix Version: 4.0 Resolution: Fixed 4.0 supports the xstream wireformat. support XStream alternative to serialization? - Key: AMQ-62 URL: https://issues.apache.org/activemq/browse/AMQ-62 Project: ActiveMQ Type: New Feature Reporter: james strachan Assignee: Karsten Silz Priority: Minor Fix For: 4.0 It'd be cool to have an XStream plugin... http://xstream.codehaus.org/ to support transparent serialization to XML while still obeying the ObjectMessage contract. Maybe allowing other clients to see the message as a TextMessage containing XML? Another idea could be to use the XMLBeans plugin http://xmlbeans.apache.org/ to do the same thing in reverse - for XML stored in a TextMessage (or even XmlMessage) we could allow objects to be extracted via ObjectMessage -- 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-3) get JXTA transport working
[ https://issues.apache.org/activemq/browse/AMQ-3?page=all ] Hiram Chirino resolved AMQ-3: - Resolution: Won't Fix Assign To: Hiram Chirino jxta is not in big demand lately. get JXTA transport working -- Key: AMQ-3 URL: https://issues.apache.org/activemq/browse/AMQ-3 Project: ActiveMQ Type: New Feature Versions: 1.0 Reporter: james strachan Assignee: Hiram Chirino Priority: Minor -- 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-21) message type restrictions on destinations
[ https://issues.apache.org/activemq/browse/AMQ-21?page=all ] Hiram Chirino reassigned AMQ-21: Assign To: james strachan Could you explain what you mean by this a little more? message type restrictions on destinations - Key: AMQ-21 URL: https://issues.apache.org/activemq/browse/AMQ-21 Project: ActiveMQ Type: Wish Reporter: james strachan Assignee: james strachan Priority: Minor Some users may want to restrict certain types (e.g. XSD types) of messages to be sent on certain destinations. -- 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-22) message type metadata exposing
[ https://issues.apache.org/activemq/browse/AMQ-22?page=all ] Hiram Chirino reassigned AMQ-22: Assign To: james strachan Are you refering to providing some visualization tools into the types of messages that are flowing through the broker? message type metadata exposing -- Key: AMQ-22 URL: https://issues.apache.org/activemq/browse/AMQ-22 Project: ActiveMQ Type: Wish Components: Broker Reporter: james strachan Assignee: james strachan Priority: Minor users may wish to see what types of messages are sent on what destinations. e.g. we may wish to collate together all Message.getMessageType() values are used for each Destination. Similarly we might wanna capture what XSD types are used on each destination to help folks grok the message model used in an organisation -- 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-69) create latency benchmark to test RPC round trips
[ https://issues.apache.org/activemq/browse/AMQ-69?page=all ] Hiram Chirino resolved AMQ-69: -- Fix Version: 4.0 Resolution: Fixed Our jmeter tests can do this now if you set it up to test with sync sends. create latency benchmark to test RPC round trips Key: AMQ-69 URL: https://issues.apache.org/activemq/browse/AMQ-69 Project: ActiveMQ Type: New Feature Reporter: james strachan Priority: Minor Fix For: 4.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] Updated: (AMQ-186) Allow for use of a connect timeout property when creating socket
[ https://issues.apache.org/activemq/browse/AMQ-186?page=all ] Hiram Chirino updated AMQ-186: -- Fix Version: 4.2 Lets see if we can get this done by 4.2 Allow for use of a connect timeout property when creating socket Key: AMQ-186 URL: https://issues.apache.org/activemq/browse/AMQ-186 Project: ActiveMQ Type: Improvement Components: Transport Reporter: Dennis Cook Priority: Minor Fix For: 4.2 Socket construction in the TcpTransportChannel class uses either Socket(host, port) or Socket(host, port, host, port) variations. J2SDK offers another construction model; Socket(), bind(bindpoint), connect(endpoint, timeout. Use of this model allows a custom connectoin timeout value to be used. -- 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-20) XmlMessage type support
[ https://issues.apache.org/activemq/browse/AMQ-20?page=all ] Hiram Chirino updated AMQ-20: - Fix Version: 4.3 Cool idea.. may ned a little more thought into how we will implement it. Putting on roadmap 4.3 XmlMessage type support --- Key: AMQ-20 URL: https://issues.apache.org/activemq/browse/AMQ-20 Project: ActiveMQ Type: Wish Reporter: james strachan Priority: Minor Fix For: 4.3 A real common use case I see is financial systems, sending around lots of XSD documents over some protocol (HTTP / JMS) - if both ends know the schema formats - then sending / receiving an efficient binary XSD format (using longs / ints / doubles for numeric / date types on DataInput/Output) would totally rock - to the end user it'd look like XML beans or text or DOM but on the wire could be super fast no xml parsing. e.g. if both sides of the wire were using Java were using XMLBeans on both sides as a bean / DOM / XPath / XQuery API, then we could take an xmlbeans schema lazily bytecode generate a marshaller per schema to use an efficient wire format, assuming the other end knows the schema. Then the message on the wire looks like http://some.repository.com/someschema/version/1.2.3 [lots of bytes] so the reader would load the XSD schema from the given universal URI, if its not created an xmlbeans schema marshaller for it yet, do so, then it can decipher the bytes. Then in those times where you're sending/receiving 100K messages per hour of the same schema, you don't have all that XML parsing to deal with - it'd use a super fast ASM.1 style binary format which to the application programmer could be marshalled into a DOM / bean / XPath / XQuery model, yet have a super-fast wire format. We could expose these types of messages to the user via a special Destination which would accept either Text messages or Object messages - if the ObjectMessage contains an xmlbean then it'd use the super-efficient binary serialization on the wire presenting it to the user as either an ObjectMessage, TextMessage or maybe a new XmlMessage (or all 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] Resolved: (AMQ-131) provide implementation to retrieve ActiveMQDestination in the MessageContainerAdmin interface
[ https://issues.apache.org/activemq/browse/AMQ-131?page=all ] Hiram Chirino resolved AMQ-131: --- Resolution: Won't Fix 4.0 has a much better JMX admin frame work and this issue does not appy anymore. provide implementation to retrieve ActiveMQDestination in the MessageContainerAdmin interface - Key: AMQ-131 URL: https://issues.apache.org/activemq/browse/AMQ-131 Project: ActiveMQ Type: New Feature Components: Broker Environment: Windows XP jsdk1.4.2_03 activemq main cvs trunk date nov 9, 2004 geronimo Reporter: Jonas Lim Priority: Minor Provide implementaion to retrieve ActiveMQDestination in the MessageContainerAdmin interface. This would be helpful when retrieving a list of destinations thru the BrokerAdmin so that we'll also have a copy of the ActiveMQDestination object not just the destination name. This way if we would like to remove the destination thru the BrokerAdmin, we can know in advance how to remove the destination based from the destination type (ie. brokerAdmin.destoryMessageContainer(new ActiveMQQueue( destinationName)) or brokerAdmin.destoryMessageContainer(new ActiveMQTopic(destinationName)) -- 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
Re: Nested MapMessage
On 6/15/06, jhakim [EMAIL PROTECTED] wrote: There are a lot of real-world applications that need the ability to send structured data via JMS. For example, take an application that wants to publish a portfolio of bonds (or stocks - take your pick). The logical way to do it would be to have a portfolio container message with zero or more (nested) bond messages. The alternative, breaking a portfolio into a series of bond messages, is VERY cumbersome and requires that the consumer reconstruct the portfolio. This is but one instance of a real-world need to publish arbitrary message structures. Nested MapMessage addresses this need directly and elegantly. Yes.. but nested Maps also addresses the same issue it seem to me. What does nesting MapMessages buy you that nested Maps do not? -- View this message in context: http://www.nabble.com/Nested-MapMessage-t1788442.html#a4877171 Sent from the ActiveMQ - Dev forum at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com
