[Design of Messaging on JBoss (Messaging/JBoss)] - Re: LargeMessage & Failover Update
by timfox
"clebert.suconic(a)jboss.com" wrote : Say you are sending two large message with 2 chunks each.
|
| The client will send packets to the server on this order:
|
| SessionSendMessage A1 (header)
| SessionSendContinuationMessage A2 (chunk last=false)
| SessionSendcontinuationMessage A3 (chunk last=true)
|
| SessionSendMessage B1 (header)
| SessionSendContinuationMessage B2 (chunk last=false)
| SessionSendcontinuationMessage B3 (chunk last=true)
|
|
| The regular process on ServerSesionImpl should be:
|
| A1 received -> CurrentLargeMessage set on the Session
| A2 received -> add bytes on the currentLargeMessage
| A3 received -> add bytes on the currentLargeMessage, and route it, and clean currentLargeMessage
|
| B1 received -> CurrentLargeMessage set on Session
| B2 received -> add bytes
| B3 received -> add bytes, route and clean currentLargeMessage
|
|
| But when we are playing the replication, the flow is delayed and B1 could be received while A3 still being processed.
|
| I would get the destination from the currentLargeMessage, but I can't play with it as it could be changed in another thread.
|
| I could make it work nicely after finding a few NPEs here and there.. but the code would be cleaner if I could just wait the first and the last package return from the backup node in certain places.
No, you can't block for replication to complete, that would really slow things up. You would be limiting all message sending to the RTT of replication!
That's a pretty core principle and it applies to all commands, we shouldn't block replicating any commands.
Instead you should just store the LargeMessage in a ConcurrentQueue and pull it off as the replications come back. The replication will always come back in the correct order.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4202669#4202669
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4202669
17 years, 2 months
[Design of EJB 3.0] - EJB3 Timebox Release Schedule
by ALRubinger
What are we comfortable with?
Monday deadlines are attractive to me, as we could plan on starting releases Thursday/Friday, with some weekend time to address any last-minute problems. However, if we release on a *day* as opposed to a *date*, we run into the problem where there may be 5 Mondays in a month, leaving a gap of 3 weeks inbetween releases.
If we really wanted to stick to *days*, we could say "every other Monday". This gets confusing though, for the same reasons as above. Sometimes we'd release 1st, 3rd, 5th, sometimes 2nd, 4th, etc.
Alternatively we could commit to two *dates* in the month ie. 1st and 16th. Issues here are that these could land on weekends, make for inconvenient scheduling (I prefer to not interrupt the middle of my development week to release), etc.
My preference is for the 2nd and 4th Monday of the month. For starters, 1.0.0-GA should be ready on a 4th Monday. Sometimes we'll have a 3 week gap, but I think the extra week every now and then is nice, and worth it to provide an easy-to-remember commitment to our community that's based on days of the week, not date within the month.
For what it's worth, the City of Boston does street cleaning here on the 1st and 3rd Tuesday of each month. If we could align the release schedule to that, it be easy for me to remember: "Push the release, move the car".
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4202658#4202658
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4202658
17 years, 2 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: LargeMessage & Failover Update
by clebert.suconic＠jboss.com
Say you are sending two large message with 2 chunks each.
The client will send packets to the server on this order:
SessionSendMessage A1 (header)
SessionSendContinuationMessage A2 (chunk last=false)
SessionSendcontinuationMessage A3 (chunk last=true)
SessionSendMessage B1 (header)
SessionSendContinuationMessage B2 (chunk last=false)
SessionSendcontinuationMessage B3 (chunk last=true)
The regular process on ServerSesionImpl should be:
A1 received -> CurrentLargeMessage set on the Session
A2 received -> add bytes on the currentLargeMessage
A3 received -> add bytes on the currentLargeMessage, and route it, and clean currentLargeMessage
B1 received -> CurrentLargeMessage set on Session
B2 received -> add bytes
B3 received -> add bytes, route and clean currentLargeMessage
But when we are playing the replication, the flow is delayed and B1 could be received while A3 still being processed.
I would get the destination from the currentLargeMessage, but I can't play with it as it could be changed in another thread.
I could make it work nicely.. but the code would be cleaner if I could just wait the first and the last package return from the backup node in certain places.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4202648#4202648
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4202648
17 years, 2 months
[Design of JBoss Portal] - Re: Design of Portal Deployer
by mwringe
anonymous wrote :
| "mwringe" wrote :
| | But it does get a little tricky when the top deployment is the dependency of a child deployment, last I tried doing this it doesn' work as expected.
|
| Tricky how?
| What about if you change the deployer hierarchy order?
| e.g. setParentFirst == false
I must not understand this part enough. If I have a sar with a nested war, the war is sent to the tomcat deployer last no matter what parentfirst is set in the sar deployer.
Note that I tested this deploying the sar after the server has been started. If the sar is in the deploy directory as the server starts its behaves differently.
I have been trying it using the dependency deployer, but it doesn't work. If I specify I want the war to be deployed after the sar is done with the real stage, it fails since it can't find the sar dependency. It will work perfectly fine in the war is removed from the sar and is no longer nested.
I would prefer to use the dependency mechanism rather than changing the portal from a sar into something else with its own custom deployer, but I can if necessary.
anonymous wrote : "mwringe" wrote :
| |
| | FYI, the manipulation of deployer order based on another deployer's order is also used in a few other deployers in AS5.
| |
| Where? To kick some butt ... :-)
EARContentsDeployer and WebServiceDeployerPreJSE do at least. There could be others.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4202583#4202583
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4202583
17 years, 2 months