Re: the broker memory leak?
i get the lated version of dotnet, and the follow the "dotnet\client-010\readme.txt", but when excute the codegen script, error occur. it says that "no module name templating", by this line"from templating import Parser". where can i obtain the templating module? -- View this message in context: http://n2.nabble.com/the-broker-memory-leak--tp2644394p2654274.html Sent from the Apache Qpid developers mailing list archive at Nabble.com. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: the broker memory leak?
i only run the example "request&response", the request peer use dotnet, and the response peer use c++, maybe some messages not acknowledged at dotnet. but i don't know howto. -- 何文辉 -- Original -- From: "Gordon Sim (via Nabble)"; Date: 2009年4月17日(星期五) 晚上8:57 To: "doublefox1981"<331847...@qq.com>; Subject: Re: the broker memory leak? doublefox1981 wrote: > i test my application, but found the c++ broker memory increase all the time. > > and in my client show that: > > 2009-apr-17 11:22:02 warning Exception received from broker: > resource-limit-exceeded: resource-limit-exceeded: Policy exceeded on > client199cf78d1-16d46-14f9c-1b597-113272b5a1a9b by message 1895 of size 55358 > , policy: size: max=104857600, current=104848052; count: unlimited; > type=flow_to_disk (qpid/broker/QueuePolicy.cpp:90) [caused by 2748379 > \x00:\x00] > terminate called after throwing an instance of > 'qpid::framing::ResourceLimitExceededException' > what(): resource-limit-exceeded: resource-limit-exceeded: Policy exceeded > on client199cf78d1-16d46-14f9c-1b597-113272b5a1a9b by message 1895 of size > 55358 , policy: size: max=104857600, current=104848052; count: unlimited; > type=flow_to_disk (qpid/broker/QueuePolicy.cpp:90) This means that you are enqueing faster than you are dequeing, the queue is growing continually and eventually reaches the default size limit. You can change the size limit, but perhaps there is something not working in the application. Are all messages that are sent being received and acknowledged? - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@... This email is a reply to your post @ http://n2.nabble.com/the-broker-memory-leak--tp2644394p2649730.html You can reply by email or by visting the link above. -- View this message in context: http://n2.nabble.com/the-broker-memory-leak--tp2644394p2654268.html Sent from the Apache Qpid developers mailing list archive at Nabble.com.
Re: [c++]: Sketch of a high-level, protocol independent API
Rafael Schloming wrote: > (good stuff) What he said, +1. Unfortunately, as it were, if you want to go there, don't start from here. Alan, Gordon: How are you expecting flow of control to work wrt number of driver threads and flow of control in any callbacks? This is arguably a lot more important than whether the API has a C or C++ flavour. James - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [c++]: Sketch of a high-level, protocol independent API
I like Rafi's idea. As I have advocated before, the most compelling reason to make a C API is the ability to support dynamic languages. Given the popularity of dynamic languages this would be a very important step in taking Qpid to the masses. This approach would allow us to maintain several dynamic language bindings with reasonable effort after the initial investment of getting a well defined compact C library. Projects like Axis2/C has had good sucess using the above approach + swig for their dynamic language support. I also like the protocol engine to not impose any threading model which then gives the particular language binding the freedom to work with a threading model that best fits it's need. For those familar with Java, an example would be the javax.net.ssl.SSLEngine which provides SSL support and is somewhat conceptually similar to what Rafi is proposing. Regards, Rajith On Fri, Apr 17, 2009 at 9:22 AM, Rafael Schloming wrote: > Alan Conway wrote: >> >> Given the current state of affairs I'd say the following is the most >> likely path to a C API: >> >> 1. Clean up, simplify and remove protocol-specifics from the C++ API. Use >> handles to hide impls (in particular PIMPL the Message class) use a single >> callback interface (MessageListener) >> >> 2. Implement a C API over this C++ API for scripting languages, C projects >> etc. >> >> 3. (maybe) bless the C API and move it inwards to the heart of the client >> lib, move more of the client lib to C. Not clear (to me) if this is going to >> be desirable but once we have a C API it becomes easier to weigh the pros & >> cons. > > My reason for being interested in a C API is for something to be embeddable > from python/ruby/php/perl/etc, as well as something that is suitable for > embedding inside both a client and a broker, and I'm not convinced the above > approach is enough to result in something that is useful for that sort of > thing. > > For embeddability what we need is a strong separation between the active and > passive portions of the code, i.e. the client needs to be structured as a > passive "protocol engine" and an active "driver". The protocol engine gets > fed bytes/frames/etc on its input and produces high level events on its > output, and the driver is responsible for feeding the protocol engine bytes > and processing any high level events that result. > > This split captures all the complex protocol logic into a single embeddable > piece, but doesn't force a threading and/or (b)locking model onto the > embedding application, e.g. I can embed the protocol engine easily inside a > broker and client and use a nonblocking driver in the former case and a > blocking driver in the latter case. > > This also has the benefit of avoiding callbacks across bindings since the > protocol engine will only ever produce events when it is fed data, so the > driver can easily check for and dispatch events without relying on > callbacks. This is a fairly critical feature for embeddability, it means we > can do things like trivially use swig to expose the protocol engine in just > about any language, and then integrate with the native threading constructs > available in that language, e.g. I can use realtime threads in RT Java if I > want to. > > --Rafael > > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1822) stop copying jmx management console libs to 'build/lib' dir
[ https://issues.apache.org/jira/browse/QPID-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Gemmell updated QPID-1822: - Priority: Trivial (was: Minor) Assignee: Aidan Skinner (was: Robert Gemmell) Hi Aidan, can you review this change please, thanks. > stop copying jmx management console libs to 'build/lib' dir > --- > > Key: QPID-1822 > URL: https://issues.apache.org/jira/browse/QPID-1822 > Project: Qpid > Issue Type: Task > Components: Ant Build System, Java Management : JMX Console >Reporter: Robert Gemmell >Assignee: Aidan Skinner >Priority: Trivial > > The build system copies the libs for each module into the 'build/lib' dir > during the build process. The JMX management console build process does not > use the libs from this dir (and moreso, the layout in which they are copied > there is useless) as only the core plugin is created in the directory, with > the full platform-specific console packages created in the plugins own > release subdirectory. > As such, we should stop copying jmx management console libs to 'build/lib' > dir. -- 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-1822) stop copying jmx management console libs to 'build/lib' dir
[ https://issues.apache.org/jira/browse/QPID-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Gemmell updated QPID-1822: - Status: Ready To Review (was: In Progress) > stop copying jmx management console libs to 'build/lib' dir > --- > > Key: QPID-1822 > URL: https://issues.apache.org/jira/browse/QPID-1822 > Project: Qpid > Issue Type: Task > Components: Ant Build System, Java Management : JMX Console >Reporter: Robert Gemmell >Assignee: Robert Gemmell >Priority: Minor > > The build system copies the libs for each module into the 'build/lib' dir > during the build process. The JMX management console build process does not > use the libs from this dir (and moreso, the layout in which they are copied > there is useless) as only the core plugin is created in the directory, with > the full platform-specific console packages created in the plugins own > release subdirectory. > As such, we should stop copying jmx management console libs to 'build/lib' > dir. -- 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-1822) stop copying jmx management console libs to 'build/lib' dir
stop copying jmx management console libs to 'build/lib' dir --- Key: QPID-1822 URL: https://issues.apache.org/jira/browse/QPID-1822 Project: Qpid Issue Type: Task Components: Ant Build System, Java Management : JMX Console Reporter: Robert Gemmell Assignee: Robert Gemmell Priority: Minor The build system copies the libs for each module into the 'build/lib' dir during the build process. The JMX management console build process does not use the libs from this dir (and moreso, the layout in which they are copied there is useless) as only the core plugin is created in the directory, with the full platform-specific console packages created in the plugins own release subdirectory. As such, we should stop copying jmx management console libs to 'build/lib' dir. -- 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-1821) Session state is not cleared properly after failover
Session state is not cleared properly after failover Key: QPID-1821 URL: https://issues.apache.org/jira/browse/QPID-1821 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.5, 0.6 Reporter: Aidan Skinner Fix For: 0.6 Session state is not cleared properly after fail over which causes NoLocalAfterRecoveryTest to fail sometimes. -- 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-1820) Dynamically created queues do not inherit queue alerting settings
Dynamically created queues do not inherit queue alerting settings - Key: QPID-1820 URL: https://issues.apache.org/jira/browse/QPID-1820 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.5 Reporter: Aidan Skinner Assignee: Aidan Skinner Priority: Critical Fix For: 0.5 AMQQueueFactory.createAMQQueueImpl does not correctly configure the queue when it's created -- 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: [c++]: Sketch of a high-level, protocol independent API
Alan Conway wrote: Given the current state of affairs I'd say the following is the most likely path to a C API: 1. Clean up, simplify and remove protocol-specifics from the C++ API. Use handles to hide impls (in particular PIMPL the Message class) use a single callback interface (MessageListener) 2. Implement a C API over this C++ API for scripting languages, C projects etc. 3. (maybe) bless the C API and move it inwards to the heart of the client lib, move more of the client lib to C. Not clear (to me) if this is going to be desirable but once we have a C API it becomes easier to weigh the pros & cons. My reason for being interested in a C API is for something to be embeddable from python/ruby/php/perl/etc, as well as something that is suitable for embedding inside both a client and a broker, and I'm not convinced the above approach is enough to result in something that is useful for that sort of thing. For embeddability what we need is a strong separation between the active and passive portions of the code, i.e. the client needs to be structured as a passive "protocol engine" and an active "driver". The protocol engine gets fed bytes/frames/etc on its input and produces high level events on its output, and the driver is responsible for feeding the protocol engine bytes and processing any high level events that result. This split captures all the complex protocol logic into a single embeddable piece, but doesn't force a threading and/or (b)locking model onto the embedding application, e.g. I can embed the protocol engine easily inside a broker and client and use a nonblocking driver in the former case and a blocking driver in the latter case. This also has the benefit of avoiding callbacks across bindings since the protocol engine will only ever produce events when it is fed data, so the driver can easily check for and dispatch events without relying on callbacks. This is a fairly critical feature for embeddability, it means we can do things like trivially use swig to expose the protocol engine in just about any language, and then integrate with the native threading constructs available in that language, e.g. I can use realtime threads in RT Java if I want to. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [c++]: Sketch of a high-level, protocol independent API
Gordon Sim wrote: Alan Conway wrote: On Wed, 2009-04-15 at 15:37 +0100, Gordon Sim wrote: I don't see view this work as replacing the existing API. I think it is simply at a higher level of abstraction. I see a role for a 'mid-level' API that provides full access to what the protocol can do, without being tied to the protocol details. That's pretty much what I am aiming for also. We probably need to dig into some specifics to understand the different approaches we each have in mind. The 0-10 specific API will still be supported and can I think be considered stable. The initial implementation of the higher level API I sketched out uses the 0-10 specific API that we have almost without change. So are you thinking we'll implement the 0-10 API over the 1.0 protocol? No. I'd rather we get a more "neutral" API that's close enough to cover everything the protocol can do, but not tied to individual protocol commands. So you feel that my initial proposal is not close enough to allow applications to exploit particular aspects of the protocol? What sort of things are you thinking of there? There may well be something missing; it may also just be the incompleteness of the sketch. Partly that - we need to cover flow control, Futures etc. Partly it's a vague worry that defining "high level" patterns of use may not provide access to the full power of the broker. A lot of AMQP's flexibility comes from allowing the users the freedome to create and bind queues and exchanges (even more so in 1.0 where its easy to compose "links" into networks). So I'm all for easy to use patterns for the common cases, but I think we still may still need to provide some more direct access to the notion of linking/binding (and to do it in a way that works for AMQP 0-10 and 1-0) - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [c++]: Sketch of a high-level, protocol independent API
Gordon Sim wrote: James Mansion wrote: Gordon Sim wrote: James Mansion wrote: My question is: why do you feel the need to create something materially different, and why in particular does a messaging API need to be much more complex for normal use? Could you elaborate a little on what aspect(s) you feel is/are much more complex? Well, I'd look to replace class instances with handles and collaps as many fancy option setting/getting functions to a simple interface that uses string property names and put/get. And I'd expose a C API as much as possible with limited use of callbacks and buffer assignments in the user code rather than having to ask the API to delete buffers (or, worse, assume that the user code and API are sharing a heap manager). I would also look to have the API buffer received messages and use the simplest notification mechanism available. So I'd suggest not starting with any fancy class structure at all, but first ask how you will integrate into applications' event loops. This is something that the MQ API is poor at from memory. Its not necessary for fancy stuff that configures special options to be fast, and having a very stable binary API is handy. Also having an API that can be trivially wrapped with Python CTypes or P/Invoke is handy - not least its also easy to wrap with other tools such as swig. Ok, so simple for you is avoiding fancy things, not just the ease of writing programs to the API? Thats certainly a fair point and I think a c API would be a great addition to the project. I'm still keen on a c++ API myself; it could at some point in the future be implemented on top of such a c API. Given the current state of affairs I'd say the following is the most likely path to a C API: 1. Clean up, simplify and remove protocol-specifics from the C++ API. Use handles to hide impls (in particular PIMPL the Message class) use a single callback interface (MessageListener) 2. Implement a C API over this C++ API for scripting languages, C projects etc. 3. (maybe) bless the C API and move it inwards to the heart of the client lib, move more of the client lib to C. Not clear (to me) if this is going to be desirable but once we have a C API it becomes easier to weigh the pros & cons. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: svn commit: r765286 - in /qpid/trunk/qpid/cpp/src/qpid/cluster: EventFrame.cpp Multicaster.h OutputInterceptor.cpp
Martin Ritchie wrote: Hi Alan, The Cruise Control boxes I keep an eye on are failing to build the C++ code after this commit: make[3]: *** No rule to make target `qpid/sys/LatencyMetric.cpp', needed by `qpid/sys/LatencyMetric.lo'. Stop. Are you also seeing this? I was, I duffed up that commit and missed some files. I comitted the rest shortly afterward. Things should be ok as of r765615, shout if not. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Issue Comment Edited: (QPID-1645) Kerberos auth support for the java client
[ https://issues.apache.org/jira/browse/QPID-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700101#action_12700101 ] Jan Sarenik edited comment on QPID-1645 at 4/17/09 2:51 AM: VERIFIED On RHEL4 and RHEL5 I have verified this using the following script: --- #!/bin/sh # # Prerequisities: # * broker has to be run with "qpidd --auth yes --realm EXAMPLE.COM" # * you have to get the ticket first # * packages (qpidd, krb5-*, cyrus-sasl-gssapi, qpid-java-*, # rhm-docs) EXAMPLE_PATH=/usr/share/doc/rhm-0.5/java EXAMPLE_LIST=`find $EXAMPLE_PATH -type f -name '*.java'` CLASSPATH=`find /usr/share/java -name '*.jar' | tr '\n' :` TMPFILE=`mktemp` PROPFILE=$EXAMPLE_PATH/org/apache/qpid/example/jmsexample/requestResponse/\ requestResponse.properties cat $PROPFILE > $TMPFILE sed -i "s|^\(connectionfactory.qpidConnectionfactory\).*$|\1 = amqp://testuser:t...@clientid/testpath?brokerlist='tcp://$HOSTNAME:5672'|" $PROPFILE cat > $EXAMPLE_PATH/myjas.conf < /dev/null & sleep 3 java \ -Djavax.security.auth.useSubjectCredsOnly=false \ -Djava.security.auth.login.config=myjas.conf \ -Dsun.security.krb5.debug=true \ -Dqpid.sasl_mechs="GSSAPI" \ -Dqpid.sasl_protocol=qpidd \ -Dqpid.sasl_server_name=$HOSTNAME \ -cp "$CLASSPATH" \ org.apache.qpid.example.jmsexample.requestResponse.Client killall java cat $TMPFILE > $PROPFILE rm -rfv $TMPFILE $EXAMPLE_PATH/myjas.conf --- was (Author: jasan): VERIFIED On RHEL4 and RHEL5 I have verified this using the following script: --- #!/bin/sh # # Prerequisities: # * broker has to be run with "qpidd --auth yes --realm EXAMPLE.COM" # * you have to get the ticket first # * packages (qpidd, krb5-*, cyrus-sasl-gssapi, qpid-java-*, # rhm-docs) EXAMPLE_PATH=/usr/share/doc/rhm-0.5/java EXAMPLE_LIST=`find $EXAMPLE_PATH -type f -name '*.java'` CLASSPATH=`find /usr/share/java -name '*.jar' | tr '\n' :` TMPFILE=`mktemp` PROPFILE=$EXAMPLE_PATH/org/apache/qpid/example/jmsexample/requestResponse/\ requestResponse.properties cat $PROPFILE > $TMPFILE sed -i "s|^\(connectionfactory.qpidConnectionfactory\).*$|\1 = amqp://testuser:t...@clientid/testpath?brokerlist='tcp://$HOSTNAME:5672'|" $PROPFILE cat > $EXAMPLE_PATH/myjas.conf < /dev/null javac -cp "$CLASSPATH" -sourcepath "$EXAMPLE_PATH" \ -d "$EXAMPLE_PATH" $EXAMPLE_LIST java \ -Djavax.security.auth.useSubjectCredsOnly=false \ -Djava.security.auth.login.config=myjas.conf \ -Dsun.security.krb5.debug=true \ -Dqpid.sasl_mechs="GSSAPI" \ -Dqpid.sasl_protocol=qpidd \ -Dqpid.sasl_server_name=$HOSTNAME \ -cp "$CLASSPATH" \ org.apache.qpid.example.jmsexample.requestResponse.Server \ &> /dev/null & sleep 3 java \ -Djavax.security.auth.useSubjectCredsOnly=false \ -Djava.security.auth.login.config=myjas.conf \ -Dsun.security.krb5.debug=true \ -Dqpid.sasl_mechs="GSSAPI" \ -Dqpid.sasl_protocol=qpidd \ -Dqpid.sasl_server_name=$HOSTNAME \ -cp "$CLASSPATH" \ org.apache.qpid.example.jmsexample.requestResponse.Client killall java cat $TMPFILE > $PROPFILE rm -rfv $TMPFILE $EXAMPLE_PATH/myjas.conf --- > Kerberos auth support for the java client > - > > Key: QPID-1645 > URL: https://issues.apache.org/jira/browse/QPID-1645 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: M4 >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > Fix For: 0.5 > > > Currently the 0-8 java client only supports PLAIN and cram-MD5 as > authentication mechanisms. > The 0-10 java client only uses PLAIN. > It would be good to add Keberos as an authentication mechanism to the java > client. -- 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-1645) Kerberos auth support for the java client
[ https://issues.apache.org/jira/browse/QPID-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700101#action_12700101 ] Jan Sarenik commented on QPID-1645: --- VERIFIED On RHEL4 and RHEL5 I have verified this using the following script: --- #!/bin/sh # # Prerequisities: # * broker has to be run with "qpidd --auth yes --realm EXAMPLE.COM" # * you have to get the ticket first # * packages (qpidd, krb5-*, cyrus-sasl-gssapi, qpid-java-*, # rhm-docs) EXAMPLE_PATH=/usr/share/doc/rhm-0.5/java EXAMPLE_LIST=`find $EXAMPLE_PATH -type f -name '*.java'` CLASSPATH=`find /usr/share/java -name '*.jar' | tr '\n' :` TMPFILE=`mktemp` PROPFILE=$EXAMPLE_PATH/org/apache/qpid/example/jmsexample/requestResponse/\ requestResponse.properties cat $PROPFILE > $TMPFILE sed -i "s|^\(connectionfactory.qpidConnectionfactory\).*$|\1 = amqp://testuser:t...@clientid/testpath?brokerlist='tcp://$HOSTNAME:5672'|" $PROPFILE cat > $EXAMPLE_PATH/myjas.conf < /dev/null javac -cp "$CLASSPATH" -sourcepath "$EXAMPLE_PATH" \ -d "$EXAMPLE_PATH" $EXAMPLE_LIST java \ -Djavax.security.auth.useSubjectCredsOnly=false \ -Djava.security.auth.login.config=myjas.conf \ -Dsun.security.krb5.debug=true \ -Dqpid.sasl_mechs="GSSAPI" \ -Dqpid.sasl_protocol=qpidd \ -Dqpid.sasl_server_name=$HOSTNAME \ -cp "$CLASSPATH" \ org.apache.qpid.example.jmsexample.requestResponse.Server \ &> /dev/null & sleep 3 java \ -Djavax.security.auth.useSubjectCredsOnly=false \ -Djava.security.auth.login.config=myjas.conf \ -Dsun.security.krb5.debug=true \ -Dqpid.sasl_mechs="GSSAPI" \ -Dqpid.sasl_protocol=qpidd \ -Dqpid.sasl_server_name=$HOSTNAME \ -cp "$CLASSPATH" \ org.apache.qpid.example.jmsexample.requestResponse.Client killall java cat $TMPFILE > $PROPFILE rm -rfv $TMPFILE $EXAMPLE_PATH/myjas.conf --- > Kerberos auth support for the java client > - > > Key: QPID-1645 > URL: https://issues.apache.org/jira/browse/QPID-1645 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: M4 >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > Fix For: 0.5 > > > Currently the 0-8 java client only supports PLAIN and cram-MD5 as > authentication mechanisms. > The 0-10 java client only uses PLAIN. > It would be good to add Keberos as an authentication mechanism to the java > client. -- 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
