[ http://jira.activemq.org/jira//browse/AMQ-637?page=comments#action_35767 ]
Robert Newson commented on AMQ-637: ----------------------------------- Some kind of connection pooling might be even better, but in the absence of that I'd be happy for the socket to exist only for the duration of the input stream. I'd definitely prefer it to be separate from the underlying JMS connection. Avoiding having the whole stream in RAM is a primary goal for us. We expect to see 99% of our incoming messages at around 2k, but the 1% are likely to be enormous (potentially up to 1gb). By negotiating a tcp stream I was hoping that we could use its blocking behaviour to cap the amount of RAM consumed on either side. In our case, we're writing the data we receive to a file system. The way I would plan to handle the two cases we have is to send an initial request message with the size of the payload and then switch to the streaming case at some threshold. For small messages, we'd include the payload in that request. > Enhance ActiveMQInput/Outputstream to use a real TCP connection. > ---------------------------------------------------------------- > > Key: AMQ-637 > URL: http://jira.activemq.org/jira//browse/AMQ-637 > Project: ActiveMQ > Type: Improvement > Reporter: Robert Newson > > > Currently the ActiveMQInputStream and ActiveMQOutputStreams chunk large > messages into 64k chunks. > Instead of that, could the act of calling getInputStream(Destination) > negotiates a new TCP socket connection? Using ActiveMQ will still give us > location transparency, but will the full streaming power of TCP. > I spoke with Hiram about this and he thought it would be a fairly simple > enhancement. I'm happy to work with him on this as we have a strong need for > this functionality. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
