[Design of Messaging on JBoss (Messaging/JBoss)] - Some thoughts on large messages and message chunking
by timfox
I've been thinking about what we're going to do about large messages and message chunking this morning, as this seems to have become a sticking point.
I'm conscious that the way we were trying to tackle the problem was perhaps too complex and trying to be "too clever". In large part this was probably my fault, not Andy's.
To get us moving I propose a solution that is simpler, and will not effect in any way (e.g. performance) the primary use case - that of non-large messages.
We can define a min large message size in bytes, call this ml above which any message is defined as large.
When sending a message, we simply check if message size is greater than ml. If false then message sending and delivery proceeds exactly as normal. If true, then we send a standard SendMessage packet, followed by n MessageContinuation packets which contains the rest of the message split into each packet.
This will involve some extra copying, but will only occur for the large message case, where high performance is probably not expected so much anyway. The user can also configure the value of ml for their system, so if they know they always send 16K messages, they can tune it appropriately to minimise copying.
In the SendMessage header we write an extra field "hasContinuations". If true it means the message is large and has extra continuation packets to follow.
Continuation packets can be interleaved on the remoting connection with other packets to prevent head-of-line blocking issues.
When the server receives a SendMessage it checks the hasContinuations field. If true then the message is large and won't be stored in the journal. Instead the message and its continuations will be stored in a file on disk, and a "pointer" to that file will be stored in the journal.
When a large message is delivered, again, it is delivered a set of packets not one, and the consumer can re-assemble the parts into a single message.
I think this solution is simply and more do-able than the previous.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4177865#4177865
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4177865
17 years, 3 months
[Design of EJB 3.0] - Re: EJBTHREE-1454 Encapsulate Container infomation in TO/VO
by jaikiran
"jaikiran" wrote :
|
| I am planning to summarize the exact changes and even upload the new patch to the JIRA in my next post.
|
|
I have uploded the patch "EJBTHREE-1454 with review comments incorporated.patch" to the JIRA. And here is a summary of what was changed:
1) New methods introduced in InvokableContext:
/**
| * Returns the initial context
| * @return
| */
| Context getInitialContext();
|
|
| /**
| * Returns the classloader associated with this {@link InvokableContext}
| * @return
| */
| ClassLoader getClassloader();
|
| /**
| * Returns the name of the container
| * @return
| */
| String getName();
|
| /**
| * Returns the global unique id of the container
| * @return
| */
| String getGuid();
|
| /**
| * Returns the advisor to use for generated proxies
| * @return
| */
| Advisor getAdvisor();
|
| /**
| * Returns the registration name with which the container
| * has been registered with AOP Dispatcher
| *
| * @return
| */
| String getDispatcherRegistrationName();
|
|
|
2) New interface InvokableSessionContext introduced. InvokableSessionContext extends InvokableContext and will contain session specific APIs. Ex:
/**
| * Returns the session bean metadata
| * @return
| */
| JBossSessionBeanMetaData getMetaData();
|
3) The SessionContainer (in proxy) and SessionSpecContainer (in core) now implement this InvokableSessionContext. These were earlier implementing InvokableContext.
4) The JndiSessionRegistrar* work with InvokableSessionContext
5) The *Session*ProxyFactory work with InvokableSessionContext whereas the ProxyFactoryBase uses the generic InvokableContext
6) The proxy/proxy-clustered internally use the getDispatcherRegistrationName() API to create the proxy factories. The SessionSpecContainer (in core) too uses this getDispatcherRegistrationName() to register with the AOP dispatcher.
7) Changed the pom in the proxy to build 1.0.7-SNAPSHOT. Changed the pom in core and proxy-clustered to depend on this new 1.0.7-SNAPSHOT from proxy.
Andrew,
I just noticed that there is a StatefulSessionInvokableContext (in proxy) which currently implements the InvokableContext. I guess, this should now implement the new InvokableSessionContext. Do you recommend that i change this too? The patch that i have applied to the JIRA "EJBTHREE-1454 with review comments incorporated.patch" does not include this one change. I will include this change during commit, if approved.
I have done a clean build of all the modules to ensure that all the test cases are passing after these changes. I see 1 testcase running into a error in embedded module, but its not related to this change.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4177863#4177863
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4177863
17 years, 3 months
[Design of JBoss Deployment Framework] - Re: Russian doll packaging in arbitrary directories - JBAS-5
by alesj
"alesj" wrote : I'll look into it a bit more. :-)
I've managed to see/find the problem.
Hacking this dir structure deployer deploys that 'broken' sar deployment:
| public class DirectoryStructure extends AbstractVFSStructureDeployer
| {
| public DirectoryStructure()
| {
| setRelativeOrder(Integer.MAX_VALUE);
| }
|
| public boolean determineStructure(StructureContext context) throws DeploymentException
| {
| try
| {
| VirtualFile file = context.getFile();
| // jar structure should already handle top level dirs
| if (context.isTopLevel() == false && isLeaf(file) == false && isMetadataPath(context) == false)
| {
| List<VirtualFile> children = file.getChildren();
| if (children != null && children.isEmpty() == false)
| {
| VFSStructuralDeployers structuralDeployers = context.getDeployers();
|
| // get top
| while (context.getParentContext() != null)
| context = context.getParentContext();
|
| for (VirtualFile child : children)
| structuralDeployers.determineStructure(child, context);
| }
| }
| return false;
| }
| catch (Exception e)
| {
| throw DeploymentException.rethrowAsDeploymentException("Error determining structure.", e);
| }
| }
|
| /**
| * Is the current context already part of metadata path.
| *
| * @param context the current structure context
| * @return true if already part of parent's context metadata path
| */
| protected boolean isMetadataPath(StructureContext context)
| {
| String relativePath = AbstractStructureDeployer.getRelativePath(context.getParent(), context.getFile());
| return "META-INF".equalsIgnoreCase(relativePath) || "WEB-INF".equalsIgnoreCase(relativePath);
| }
| }
|
But it looks too much of a hack. :-(
e.g. dunno how it would handle that top structure context search in some ear deployment
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4177841#4177841
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4177841
17 years, 3 months