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...@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-tabpanelfocusedCommentId=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 EOF
com.sun.security.jgss.initiate {
com.sun.security.auth.module.Krb5LoginModule required useTicketCache=true;
};
EOF
pushd $EXAMPLE_PATH
find $EXAMPLE_PATH -iname *.class -exec rm -v {} \ /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
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
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: [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
[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-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] 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
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 rafa...@redhat.com 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
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: the broker memory leak?
i only run the example requestresponse, 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)ml-user+168305-213681...@n2.nabble.com; Date: 2009年4月17日(星期五) 晚上8:57 To: doublefox1981331847...@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: 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 linefrom 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
