I will need to recover my old-branch to give you some pointers about it…
I - A lot of the codecs are creating plenty of intermediate objects…
Pseudo-Example on the messageCodec: List… decodedProperties…
Message message = new Message(list.get(0), list.get(1)… );
it could be something done
On Dec 12, 2014, at 9:38 AM, Darryl L. Pierce dpie...@redhat.com wrote:
On Fri, Dec 12, 2014 at 01:43:45PM +, Gordon Sim wrote:
On 12/12/2014 12:16 PM, Darryl L. Pierce wrote:
I like the idea of pull requests and explicit peer reviews for changes.
But it's above my pay grade to do
On Dec 12, 2014, at 9:57 AM, Darryl L. Pierce dpie...@redhat.com wrote:
On Fri, Dec 12, 2014 at 09:48:05AM -0500, Clebert Suconic wrote:
In my experience there is no way to proper work with git without PRs and
peer review.. but that’s up to you guys.
I feel like my comment, which
On Dec 12, 2014, at 11:44 AM, Gordon Sim g...@redhat.com wrote:
On 12/12/2014 02:38 PM, Darryl L. Pierce wrote:
On Fri, Dec 12, 2014 at 01:43:45PM +, Gordon Sim wrote:
On 12/12/2014 12:16 PM, Darryl L. Pierce wrote:
I like the idea of pull requests and explicit peer reviews for
I agree and disagree with this simplistic position.
If (and only if) your task branch is yours and yours alone and no one
has ever relied on it then you can safely rebase it. Actually I find
that rebasing is a lot more useful to get my commits in a logical
sequence of smaller working
On Dec 12, 2014, at 2:44 PM, Andrew Stitcher astitc...@redhat.com wrote:
On Fri, 2014-12-12 at 14:21 -0500, Clebert Suconic wrote:
..
On the other hand I agree that merging from master just before merging
to master is irritating and pointless.
The apache master can’t be rebased… Period
Rebasing and pushing is not a good option IMO. We have been using pull requests
from GitHub and pushing them through Apache. It's working very well for us.
Committing directly to Apachea may get you these issues.
We can provide you guys more information on how we are doing on activemq6 if
We do a slightly different approach. If you guys are doing git I really think
you guys should consider it.
1. create a task branch : git checkout -b my-working-branch
2. create that voodoo that you do
3. when done, rebase your task branch on master : git rebase -i master
4. push to your
On Dec 11, 2014, at 5:11 PM, Darryl L. Pierce dpie...@redhat.com wrote:
On Thu, Dec 11, 2014 at 04:16:29PM -0500, Clebert Suconic wrote:
Rebasing and pushing is not a good option IMO. We have been using pull
requests from GitHub and pushing them through Apache. It's working very well
[
https://issues.apache.org/jira/browse/PROTON-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230092#comment-14230092
]
clebert suconic commented on PROTON-762:
couldn't you commit a compiled version
[X} Yes, release Proton 0.8 RC5 as 0.8 final
I tested 0.8 against the HornetQ trunk. Had to rename a few enums (SESSION_OPEN
to SESSION_LOCAL_OPEN) but other than that everything worked.
+1 (non binding I guess)
On Oct 23, 2014, at 12:21 PM, Rafael Schloming r...@alum.mit.edu wrote:
Hi Everyone,
I've put together RC4. This is pretty much the same as RC3 with a number of
fixes to disable those SSL versions that are vulnerable to attack.
The sources are available here:
if implemented at the proper place.
But if you already have a solution for that.. it's all good... thanks Robbie
Robbie
On 15 October 2014 15:15, Clebert Suconic csuco...@redhat.com wrote:
I think you should have an event for SASL_NEGOTATION.. or any name you
chose.. then you could negotiate
qpid JMS clients currently expect to send anonymous connection in the following
way:
- if the first frame has the SASL byte 3 (I'm not reading the spec now.. I'm
not sure the correct term), the server is supposed to initialize SASL on the
connection, transport... etc
In other terms, if the
+1 (mine it's a non binding vote.. but I wanted to register it since we have
been testing it for a while)
On Oct 14, 2014, at 4:44 PM, Rafael Schloming r...@alum.mit.edu wrote:
Hi Everyone,
I've put up 0.8 RC2 at the usual places. The source code can be found here:
If you want another example you can also look at the Proton integration I'm
doing at HornetQ:
https://github.com/hornetq/ProtonPlug
I made it to be pluggable with a minimal interface.. I don't think I will keep
it as a separate library.. but it could suite you as an example.
On Oct 2,
On Oct 2, 2014, at 1:01 PM, Bozo Dragojevic bo...@digiverse.si wrote:
On 2. 10. 14 17:31, Ernest Allen wrote:
Since the api-reconciliation tool is no longer viable, are there any example
java apps that use the engine api?
contrib/proton-hawtdispatch is also using the engine.
True,
This is also failing for me when I run the entire mvn install (after a mvn
clean).. it's not just on the CI for me
On Sep 25, 2014, at 2:20 PM, Robbie Gemmell robbie.gemm...@gmail.com wrote:
Failing in a different way now, the overall run of the python tests bombs
out. I see the same thing
This is just testing... can't you have a java7 tests folder? you would be able
to still have java7 specific tests.
On Sep 24, 2014, at 7:13 AM, Robbie Gemmell robbie.gemm...@gmail.com wrote:
Hi all,
With Qpid 0.30 we have made the move to requiring Java 7+. Currently,
proton still allows
[
https://issues.apache.org/jira/browse/PROTON-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14143232#comment-14143232
]
clebert suconic commented on PROTON-694:
I don't need an interface method here
[
https://issues.apache.org/jira/browse/PROTON-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14143239#comment-14143239
]
clebert suconic commented on PROTON-694:
this is the patch:
https://github.com
Can we get this one in:
https://github.com/clebertsuconic/qpid-proton/tree/PROTON-694
The current version always gets me a Bytearray through EncodedMessage while I
just need the ProtonJMessage for a later encoding when dealing with JMS
Conversions.
I have a patch linked on the issue.
On
[
https://issues.apache.org/jira/browse/PROTON-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14143502#comment-14143502
]
clebert suconic commented on PROTON-694:
I don't think it's double encoding
[
https://issues.apache.org/jira/browse/PROTON-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14143508#comment-14143508
]
clebert suconic commented on PROTON-694:
The previous version would do
[
https://issues.apache.org/jira/browse/PROTON-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic updated PROTON-694:
---
Attachment: diff.patch
splitting contrib/JMSMappingOutboundTransformer's encoding
[
https://issues.apache.org/jira/browse/PROTON-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14143589#comment-14143589
]
clebert suconic commented on PROTON-694:
I have squashed the change at
https
I have a commit that I would like to send towards a contrib component:
https://github.com/clebertsuconic/qpid-proton/commit/ab423a90f6b1e6d06c84615c5724497a3f9e8533
The current code is always encoding it as Bytes, and I need the ProtonJ as an
output on the case of the JMS component.
On Sep
I'm the project lead on hornetq and I'm currently writing the Proton
integration on HornetQ
Instead of keeping the integration bits internally on HornetQ, I have made the
Proton integration as a plugin, and maybe it could be reused for other projects
outside of RedHat scope.
This is
I'm looking into committing some stuff into hornetq next week that's highly
dependent on the current trunk.
However I don't have a space/policy in place currently for snapshots on our
trunk (It's hard / impossible to get the current release on history with
snapshots).
So, is there a way you
clebert suconic created PROTON-645:
--
Summary: Implement session flow control independently of
transport.capacity
Key: PROTON-645
URL: https://issues.apache.org/jira/browse/PROTON-645
Project: Qpid
[
https://issues.apache.org/jira/browse/PROTON-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14094565#comment-14094565
]
clebert suconic commented on PROTON-645:
Of course it could be the case that pop
[
https://issues.apache.org/jira/browse/PROTON-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14094563#comment-14094563
]
clebert suconic commented on PROTON-645:
*Producer = I'm describing this term here
commit ccb7b03b8089c2fea329d44cea5dc06da6345ea6
Author: Robert Gemmell rob...@apache.org
Date: Fri Jun 27 10:08:24 2014 +
PROTON-597: only release transport buffers if they are above a threshold
capacity
git-svn-id: https://svn.apache.org/repos/asf/qpid/proton/trunk@1606012
using large frame sizes
Change from Marcel Meulemans
git-svn-id: https://svn.apache.org/repos/asf/qpid/proton/trunk@1606010
13f79535-47bb-0310-9956-ffa450edef68
On Jul 2, 2014, at 11:40 AM, Clebert Suconic csuco...@redhat.com wrote:
commit ccb7b03b8089c2fea329d44cea5dc06da6345ea6
in with the property.
Robbie
On 2 July 2014 16:42, Clebert Suconic csuco...@redhat.com wrote:
Wrong commit...
this is the culprit:
commit 8fe9a12b1ad8dc9cd35324f4ed53bea9cb37ce22
Author: Robert Gemmell rob...@apache.org
Date: Fri Jun 27 10:07:47 2014 +
PROTON-597: update
On Jul 2, 2014, at 12:28 PM, Robbie Gemmell robbie.gemm...@gmail.com wrote:
Discussed with Clebert on IRC. There is a threshold where it changes
behaviour and that was set too low, so it has now been raised significantly
such that most people continue seeing the prior behaviour and those who
I have a case where I have a ByteBuffer (which could be a native buffer
(ByteBuffer.allocateNative (whatever method name that is)), and using the
decode (byte[] ) would make me duplicate the byte region.
Would be ok if someone merged this simple commit on qpid-proton-j? It's a very
simple
I just bumped into one issue (actually two issues) after this:
I - First HAWT-JMS is not working with trunk because the API is changed here. I
could change the API but now I have an issue that we can't commit the change
since there is no commit for this yet.
II - Using this Factory on the
t-jic...@microsoft.com
wrote:
Proton-j was my first choice but I was unable to connect to the
Azure Service Bus, which is my end goal. There are tutorials and
support for connecting proton-c to the azure service bus.
-Original Message-
From: Clebert Suconic [mailto:csuco
Wouldn't Proton-j be a better fit?
On May 28, 2014, at 8:45 PM, Jimmy Campbell t-jic...@microsoft.com wrote:
I am trying to get proton-c to run on android. Does anybody have any advice
or experience on the matter that I can get in contact with?
On May 14, 2014, at 1:36 PM, Rafael Schloming r...@alum.mit.edu wrote:
On Wed, May 14, 2014 at 1:05 PM, Clebert Suconic csuco...@redhat.comwrote:
I was just playing with possibilities and trying to find ways to improve
the API how things are done.
The interface is designed
I was just playing with possibilities and trying to find ways to improve the
API how things are done.
The interface is designed to
operate in terms of chunks of message data rather than in terms of an
entire message.
That's one thing that I'm lacking control through the API actually..
I have been playing with the API, and there is one change that would make the
API clearer IMO.
Right now you have to send a delivery, and then call send(bytes) to add Bytes
to the delivery what will make it copy data to the Delivery and self expand the
buffer.
I have played with a change
On May 13, 2014, at 1:46 PM, Rafael Schloming r...@alum.mit.edu wrote:
I'm not sure this will work as an API. One problem I see with this is that
it is circumventing the engine's flow control logic. If you notice there is
logic inside send() to update counters on the session. Unless I've
It seems the list is not working properly. sorry for the Spam but this is just
a test.. ignore it please
On May 5, 2014, at 5:02 PM, Rafael Schloming r...@alum.mit.edu wrote:
Hi Clebert,
Sorry for taking so long to follow up with the benchmark. I've been tweaking
it and using it to do some memory and CPU profiling.
The good news is I was able to significantly reduce memory utilization by
frameworks (e.g. Netty).
On May 5, 2014, at 5:40 PM, Clebert Suconic csuco...@redhat.com wrote:
On May 5, 2014, at 5:02 PM, Rafael Schloming r...@alum.mit.edu wrote:
Hi Clebert,
Sorry for taking so long to follow up with the benchmark. I've been tweaking
it and using it to do some memory
These shuld be all cleared now..
My github branch and PR are up to date now:
https://github.com/apache/qpid-proton/pull/1
And isn't git is beautiful. It's already rebased with Rafi's last commit!
On May 1, 2014, at 5:32 PM, Clebert Suconic csuco...@redhat.com wrote:
I will do some
[
https://issues.apache.org/jira/browse/PROTON-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987747#comment-13987747
]
clebert suconic commented on PROTON-576:
Why don't you add a test with your patch
[
https://issues.apache.org/jira/browse/PROTON-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13986807#comment-13986807
]
clebert suconic commented on PROTON-576:
Sounds a good idea.
Talking about
[
https://issues.apache.org/jira/browse/PROTON-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13986911#comment-13986911
]
clebert suconic commented on PROTON-576:
200 samples is a small number. you should
[
https://issues.apache.org/jira/browse/PROTON-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13986913#comment-13986913
]
clebert suconic commented on PROTON-576:
why don't you share your test here
30, 2014 at 2:15 PM, Clebert Suconic csuco...@redhat.comwrote:
I just submitted it as a git PR:
https://github.com/apache/qpid-proton/pull/1
On Apr 30, 2014, at 10:47 AM, Robbie Gemmell robbie.gemm...@gmail.com
wrote:
I think anyone can sign up for ReviewBoard themselves
Ah... I will fix the license headers shortly.
On May 1, 2014, at 4:51 PM, Clebert Suconic csuco...@redhat.com wrote:
For now I have pretty much optimized the Transfer type only. no other types.
for instance I see that Disposition type needs optimization as well...
For us though
:35 AM, Clebert Suconic csuco...@redhat.com
wrote:
@Rafi: I see there is a patch review process within Apache (based on
your
other thread on Java8)
Should we make this through the patch process at some point?
I'm fine looking at it on your git branch, but if you'd like to play
The only issue is that all the users using Proton-j would have to be at least
Java8.
For instance, I can have maybe my users using Java8 on the server, but they
won't migrate all their clients.
On Apr 30, 2014, at 6:48 AM, Rafael Schloming r...@alum.mit.edu wrote:
I forgot to mention, but
@Rafi: I see there is a patch review process within Apache (based on your
other thread on Java8)
Should we make this through the patch process at some point?
On Apr 29, 2014, at 4:04 PM, Clebert Suconic csuco...@redhat.com wrote:
On Apr 29, 2014, at 4:00 PM, Rafael Schloming r
to each other.
--Rafael
On Wed, Apr 30, 2014 at 8:33 AM, Clebert Suconic csuco...@redhat.comwrote:
The only issue is that all the users using Proton-j would have to be at
least Java8.
For instance, I can have maybe my users using Java8 on the server, but
they won't migrate all
milliseconds with raw reading
Notice that this will also minimize the footprint of the codec but I'm not
measuring that here.
I'm looking forward to work with this group, I actually had a meeting with Rafi
and Ted last week, and I plan to work closer to you guys on this
Clebert Suconic
On Apr 29, 2014, at 4:00 PM, Rafael Schloming r...@alum.mit.edu wrote:
Notice that this will also minimize the footprint of the codec but I'm not
measuring that here.
Just out of curiosity, when you say minimize the footprint, are you
referring to the in memory overhead, or do you mean
Thanks.. that's what I needed!
On Mar 21, 2014, at 9:06 AM, Ted Ross tr...@redhat.com wrote:
You have the option of leaving the target of a producer link empty and
putting the destination in the to field of each message sent on the link.
-Ted
On 03/20/2014 11:36 PM, Clebert Suconic
A common JMS feature is to have a Producer being anonymous and define the
address only when the message is sent.
We do the same on HornetQ core API.. However from my first look on the Proton
API I always need to define the source and the target?
Is there a way to define the destination per
to ConnectionImpl what breaks the
purpose of the interface. Can you guys move it?
--Rafael
On Mon, Mar 17, 2014 at 12:44 PM, Clebert Suconic csuco...@redhat.comwrote:
Why getWorkSequence is not exposed through Connection?
Forcing me to use getWorkHead() would make me re-implement the exact
Unfortunately there aren't docs for the Java version of the API yet, but it
shouldn't be difficult to figure out how to use it from the C API docs.
BTW I don't need the javadoc.. just point me what class are you talking about
and I will figure out
Right now my implementation is forced to cast to ConnectionImpl what
breaks the purpose of the interface. Can you guys move it?
I'm happy to accept a patch for it, although I'd encourage you to check out
the events stuff in any case.
--Rafael
I sure will take a look on the events
Why getWorkSequence is not exposed through Connection?
Forcing me to use getWorkHead() would make me re-implement the exact same
Iterator that's being implemented at ConnectionImpl(); Why not just expose it
properly? Iterators are common practice in Java anyways.
66 matches
Mail list logo
