[jira] Commented: (QPID-2861) JMS client needs to handle duplicate commands replayed after failover

2010-09-20 Thread Rajith Attapattu (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912816#action_12912816
 ] 

Rajith Attapattu commented on QPID-2861:


After investigation I found that the JMS client had infact replayed the 
ExchangeQuery command during failover which prompted the broker to send the 
exchange query result.
See QPID-2876 for more details.

> JMS client needs to handle duplicate commands replayed after failover
> -
>
> Key: QPID-2861
> URL: https://issues.apache.org/jira/browse/QPID-2861
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Reporter: Rajith Attapattu
>Assignee: Rajith Attapattu
>Priority: Critical
> Fix For: 0.7
>
>
> The c++ broker could resend commands after failover that is no longer valid 
> on the client side.
> The commands maybe invalid (removed from the internal map) for two reasons,
> 1. These commands could have been acted on the client side but were unable to 
> confirm to the broker before failover happened.
> 2. It could also that the c++ broker is actually sending commands that were 
> already acked due to a bug on the broker side.
> So far I haven't been able to conclusively determine which of the above is 
> causing the duplicate commands. 
> Since this is only surfaced very recently I am speculating that it is the 
> later as if it was the former then it would have been detected a lot earlier 
> as the JMS client lacked any error handling in this area.
> It could also be that the broker is replaying only responses to certain 
> commands like ExchangeQuery QueueQuery etc.. 
> These commands are sent by the JMS client only if the new addressing scheme 
> is used, hence the reason why this issue can be reproduced only  when the new 
> addressing syntax is used.
> Irrespective of whether it's a broker bug or not the Java client should be 
> able to handle this error. 
> For example the c++ broker seems to resend an ExchangeQueryResult after 
> failover, that had actually been sent to the client before failover. This 
> causes a NPE on the JMS client which doesn't get handled properly and 
> eventually kills the connection. This causes the client to retry the 
> connection which in turn causes errors like Session already attached.
> Ex.
> 2010-09-16 17:16:05 error Channel exception: session-busy: Session already 
> attached: gu...@qpid.b39ab79e-3df8-468a-96ce-9c38f469a551 
> (qpid/broker/SessionManager.cpp:55)
> 2010-09-16 17:16:05 error Channel exception: not-attached: Channel 4 is not 
> attached (qpid/amqp_0_10/SessionHandler.cpp:39)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Created: (QPID-2876) Design issues in Java client failover

2010-09-20 Thread Rajith Attapattu (JIRA) 
Design issues in Java client failover
-

 Key: QPID-2876
 URL: https://issues.apache.org/jira/browse/QPID-2876
 Project: Qpid
  Issue Type: Bug
  Components: Java Client
Reporter: Rajith Attapattu
Assignee: Rajith Attapattu
 Fix For: 0.7


The java client keeps AMQP commands in it's replay buffer in case it needs to 
replay them during failover.
However this could cause several issues. For example,

1. The failover code at the JMS layer recreates subscriptions after failing 
over to a new node. However if there were message subscriptions present in the 
replay buffer and were replayed after failing over it can cause the 
subscription attempt by the JMS layer to fail if using exclusive subscriptions.

2. If there were ExchangeQuery/QueueQuery (or any command that expects a 
response) gets replayed, it will cause the broker to respond, but the JMS 
client may not have the command in it's internal map that manages 
request-response coordination. This can cause errors. See QPID-2861

Since we are not implementing full session resume for the 0-10 client, I don't 
think there is any advantage in replaying anything other than the message 
transfers.
The JMS client should also attempt to shrink it's in doubt window by 
periodically calling flush to get the broker to confirm the completion of the 
commands.
This will prevent in message being duplicated unnecessarily.

There maybe a potential bug where the Java client may not be removing commands 
even after the broker confirming them. I will create a new JIRA if this is 
confirmed.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Commented: (QPID-2860) C++ hello_xml example receives all message content, not just what's wanted

2010-09-20 Thread Steve Huston (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-2860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912704#action_12912704
 ] 

Steve Huston commented on QPID-2860:


I think I know what's going on with this, but could someone with more exposure 
to the internals of qpidmessaging weigh in here please?

The qpid/cpp/examples/xml-exchange example works correctly (only the 
xquery-selected records are received). The differences I see between that 
example and hello_xml is that when the exchange is bound, the xquery entry in 
the arguments are encoded as str16 in the working example (using the older qpid 
client API) and vbin16 in hello_xml (using the new messaging API).


> C++ hello_xml example receives all message content, not just what's wanted
> --
>
> Key: QPID-2860
> URL: https://issues.apache.org/jira/browse/QPID-2860
> Project: Qpid
>  Issue Type: Bug
>  Components: Qpid Examples
>Affects Versions: 0.7
> Environment: Linux (RHEL 5), Qpid svn trunk, xerces-c-2.7.0-8.el5
>Reporter: Steve Huston
>Priority: Minor
>
> In using the qpid/cpp/examples/messaging/hello_xml.cpp example to figure 
> something out, I changed the sent message's  element to Boston. This 
> should cause the message to not pass the XQuery set in the receiver. But when 
> executed, the "Boston" message is still received.
> $ ./hello_xml
> Boston 
> (BOS)167035

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: qpid C++ broker cluster in centos 5.5

2010-09-20 Thread Alan Conway 

On 09/20/2010 03:50 PM, Tim Chen wrote:

Hi all,

I'm trying to test qpid C++ broker clustering using a VM hosting centOS 5.5.

Just running qpidd directly runs fine, so I did the following

1. install corosync/corosynclib/corosynclib-devel (1.2.7) from clusterlabs rhel 
5 repository

2. rebuilt qpid so it includes clustering support

3. setup /etc/corosync/corosync.conf, and added entry to uidgid.d.

4. start corosync

5. start qpid with

qpidd --cluster-name=test_cluster --auth=no

And I get the error messages:

[r...@t3 sbin]# ./qpidd --cluster-name=test_cluster --auth=no --no-data-dir
2010-09-20 12:48:58 notice Initializing CPG
2010-09-20 12:48:58 error Error during CPG shutdown: Cannot finalize CPG group 
test_cluster: try again (6)
2010-09-20 12:48:58 critical Unexpected error: Cannot join CPG group 
test_cluster: try again (6)

Nothing shows up in the corosync log file.

Anyone know what I'm doing wrong here?



It looks like you may already have covered this but double check with the 
checklist at

 https://cwiki.apache.org/qpid/starting-a-cluster.html
The selinux note might be relevant.

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

qpid C++ broker cluster in centos 5.5

2010-09-20 Thread Tim Chen 
Hi all,

I'm trying to test qpid C++ broker clustering using a VM hosting centOS 5.5.

Just running qpidd directly runs fine, so I did the following

1. install corosync/corosynclib/corosynclib-devel (1.2.7) from clusterlabs rhel 
5 repository

2. rebuilt qpid so it includes clustering support

3. setup /etc/corosync/corosync.conf, and added entry to uidgid.d.

4. start corosync

5. start qpid with 

qpidd --cluster-name=test_cluster --auth=no

And I get the error messages:

[r...@t3 sbin]# ./qpidd --cluster-name=test_cluster --auth=no --no-data-dir
2010-09-20 12:48:58 notice Initializing CPG
2010-09-20 12:48:58 error Error during CPG shutdown: Cannot finalize CPG group 
test_cluster: try again (6)
2010-09-20 12:48:58 critical Unexpected error: Cannot join CPG group 
test_cluster: try again (6)

Nothing shows up in the corosync log file.

Anyone know what I'm doing wrong here?

Thanks,

Tim


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Created: (QPID-2875) Federation route propagation tests fail occassionally.

2010-09-20 Thread Ken Giusti (JIRA) 
Federation route propagation tests fail occassionally.
--

 Key: QPID-2875
 URL: https://issues.apache.org/jira/browse/QPID-2875
 Project: Qpid
  Issue Type: Bug
  Components: Python Test Suite
 Environment: C++ broker
Reporter: Ken Giusti
Assignee: Ken Giusti
Priority: Trivial


Occasionally one or more of the C++ broker's dynamic federation tests will 
fail, usually when the system is under load with the following assertion 
message:

federation.FederationTests.test_dynamic_direct_route_prop
.
fail
Error during test:
  Traceback (most recent call last):
File
"/home/kgiusti/Desktop/work/qpid/cpp/src/tests/python/commands/qpid-python-test",
line 311, in run
  phase()
File
"/home/kgiusti/Desktop/work/qpid/cpp/src/tests/federation.py",
line 1059, in test_dynamic_direct_route_prop
  exchanges[3].msgRoutes))
File "/usr/lib64/python2.6/unittest.py", line 358, in failIfEqual
  (msg or '%r == %r' % (first, second))
  AssertionError: federation failed to route more msgs 20:10 10:20 10:10 10:10


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: Implementing clustering support for Qpid Java broker

2010-09-20 Thread Etienne Antoniutti Di Muro 
That would be very helpful to define either clustering goals,
and  what/how to replicate.

Thank you!
Etienne


On Mon, Sep 20, 2010 at 5:23 PM, Alan Conway  wrote:
> On 09/20/2010 11:05 AM, Kerry Bonin wrote:

> On portability: I think it would not be difficult to abstract the C++
> cluster to run over a different virtual synchrony library. If there is such
> a library on windows it would probably pay to make the existing code
> portable rather than fork a completely new cluster solution. It would be
> beneficial to have more people testing the same core cluster code rather
> than spreading the effort over separate code bases, and very beneficial to
> have  more eyes on that code.
>
> I'm getting together some thoughts on how the C++ cluster architecture code
> could be restructured for greater performance and maintainability which
> might be of interest. The general idea is to replicate a smaller and more
> clearly defined subset of broker state and to remove the need for identical
> ordering of messages on replicated queues. I'll try to get something written
> up this week.
>
>
> -
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>
>

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Created: (QPID-2874) Clustered broker crashes in assertion in cluster/ExpiryPolicy.cpp

2010-09-20 Thread Alan Conway (JIRA) 
Clustered broker crashes in assertion in cluster/ExpiryPolicy.cpp
-

 Key: QPID-2874
 URL: https://issues.apache.org/jira/browse/QPID-2874
 Project: Qpid
  Issue Type: Bug
  Components: C++ Clustering
Affects Versions: 0.6
Reporter: Alan Conway
Assignee: Alan Conway


>From us...@qpid.apache.org:

We have a Java node connecting to one of two Qpid brokers (0.5 or 0.6,
doesn't matter, we get the same) as a client of another Java node which 
acts
as the server. The client sends messages over a queue, awaiting a 
response
message from the server on a temporary queue. Both brokers use 
clustering
(and are part of the same cluster). At some point, after 1 to 3 
exchanges
between the client and server nodes, both Qpid brokers simply crash, 
without
any error being logged. Broker logfile is attached. The typical output 
that
appears in the broker log files - the last line in the log is always the
same, so it seems that the place at which the failure occurs is 
consistent.

Stack trace follows:

[r...@ca-mtl1-tric-01 .qpidd]# gdb /opt/qpid/current/sbin/qpidd core.6709
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5_5.2)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /opt/qpid/qpid-0.5/sbin/qpidd...done.
[New Thread 6732]
[New Thread 6727]
[New Thread 6721]
[New Thread 6710]
[New Thread 6709]

warning: .dynamic section for "/usr/lib/libplc4.so" is not at the expected 
address

warning: difference appears to be caused by prelink, adjusting expectations

warning: .dynamic section for "/usr/lib/libplds4.so" is not at the expected 
address

warning: difference appears to be caused by prelink, adjusting expectations

warning: .dynamic section for "/usr/lib/openais/libcpg.so.2" is not at the 
expected address

warning: difference appears to be caused by prelink, adjusting expectations
Reading symbols from /opt/qpid/current/lib/libqpidbroker.so.0...done.
Loaded symbols for /opt/qpid/current/lib/libqpidbroker.so.0
Reading symbols from /opt/qpid/current/lib/libqpidcommon.so.0...done.
Loaded symbols for /opt/qpid/current/lib/libqpidcommon.so.0
Reading symbols from /usr/lib/libboost_program_options.so.2...(no debugging 
symbols found)...done.
Loaded symbols for /usr/lib/libboost_program_options.so.2
Reading symbols from /usr/lib/libboost_filesystem.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libboost_filesystem.so.2
Reading symbols from /lib/libuuid.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libuuid.so.1
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /usr/lib/libsasl2.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libsasl2.so.2
Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libresolv.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from 
/opt/qpid/current/lib/qpid/daemon/replicating_listener.so...done.
Loaded symbols for /opt/qpid/current/lib/qpid/daemon/replicating_listener.so
Reading symbols from 
/opt/qpid/current/lib/qpid/daemon/replication_exchange.so...done.
Loaded symbols for /opt/qpid/current/lib/qpid/daemon/replication_exchange.so
Reading symbols from /opt/qpid/current/lib/qpid/daemon/acl.so...done.
Loaded symbols for /opt/qpid/current/lib/qpid/daemon/acl.so
Reading symbols from /opt/qpid/current/lib/qpid/daemon/ssl.so...done.
Loaded symbols for /opt/qpid/current/lib/qpid/daemon/ssl.s

Re: Implementing clustering support for Qpid Java broker

2010-09-20 Thread Lahiru Gunathilake 
On Mon, Sep 20, 2010 at 8:55 PM, Etienne Antoniutti Di Muro <
etienne.antoniu...@adaptivebytes.com> wrote:

> So maybe we ca do the reverse, i.e. build a single replication
> middleware serving both the C++ and Java
> brokers.
>
> +1

 I am not that happy with the C++ clustering implementation since it was
a nightmare to install corosync and other stuff to get it work. It would be
nice  if we can address clustering support for both brokers together.


Regards
Lahiru

> Such middleware can be built on top of a specific communication
> service layer, i.e. spread.
>
>
> Regards
> Etienne
>
>
>
> On Mon, Sep 20, 2010 at 5:05 PM, Kerry Bonin  wrote:
> > On the C++ Broker, just remember that the technology choice made for
> > clustering (OpenAIS/Corosync) is a Linux only solution, and that
> > codebase (~100k SLOC) was not written for portability.
> >
> > Our project needs a Windows option, and this is already hurting us.  I
> > (and my team) would be willing to spend some cycles supporting any
> > reasonable effort to address this, even if its not C++...
> >
> >
> > On Sun, Sep 19, 2010 at 4:18 AM, Lahiru Gunathilake 
> wrote:
> >> On Sun, Sep 19, 2010 at 11:37 AM, Etienne Antoniutti Di Muro <
> >> etienne.antoniu...@adaptivebytes.com> wrote:
> >>
> >>> Andrew,
> >>>
> >>> I'll have a look at services provided by Terracotta,
> >>> however at a first glance, I hit the search button on their site, with
> >>> 'virtual synchrony' - no result!
> >>> While if you google 'spread.org: virtual synchrony' -it's there.
> >>>
> >>> I'll take some time to investigate deeper into Terracotta services.
> >>>
> >>> However it all depends on what clustering is intended for.
> >>>
> >>> Moreover, in order to keep the project compact, does it make sense
> >>> building a java API
> >>> for the C++ broker clustering solution ?
> >>>
> >> I think there's C++ broker clustering already done ! I would like to use
> >> another Apache project like Tribes.
> >>
> >>
> >> Lahiru
> >>
> >> Lahiru
> >>
> >>>
> >>> Regards
> >>> Etienne
> >>>
> >>>
> >>> On Thu, Sep 16, 2010 at 8:57 AM, Andrew Kennedy
> >>>  wrote:
> >>> > On 15 Sep 2010, at 22:56, Etienne Antoniutti Di Muro wrote:
> >>> >>
> >>> >> However I do have some proposals, you can have a look here
> >>> >> http://portal.acm.org/citation.cfm?id=1101143
> >>> >>
> >>> >> As a starter, I'd need someone to help me understand Qpid
> architecture,
> >>> at
> >>> >> least an overview.
> >>> >
> >>> >
> >>> > For those of us that aren't paying for an ACM subscription, Etienne's
> >>> thesis
> >>> > is also available here:
> >>> >
> >>> >
> >>> >
> >>>
> http://middleware05.objectweb.org/WSProceedings/DoctoralSymposium05/a3-diMuro.pdf
> >>> >
> >>> > I think that functional homogeneity could probably be provided by
> >>> Terracotta
> >>> > or similar, but I am unsure of the licensing restrictions.
> >>> >
> >>> > Andrew.
> >>> > --
> >>> > -- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
> >>> >
> >>> > -
> >>> > Apache Qpid - AMQP Messaging Implementation
> >>> > Project:  http://qpid.apache.org
> >>> > Use/Interact: mailto:dev-subscr...@qpid.apache.org
> >>> >
> >>> >
> >>>
> >>> -
> >>> Apache Qpid - AMQP Messaging Implementation
> >>> Project:  http://qpid.apache.org
> >>> Use/Interact: mailto:dev-subscr...@qpid.apache.org
> >>>
> >>>
> >>
> >
> > -
> > Apache Qpid - AMQP Messaging Implementation
> > Project:  http://qpid.apache.org
> > Use/Interact: mailto:dev-subscr...@qpid.apache.org
> >
> >
>
> -
> Apache Qpid - AMQP Messaging Implementation
> Project:  http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>
>

Re: Implementing clustering support for Qpid Java broker

2010-09-20 Thread Etienne Antoniutti Di Muro 
So maybe we ca do the reverse, i.e. build a single replication
middleware serving both the C++ and Java
brokers.

Such middleware can be built on top of a specific communication
service layer, i.e. spread.


Regards
Etienne



On Mon, Sep 20, 2010 at 5:05 PM, Kerry Bonin  wrote:
> On the C++ Broker, just remember that the technology choice made for
> clustering (OpenAIS/Corosync) is a Linux only solution, and that
> codebase (~100k SLOC) was not written for portability.
>
> Our project needs a Windows option, and this is already hurting us.  I
> (and my team) would be willing to spend some cycles supporting any
> reasonable effort to address this, even if its not C++...
>
>
> On Sun, Sep 19, 2010 at 4:18 AM, Lahiru Gunathilake  wrote:
>> On Sun, Sep 19, 2010 at 11:37 AM, Etienne Antoniutti Di Muro <
>> etienne.antoniu...@adaptivebytes.com> wrote:
>>
>>> Andrew,
>>>
>>> I'll have a look at services provided by Terracotta,
>>> however at a first glance, I hit the search button on their site, with
>>> 'virtual synchrony' - no result!
>>> While if you google 'spread.org: virtual synchrony' -it's there.
>>>
>>> I'll take some time to investigate deeper into Terracotta services.
>>>
>>> However it all depends on what clustering is intended for.
>>>
>>> Moreover, in order to keep the project compact, does it make sense
>>> building a java API
>>> for the C++ broker clustering solution ?
>>>
>> I think there's C++ broker clustering already done ! I would like to use
>> another Apache project like Tribes.
>>
>>
>> Lahiru
>>
>> Lahiru
>>
>>>
>>> Regards
>>> Etienne
>>>
>>>
>>> On Thu, Sep 16, 2010 at 8:57 AM, Andrew Kennedy
>>>  wrote:
>>> > On 15 Sep 2010, at 22:56, Etienne Antoniutti Di Muro wrote:
>>> >>
>>> >> However I do have some proposals, you can have a look here
>>> >> http://portal.acm.org/citation.cfm?id=1101143
>>> >>
>>> >> As a starter, I'd need someone to help me understand Qpid architecture,
>>> at
>>> >> least an overview.
>>> >
>>> >
>>> > For those of us that aren't paying for an ACM subscription, Etienne's
>>> thesis
>>> > is also available here:
>>> >
>>> >
>>> >
>>> http://middleware05.objectweb.org/WSProceedings/DoctoralSymposium05/a3-diMuro.pdf
>>> >
>>> > I think that functional homogeneity could probably be provided by
>>> Terracotta
>>> > or similar, but I am unsure of the licensing restrictions.
>>> >
>>> > Andrew.
>>> > --
>>> > -- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
>>> >
>>> > -
>>> > Apache Qpid - AMQP Messaging Implementation
>>> > Project:      http://qpid.apache.org
>>> > Use/Interact: mailto:dev-subscr...@qpid.apache.org
>>> >
>>> >
>>>
>>> -
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project:      http://qpid.apache.org
>>> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>>>
>>>
>>
>
> -
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>
>

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: Implementing clustering support for Qpid Java broker

2010-09-20 Thread Alan Conway 

On 09/20/2010 11:05 AM, Kerry Bonin wrote:

On the C++ Broker, just remember that the technology choice made for
clustering (OpenAIS/Corosync) is a Linux only solution, and that
codebase (~100k SLOC) was not written for portability.

Our project needs a Windows option, and this is already hurting us.  I
(and my team) would be willing to spend some cycles supporting any
reasonable effort to address this, even if its not C++...



On portability: I think it would not be difficult to abstract the C++ cluster to 
run over a different virtual synchrony library. If there is such a library on 
windows it would probably pay to make the existing code portable rather than 
fork a completely new cluster solution. It would be beneficial to have more 
people testing the same core cluster code rather than spreading the effort over 
separate code bases, and very beneficial to have  more eyes on that code.


I'm getting together some thoughts on how the C++ cluster architecture code 
could be restructured for greater performance and maintainability which might be 
of interest. The general idea is to replicate a smaller and more clearly defined 
subset of broker state and to remove the need for identical ordering of messages 
on replicated queues. I'll try to get something written up this week.



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: Implementing clustering support for Qpid Java broker

2010-09-20 Thread Kerry Bonin 
On the C++ Broker, just remember that the technology choice made for
clustering (OpenAIS/Corosync) is a Linux only solution, and that
codebase (~100k SLOC) was not written for portability.

Our project needs a Windows option, and this is already hurting us.  I
(and my team) would be willing to spend some cycles supporting any
reasonable effort to address this, even if its not C++...


On Sun, Sep 19, 2010 at 4:18 AM, Lahiru Gunathilake  wrote:
> On Sun, Sep 19, 2010 at 11:37 AM, Etienne Antoniutti Di Muro <
> etienne.antoniu...@adaptivebytes.com> wrote:
>
>> Andrew,
>>
>> I'll have a look at services provided by Terracotta,
>> however at a first glance, I hit the search button on their site, with
>> 'virtual synchrony' - no result!
>> While if you google 'spread.org: virtual synchrony' -it's there.
>>
>> I'll take some time to investigate deeper into Terracotta services.
>>
>> However it all depends on what clustering is intended for.
>>
>> Moreover, in order to keep the project compact, does it make sense
>> building a java API
>> for the C++ broker clustering solution ?
>>
> I think there's C++ broker clustering already done ! I would like to use
> another Apache project like Tribes.
>
>
> Lahiru
>
> Lahiru
>
>>
>> Regards
>> Etienne
>>
>>
>> On Thu, Sep 16, 2010 at 8:57 AM, Andrew Kennedy
>>  wrote:
>> > On 15 Sep 2010, at 22:56, Etienne Antoniutti Di Muro wrote:
>> >>
>> >> However I do have some proposals, you can have a look here
>> >> http://portal.acm.org/citation.cfm?id=1101143
>> >>
>> >> As a starter, I'd need someone to help me understand Qpid architecture,
>> at
>> >> least an overview.
>> >
>> >
>> > For those of us that aren't paying for an ACM subscription, Etienne's
>> thesis
>> > is also available here:
>> >
>> >
>> >
>> http://middleware05.objectweb.org/WSProceedings/DoctoralSymposium05/a3-diMuro.pdf
>> >
>> > I think that functional homogeneity could probably be provided by
>> Terracotta
>> > or similar, but I am unsure of the licensing restrictions.
>> >
>> > Andrew.
>> > --
>> > -- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
>> >
>> > -
>> > Apache Qpid - AMQP Messaging Implementation
>> > Project:      http://qpid.apache.org
>> > Use/Interact: mailto:dev-subscr...@qpid.apache.org
>> >
>> >
>>
>> -
>> Apache Qpid - AMQP Messaging Implementation
>> Project:      http://qpid.apache.org
>> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>>
>>
>

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Updated: (QPID-2858) Implement FilterManager for 0-10 subscriptions

2010-09-20 Thread Sorin Suciu (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sorin Suciu updated QPID-2858:
--

Attachment: (was: qpid-2858.patch)

> Implement FilterManager for 0-10 subscriptions
> --
>
> Key: QPID-2858
> URL: https://issues.apache.org/jira/browse/QPID-2858
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: 0.7
>Reporter: Sorin Suciu
>Assignee: Andrew Kennedy
> Fix For: 0.7
>
> Attachments: qpid-2858_1.patch
>
>
> On 0-10 path, the subscriptions are created with a null FilterManager,

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Updated: (QPID-2858) Implement FilterManager for 0-10 subscriptions

2010-09-20 Thread Sorin Suciu (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sorin Suciu updated QPID-2858:
--

Attachment: (was: qpid-2858_1.patch)

> Implement FilterManager for 0-10 subscriptions
> --
>
> Key: QPID-2858
> URL: https://issues.apache.org/jira/browse/QPID-2858
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: 0.7
>Reporter: Sorin Suciu
>Assignee: Andrew Kennedy
> Fix For: 0.7
>
> Attachments: qpid-2858_1.patch
>
>
> On 0-10 path, the subscriptions are created with a null FilterManager,

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Updated: (QPID-2858) Implement FilterManager for 0-10 subscriptions

2010-09-20 Thread Sorin Suciu (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sorin Suciu updated QPID-2858:
--

Attachment: qpid-2858_1.patch

> Implement FilterManager for 0-10 subscriptions
> --
>
> Key: QPID-2858
> URL: https://issues.apache.org/jira/browse/QPID-2858
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: 0.7
>Reporter: Sorin Suciu
>Assignee: Andrew Kennedy
> Fix For: 0.7
>
> Attachments: qpid-2858_1.patch
>
>
> On 0-10 path, the subscriptions are created with a null FilterManager,

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Reopened: (QPID-2858) Implement FilterManager for 0-10 subscriptions

2010-09-20 Thread Robbie Gemmell (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell reopened QPID-2858:
--

  Assignee: Andrew Kennedy

The newly created FilterManager is not used, so the patches amount to a dead 
code block. The pre-checking and filtering of arguments (not sure the use of 
.getFields() is correct here, getArguments() possibly?) should not be necessary 
as the FilterManagerFactory does this itself.  The FilterManagerFactorycreation 
should have a method added that takes the argument Map instead of Fieldtable 
and then performs the necessary actions, so that functionality for creating 
FilterManagers is contained in the factory rather than the Subscription.

> Implement FilterManager for 0-10 subscriptions
> --
>
> Key: QPID-2858
> URL: https://issues.apache.org/jira/browse/QPID-2858
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: 0.7
>Reporter: Sorin Suciu
>Assignee: Andrew Kennedy
> Fix For: 0.7
>
> Attachments: qpid-2858.patch, qpid-2858_1.patch
>
>
> On 0-10 path, the subscriptions are created with a null FilterManager,

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org