[
https://issues.apache.org/activemq/browse/AMQ-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38015
]
Sridhar Komandur commented on AMQ-920:
--
Rob/James,
I have two-way communication working on my desktop
[
https://issues.apache.org/activemq/browse/AMQ-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sridhar Komandur updated AMQ-917:
-
Attachment: dnc4.1patch.txt
Discovery Network Connector needs to clean up internal
[
https://issues.apache.org/activemq/browse/AMQ-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37841
]
Sridhar Komandur commented on AMQ-917:
--
Hi,
What is the status of applying the provided patch ?
I have uploaded
[
https://issues.apache.org/activemq/browse/AMQ-917?page=comments#action_37380 ]
Sridhar Komandur commented on AMQ-917:
--
[[ Old comment, sent by email on Mon, 2 Oct 2006 15:34:32 -0700 ]]
James,
I tried many snapshots going back in 5
[ https://issues.apache.org/activemq/browse/AMQ-917?page=all ]
Sridhar Komandur reopened AMQ-917:
--
I tested after apply the patch to the turnk (as of yesterday). It still breaks
in a couple of places even without the patch (an example below
[ https://issues.apache.org/activemq/browse/AMQ-917?page=all ]
Sridhar Komandur updated AMQ-917:
-
Attachment: patchfile.txt
per my earlier comment, patch to latest trunk.
Discovery Network Connector needs to clean up internal
[ https://issues.apache.org/activemq/browse/AMQ-917?page=all ]
Sridhar Komandur updated AMQ-917:
-
Attachment: new_patchfile.txt
Please ignore the earlier attachment.
Discovery Network Connector needs to clean up internal
[
https://issues.apache.org/activemq/browse/AMQ-920?page=comments#action_36950 ]
Sridhar Komandur commented on AMQ-920:
--
Jon brought up another important use case related to brokers outside the
Firewall (perhaps in the DMZ
: Improvement
Components: Connector
Reporter: Sridhar Komandur
We noticed the following during our testing
When a broker A establishes connection to broker B, the message flow is
unidirectional from A to B.
This is a an issue for us: For example, consider brokers associated
Components: Connector
Reporter: Sridhar Komandur
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
[
https://issues.apache.org/activemq/browse/AMQ-917?page=comments#action_36937 ]
Sridhar Komandur commented on AMQ-917:
--
If my original code is not the latest, please apply the changes as appropriate
Discovery Network Connector needs
James, Thanks for taking time to discuss this issue. Please see below:
On 8/10/06, James Strachan [EMAIL PROTECTED] wrote:
On 8/10/06, Komandur [EMAIL PROTECTED] wrote:
1. can we use an 'elastic prefetch' buffer based on a sliding window
(like
in TCP) - this reacts to client
Add dynamic 'prefetch window' management ...
-
Key: AMQ-873
URL: https://issues.apache.org/activemq/browse/AMQ-873
Project: ActiveMQ
Issue Type: Improvement
Reporter: Sridhar Komandur
[
https://issues.apache.org/activemq/browse/AMQ-850?page=comments#action_36732 ]
Sridhar Komandur commented on AMQ-850:
--
James/Hiram,
Here is another proposal for fixing this issue.
At a high level, we need break the coupling between
Team,
I had a question regarding the code below - doTimeKeepingServices() is
called the very first time and
then it is waiting on mcast.receive - so it will advertize itself after
hearing from another broker, assuming keepAliveInterval
has elapsed.
Should we instead run doTimeKeepingServices on
Thanks Hiram. Yes, I did that and got it working.
(I retracted the posting from the Nabble web site, but I guess it was
already forwarded)
On 8/3/06, Hiram Chirino [EMAIL PROTECTED] wrote:
Hi Komandur,
As long as your META-INF directory is in the classpath it should get
picked up. Please
I like the idea of broker-broker synchronization. One of the issues to
resolve is how reliable this synch activity needs to be ? A transactional
approach is too heavy weight for the common case.
I think a middle ground based on TCP may be good enough. We can divide the
synchronization into two
to process the old messeges later for recovery purposes
Regards
- Sridhar
Thanks.
Ning
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Sridhar Komandur
Sent: Wednesday, March 08, 2006 9:59 AM
To: activemq-dev@geronimo.apache.org
Subject: Re: improve
gives us an opportunity to evaluate if the pain of pausing the clients is
worth the additional complexity.
Regards
- Sridhar
I
On 8 Mar 2006, at 19:28, Sridhar Komandur wrote:
On 3/8/06, Ning Li [EMAIL PROTECTED] wrote:
Bulk synch is a good idea, I think we can find a way to do
of hardware, in a majority of cases.
Thanks
Regards
- Sridhar
On 3/8/06, Sridhar Komandur [EMAIL PROTECTED] wrote:
I agree that bulk synch first and then enabling dynamic synch cuts on down
complexity.
Please see answers inline ...
On 3/8/06, Rob Davies [EMAIL PROTECTED] wrote
20 matches
Mail list logo
