[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Message Chunking
by ataylor
anonymous wrote : I think it's the packet's responsibility to know how to encode itself, whether it encodes itself into one messagingbuffer (normal packet) or many (large message) is behaviour of the packet.
Ok, i can move this.
anonymous wrote : For large messages it's important we don't re-encode since that's a lot of copying.
| If the logic for encoding is inside the packet, then it can make the decision at send time whether to just use the message's current buffers as is (for large messages) or re-encode them into another buffer (e.g. small messages).
|
| Again, this is up to the packet how it wants to encode itself.
ok, again i can change this, I'll add some threshold level, i.e. if body < x add to original buffer.
anonymous wrote : I don't think that is true. The decoded message can just maintain a list of messagingbuffers and a pointer (int) to a position in the first buffer where the data starts. Different messges can point to the same buffers if there are many messages in the same buffer. I don't think there is any need for re-assembling there.
I think the point is that we cant decode the message until the last fragment has arrived. so we need to cache these buffers somewhere until we are ready.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167875#4167875
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167875
16 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Message Chunking
by timfox
"ataylor" wrote :
| could do, but i don't think the Packet should care about how messages are broken up.
|
I think it's the packet's responsibility to know how to encode itself, whether it encodes itself into one messagingbuffer (normal packet) or many (large message) is behaviour of the packet.
anonymous wrote :
| yes, at the minute they do. this still needs changing. Doing it this way tho' means that every message is still split up into 2 messages since the body is always written before the packet headers etc. I was thinking about changing it so the body is encoded at the time of sending the message.
|
For large messages it's important we don't re-encode since that's a lot of copying.
If the logic for encoding is inside the packet, then it can make the decision at send time whether to just use the message's current buffers as is (for large messages) or re-encode them into another buffer (e.g. small messages).
Again, this is up to the packet how it wants to encode itself.
anonymous wrote :
| we need somewhere to hold the fragment info, ie packet id, correlation id etc.
|
packet id is already written to the buffer, all we need to write is a boolean flag saying "lastPacket", if true then the server knows it's received all fragments. I don't think we need another class to do that, it's just an extra writeBoolean/readBoolean when encoding/decoding.
anonymous wrote :
| we need to reassemble them as we need to know which packet they belong to, and need to wait for all the fragments to arrive before decoding. remember there may be fragments from many packets interleaved in a buffer.
|
I don't think that is true. The decoded message can just maintain a list of messagingbuffers and a pointer (int) to a position in the first buffer where the data starts. Different messges can point to the same buffers if there are many messages in the same buffer. I don't think there is any need for re-assembling there.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167873#4167873
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167873
16 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Message Chunking
by ataylor
anonymous wrote : I have to say I don't really understand why you don't just put the conversion to List in the encode method of the Packet - not sure I see that PacketAssembler/Disassembler is necessary.
could do, but i don't think the Packet should care about how messages are broken up.
anonymous wrote : Another observation is that messages are just being re-encoded into several buffers. The original idea here was to write directly into the messages own buffers when the user builds the message and then just use that when writing to the wire - no re-writing necessary.
yes, at the minute they do. this still needs changing. Doing it this way tho' means that every message is still split up into 2 messages since the body is always written before the packet headers etc. I was thinking about changing it so the body is encoded at the time of sending the message.
anonymous wrote : I'm nor sure we need PacketFragment either - can't we just use MessagingBuffer?
we need somewhere to hold the fragment info, ie packet id, correlation id etc.
anonymous wrote : Regarding re-assembling, I'm not sure this is necessary either since when reading several packets off the wire to form a command we can just store the actual buffers, no need to re-assemble?
we need to reassemble them as we need to know which packet they belong to, and need to wait for all the fragments to arrive before decoding. remember there may be fragments from many packets interleaved in a buffer.
anonymous wrote : One thing I noticed is that RemotingServiceImpl and PacketAssemblerImpl have references to a PacketFragmentCache but don't do anything with it. This is a holder for WIP.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167869#4167869
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167869
16 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Some feedback on latest journal changes
by timfox
Clebert-
I've done a quick review of your latest changes, here are a few comments/questions:
1) I've made and committed several cosmetic changes - spacing, indentation etc.
2) final modifier was ommitted from many methods - I've added these and committed. Please remember to add these - they're very useful for catching bugs.
3) JournalImpl::disableautoreclaim - All attributes should be in the positive, not the negative as per discussion some time back.
4) JournalTransaction:commit, commented out line:
//throw new IllegalStateException("Cannot find add info " + n.b);
If the line is not needed any more, delete it, don't just comment it, or someone (like me) will wonder why it's still there
5) writeTransaction - why do we need to write a "transaction complete" record with all the ids?
6) @supressWarnings - why do we need this annotation?
7) long load(LoadManager reloadManager) throws Exception - this method is only called internally so don't add it to the public interface
8) JournalImpl::load:
if (recordType < ADD_RECORD || recordType > ROLLBACK_RECORD)
{
continue;
}
Why do we ignore these?
9) Please respect the correct sections of the file, public, private etc. e.g. debug() method in wrong section of the file
10) JournalTransaction::get/isInvalid - I can't see this is actually used for anything, and if it is used it should be volatile or synchronized since could be called by different threads.
11) lock.acquire should go outside of try block, like this:
lock.acquire should go outside the try block, like this:
lock.acquire
try
{
...
}
finally
{
lock.release();
}
12) The locking on the append methods is effectively making the journal single threaded. Is this deliberate?
13) Why addandGet(1) rather than incrementandGet().
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167851#4167851
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167851
16 years, 5 months
[Design of JBoss Build System] - Re: Using jdocbook
by Anne-Marie Barthe
Hello,
I am using jdocbook with a maven project.
My problem is the following : the tree structure of our projects is not compatible with the one used by default by the JDocbook plugin (like the path and name of the staging directory).
It is impossible to generate the documentations with pictures, using a CSS for the HTML generation, etc.
I tried a solution : I modified the sources of the JDocbook plugin. In the AbstractDocBookMojo class (package : org.jboss.maven.plugins.jdocbook), I removed the "@readonly" annotation.
So, I set my own name and path for this directory into the POM file (see configuration below). With this modification, the documentation is perfectly generated.
| <configuration>
| <imageResource>
| <directory>${basedir}/src/doc/resources/images</directory>
| </imageResource>
| <cssResource>
| <directory>${basedir}/src/doc/resources/css</directory>
| </cssResource>
|
| <!-- I have added this parameter to configure the path of stagingDirectory (which is no more "read only")-->
| <stagingDirectory>${basedir}/target/docbook/publish/resources</stagingDirectory>
|
| <sourceDirectory>${basedir}/src/doc/docbook/doc-en</sourceDirectory>
| <sourceDocumentName>dragon-doc.xml</sourceDocumentName>
| <publishDirectory>${basedir}/target/docbook/publish</publishDirectory>
|
| <formats>
| <format>
| <formatName>pdf</formatName>
| <stylesheetResource>file:${basedir}/tools/stylesheets/fo.xsl</stylesheetResource>
| <finalName>dragon-docbook-${version}.pdf</finalName>
| </format>
| <format>
| <formatName>html</formatName>
| <stylesheetResource>file:${basedir}/tools/stylesheets/html.xsl</stylesheetResource>
| <finalName>dragon-docbook-${version}.html</finalName>
| </format>
| </formats>
|
| <options>
| <xincludeSupported>true</xincludeSupported>
| <xmlTransformerType>saxon</xmlTransformerType>
| </options>
| </configuration>
|
I would know if the deleting of the "@readonly" has consequences on other classes, methods, etc. ?
In the future, the attribute stagingDirectory will be editable by the user ? Or will it remain with the "read only status" (if stagingDirectory will remain "read only", I will create a patch to be able to use it in our projects).
Thank you for your help !
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167834#4167834
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167834
16 years, 5 months