Steve Huston wrote:
For some background info on Windows Schannel (the native SSL
implementation on Windows) I wrote a blog overview of it recently - you
may want to read that before the review meeting for this patch
(http://stevehuston.wordpress.com/2009/12/29/how-to-use-schannel-for-ssl
-sockets
Rajith Attapattu wrote:
IMO it's not a very accurate picture.
Well, we can debate whether the assortment of protocol support levels
actually
has that affect, but its not really important.
Having said that, there would still be quite a bit of work maintaining
them and we would need an owne
Aidan Skinner wrote:
On Thu, Dec 3, 2009 at 10:11 PM, James Mansion
wrote:
Eh, I don't really want to get rid of the actively maintained clients
we already have. In particular, Java and C# derive enormous benefits
from purely managed code in terms of portability, JITability etc.
Aidan Skinner wrote:
It's particularly important where we're importing something which
duplicates (fully or partially) existing functionality, if only so
that the situation is sufficiently clear to people trying to make an
informed decision about what best suits their needs.
Perhaps the QPID p
Jonathan Robie wrote:
In the languages besides Java, there is no standard messaging API to
fall behind. I'll say something more on Java in a separate message.
If its market share of deployed MOM components that lie strangely
unused, its MSMQ.
If market share of paid-for MOM matters, isn't MQSe
Kim van der Riet wrote:
IANAL, you may be correct. However, this decision was made about 2 years
ago out of an abundance of caution regarding non-apache-compatible
licenses. The reason LGPL was selected was that it is suited for use
with libraries (which this is - msgstore.so) which can be run ag
Kim van der Riet (JIRA) wrote:
They are encumbered with BDB, which is used to save the broker state. For this
reason, these files are LGPL
Why are they encumbered with BDB? You aren't redistributing BDB are you?
And even if you deem that referencing symbols in BDB is somehow
'redistribution'
Alan Conway wrote:
I will be moving the public header files into a separate qpid/include
directory tomorrow or the next day, I'm just ironing out glitches now.
The idea is to make it clear when we might be breaking source or
binary compatibility - if it's in include/ then there's a risk, if not
Gordon Sim wrote:
Alan Conway wrote:
// Pull style:
LocalQueue lq;
queue.subscribe(lq);
while (...) { Message m = lq.get(); ... }
// Push style
MyListener l;
queue.subscribe(l);
sessoin.run();
}
How does any of this integrate into a single-threaded application's
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 imp
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
Gordon Sim wrote:
James Mansion wrote:
Sure you couldn't have a C API that is closely based on the MQSeries
one, with extra tweaks?
Or a C++ API that is much like the COM API from MSMQ?
Both with extensions as needed.
These are the most widely deployed existing systems. Sure you&#
Gordon Sim wrote:
All queries, comments, criticisms etc are very welcome.
Sure you couldn't have a C API that is closely based on the MQSeries
one, with extra tweaks?
Or a C++ API that is much like the COM API from MSMQ?
Both with extensions as needed.
These are the most widely deployed exis
Gordon Sim wrote:
However, following the execution.exception is the session.detach as
required by the AMQP 0-10 spec. If the session goes out of scope
before this is handled, then the whole connection ends up being
destroyed due to the NotAttachedException thrown.
To me that suggests that some
[
https://issues.apache.org/jira/browse/QPID-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693993#action_12693993
]
James Mansion commented on QPID-1780:
-
I'm not sure the position is any bette
Gordon Sim wrote:
That is the intention. There are as you say a few AMQP specifics still
remaining (mainly around the protocol initiation header) that need to
be refactored out of this code and hidden behind the codec abstraction.
I had a quick try on the train the other day. Looks like there a
This code (Poller etc) is currently in common (at least on Windows) - which
also has a pile of AMQP-specific code.
Would anyone (else) like to have an organisation which would see it
usable as a simple general-purpose server core? Not least, this would
make it easier to test and measure it, or d
Robert Greig wrote:
JMS may not be perfect but I can just about guarantee that most of the
apps written in Java for Qpid using the JMS API will work just fine
when we release a Qpid broker than supports the 1-0 protocol. Who's
feeling confident about Python??
I'm surprised about that. Do you
chenta lee (JIRA) wrote:
[
https://issues.apache.org/jira/browse/QPID-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Is this the stuff that Red Hat is trying to patent?
James
-
Apache Qpid
Aidan Skinner wrote:
The Java client uses JMS for this to an extent, but we still need a
way of exposing AMQP specific things in ways that are as version
independent as possible (such as the mandatory flag).
I can see that there is value in reaching out to developers who have JMS
code or who
wis
Gordon Sim wrote:
For me the first part of the process is a protocol independent API and
some thinking around how to support multiple protocols in the broker
(allowing messages published over one protocol to be delivered over
another etc).
You mean an internal support API into which the 1.0 and
Gordon Sim wrote:
Based on past experience I think its best to wait until the final spec
is actually published before getting too concerned about an
implementation plan.
Its not long 'til then though - but I was actually more interested in
what the process will be, and who will manage and execu
Gordon Sim wrote:
James Mansion wrote:
The WindowsSasl implementation doesn't do anything Windows-ish. Why
isn't
this basic implementation the default if CyrusSasl is not available?
There is code in the ConnectionHandler that is intended to cover the
case where a specific Sasl
I notice that just as I start to try to understand the implementation,
the AMQP 1.0 spec is 'all change'. Well, significantly so it seems.
The current codebase doesn't seem entirely seperated between
the 'how' and the 'what' of the implementation - its not clear
how much will carry over into a 1
Steve Huston (JIRA) wrote:
The qpid/cpp/src/qpid/sys/windows/IntegerTypes.h file typedefs size_t. This is
not necessary for VC9, and the definition conflicts with the proper def for
64-bit builds. Removing the typedef for size_t works for both 32- and 64-bit
builds.
More to the point, why
Steve Huston wrote:
Fix is on svn trunk...
-Steve
How did you test it? It didn't work for me using the rather minimal
debug settings in the test_client solution.
My analysis of the failure is:
In WindowsSasl, if we have PLAIN on offer, then we choose it - even if we
do not have a configure
Steve Huston wrote:
Hi James,
This is a known issue: https://issues.apache.org/jira/browse/QPID-1733
I'm working on a fix for it.
Workaround is to start with broker with --auth no.
OK, thanks. Perhaps teh JIRA organisation could be improved? - the Java
tests have a JIRA
section and I look
Martin Ritchie wrote:
You don't mention which broker you are looking for details on.
Sorry - the C++ one. I'd use the comments - but they all seem to be
copyright
declarations. :-(
Except perhaps:
Is the comment about broken Thread::current in APR in qpid/sys/Thread.h
relevant any more?
I have tried to run client_test from cpp/src/tests.
The client is being rejected because it is trying to use an empty
mechanism and the server wants 'ANONYMOUS' or 'PLAIN'.
2009-mar-16 08:13:38 notice Broker running
2009-mar-16 08:14:18 debug RECV [127.0.0.1:1716] INIT(0-10)
2009-mar-16 08:14:18
Where to Jira?
I see:
ClientSessionTest.cpp
.\ClientSessionTest.cpp(149) : error C2447: '{' : missing function
header (old-style formal list?)
.\ClientSessionTest.cpp(170) : error C2447: '{' : missing function
header (old-style formal list?)
I'm using VS2008 with Boost 1.38, QPID_AUTO_TEST_C
Is there any documentation on the CPU flow inside the broker and the
major elements of the broker?
James
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpi
[
https://issues.apache.org/jira/browse/QPID-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Mansion updated QPID-1737:
Attachment: SIP.patch
Patch attached - replaces STATUS_INVALID_PARAMETER with
Steve Huston wrote:
Hi James,
Svn diff is perfect - thanks.
QPID-1737.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Environment: XP 32 bit with latest SDK from Microsoft (SDK 7 beta)
Reporter: James Mansion
I'm trying to build M4 of AMQP on XP with the Win7 SDK Beta, and I'm seeing that
Manageable::STATUS_INVALID_PARAMETER
is being expanded to:
Manageable::((DWORD )0xC00DL);
I thi
Steve Huston wrote:
Hi James,
This situation arose a few other times while I was porting Qpid to
Windows. The approach taken was to rename the item in Qpid to avoid
Microsoft's macro. I haven't tried anything related to Win7, so
haven't hit that one, but if you attach a patch to a JIRA entry, I'
I'm trying to build M4 of AMQP on XP with the Win7 SDK Beta, and I'm
seeing that
Manageable::STATUS_INVALID_PARAMETER
is being expanded to:
Manageable::((DWORD )0xC00DL);
I think this is because src\qpid/sys/windows/uuid.h has included rpc.h
and included a lot of the SDK as a result.
S
36 matches
Mail list logo
