January 2009 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: servlet transport implementation

by trustin

"ataylor" wrote : "trustin" wrote : It could be distributed as a separate WAR, hence we could create a subproject under svn.jboss.org/repos/netty/subproject/servlet (or some cool name :-) | Ok, that will give it seperation and make it easier to deploy. what would you like to call the sub project? http-tunnel, named after stunnel (http://www.stunnel.org/). WDYT? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201985#4201985 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201985

17 years, 2 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 2: Servlet Invoker

by ron.sigal＠jboss.com

Who can complete: anonymous wrote : | He will drink his super sauce | And throw the bad guys for a loss | He will bring them in alive and kickin' | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201958#4201958 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201958

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: LargeMessage & Failover Update (Repost)

by clebert.suconic＠jboss.com

- If we wait the replicatePacket to finish, largeMessageDeliver.deliver will be done asynchronously | private void deliverLargeMessage(final MessageReference ref, final ServerMessage message) | { | ..... | | | if (!replicating) | largeMessageDeliver.deliver(); // synchronous call when not replicating | | else | result.setResultRunner(new Runnable() // asynchronous call when replicating | { | public void run() | { | largeMessageDeliverer.deliver(); | } | | }); | } | - the method doHandle which is calling deliverLargeMessage, will return immediately, while the server is still deliveringChunks to the client. (promptDelivery BTW will try to send another message to the consumer, but it will be rejected as BUSY) - As the ServerSessionPacketHandler is free, credits will arrive concurrently with the delivery to the client, instead coming after deliver returned. This following logic on receiveCredits will not work: | public void receiveCredits(final int credits) throws Exception | { | if (credits == -1) | { | // No flow control | availableCredits = null; | } | else | { | int previous = availableCredits.getAndAdd(credits); | | if (previous <= 0 && previous + credits > 0) | { | promptDelivery(); // this is what would resume the delivery of the largeMessage | } | else | { | log.info("Previous was not 0"); | } | } | } | - because of the credits coming on a different order than how they would usually come, the delivery of messages is interrupted. We will get the credit before they became negative.. so nothing will resume delivery. If we called largeMessageDeliver.deliver() synchronously the credits would only arrive at the right time and the resume would work without any problem. - We could of course place the receiveCredits on an executor, scheduling the credit to be added as soon as the largeMessageSender is finished, or play with locks, but that seems weird to me and besides would cause implications on the regular use-case which is sending regular messages. Making the call to largeMessageDeliverer.deliver synchronously would be the easiest solution, where I don't need to use any locks or executors, and believe on the natural order of credits that are coming from the client. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201951#4201951 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201951

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: LargeMessage & Failover Update

by clebert.suconic＠jboss.com

- If we wait the replicatePacket to finish, largeMessageDeliver.deliver will be done asynchronously | private void deliverLargeMessage(final MessageReference ref, final ServerMessage message) | { | ..... | | | if (!replicating) | largeMessageDeliver.deliver(); // synchronous call when not replicating | | else | result.setResultRunner(new Runnable() // asynchronous call when replicating | { | public void run() | { | largeMessageDeliverer.deliver(); | } | | }); | } | - the method doHandle which is calling deliverLargeMessage, will return immediately, while the server is still deliveringChunks to the client. (promptDelivery BTW will try to send another message to the consumer, but it will be rejected as BUSY) - As the ServerSessionPacketHandler is free, credits will arrive concurrently with the delivery to the client, instead coming after deliver returned. This following logic on receiveCredits will not work: | public void receiveCredits(final int credits) throws Exception | { | if (credits == -1) | { | // No flow control | availableCredits = null; | } | else | { | int previous = availableCredits.getAndAdd(credits); | | if (previous <= 0 && previous + credits > 0) | { | promptDelivery(); // this is what would resume the delivery of the largeMessage | } | else | { | log.info("Previous was not 0"); | } | } | } | - because of the credits coming on a different order than how they would usually come, the delivery of messages is interrupted. We will get the credit before they came negative.. so nothing will resume delivery. If we called largeMessageDeliver.deliver() synchronously the credits would only arrive at the right time and the resume would work without any problem. - We could of course make place the receiveCredits on an executor, scheduling the credit to be added as soon as the largeMessageSender is finished, or play with locks, but that seems weird to me and besides would cause implications on the regular use-case which is sending regular messages. Making the call to largeMessageDeliverer.deliver synchronously would be the easiest solution, where I don't need to use any locks or executors, and believe on the natural order of credits that are coming from the client. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201951#4201951 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201951

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Expected Behaviour MessagingXAResource.isSame

by clebert.suconic＠jboss.com

Yes.. i saw that... But someone was complaining about eventual failures... so I wanted to confirm if that was the supposed behaviour. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201949#4201949 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201949

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Expected Behaviour MessagingXAResource.isSame

by jhowell＠redhat.com

yep exactly. The actaul method returns... boolean same = ((MessagingXAResource)xaResource).rm.getServerID() == this.rm.getServerID(); so it just compares the peer ids. Jay:) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201945#4201945 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201945

17 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Accessing session attributes in a portlet

by segal96

I am using Jboss portal 2.6.8. I tried the code below, but I still get null value when attempting to read "attr1". I set "attr1", an HttpSession attribute, in the doFilter() of my filter class. I believe that this is set before the request gets to the portal servlet. I'm not to JB portal, but from what I am reading, there might not be a way to read this attribute from my portlet. Here is a similar post with no response from '05: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122211#4122211 Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201943#4201943 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201943

17 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Design of Portal Deployer

by mwringe

"alesj" wrote : A few comments to your current work and we'll pick it up from here. | | 1) Deployer - Portal Container dependency | | (a) like you're doing it now by adding dependencies to deployment | | (b) making deployers optionally depend on the portal container | e.g. @Inject(option=InjectOption.CALLBACK) | Then if the portal container is not present do nothing. | | I like (a) better, as it holds all the dependencies at a single place. | It's just the way your doing it - not cleaning up in undeploy + duplication code. | I don't think (b) is even possible since we can't guarantee the order of when the container or deployment is deployed. We could do something like storing the deployment data in the deployer until the container starts or making the container directly contact the server to check what it has already deployed, but I don't like these ideas. anonymous wrote : | See how I do it with DependenciesMetaDataDeployer or DeploymentDependencyDeployer, | meaning you only need to provide Portal specific DependenciesMetaData or DeploymentDependencies impl. | ok anonymous wrote : | WRT "container - deployer" interface, I would go to a bean directly, via some proper interface. | agreed anonymous wrote : | 2) PortletTLDDeployer | | TLD usage in portal should be metadata driven, | as is the rest of the metadata stuff that we do in JBossAS. | Hence making it easier and cleaner to do this tld addition. | | I guess this approach would still work if we still always unpack .war deployment. | Dunno if that's true with the VFS usage? | I really don't like how this is working right now, its a hack. It's something that needs to be fixed. I will need to read up on how tlds work to see if it can done in a different manner (perhaps referencing the tld location in metadata instead of imbedding it into the war). I took some time to look into the VFS, but couldn't figure out a way to make this work nicely. If anyone has any suggestions on how to add a file to a webapp during the deployment phase please speak up :) anonymous wrote : | 3) PortletDeployer | | What's the point of this one? | No point right now, it was just initially done to check somethings while I am working on the deployer. anonymous wrote : | 4) PortletDependencyDeployer | | As already mentioned. | This one should just produce custom portal DependenciesMetaData or DeploymentDependencies impl. | The way it's currently done is wrong, as ControllerContext is only present in top deployment unit. | Ah, good point, this will be fixed. 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. anonymous wrote : | 5) CommandServletDeployer | | Looks OK. | This is how TLD stuff should look like. ;-) | This is how I want the TLD stuff to work, I just need to figure out how. anonymous wrote : | 6) PortalPostWebDeployer | | What does this do? | This is a hack that will be removed once the portal is completely moved over to using the microcontainer deployment. The way portal used to get this type of information was changed too much in AS5 so this replaces the lost functionality. Its meant to be removed at some point. anonymous wrote : | And using such hacks: | | | public int getRelativeOrder() | | { | | //return the order just after the war deployer | | //note: should really be +1 but other portal deployer is getting in the way right now | | return warDeployerOrder + 2; | | } | | | defeats the purpose of deployers chain/changeability/inputs/outputs/... | For those deployers right now, knowing when the war deployer has finished deploying the app is required as we access that information from the war deployer in our own deployer. This is only being used in deployers that are meant to be removed or the TLD deployer which needs to be rewritten more cleanly anyways. So this issue will be gone. FYI, the manipulation of deployer order based on another deployer's order is also used in a few other deployers in AS5. anonymous wrote : | 7) LibDirectoryStructure | | What should this do? | Similar to my legacy DirectoryStructure? | Yes, except it doesn't look through the whole directory structure, only at directories called "lib" within the first level of the deployment. I don't believe its needed anymore, but it used to cause all sorts of problems without it when nested deployments (like sars) were used that would have worked fine on AS4. And I know that using jboss-structure.xml files would have worked, but it meant that we could no longer add or remove wars to the portal sar without rewriting that file each time. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201940#4201940 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201940

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Expected Behaviour MessagingXAResource.isSame

by timfox

isSameRM() should return true if they correspond to the same resource manager, in JBM's case this means the same server. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201933#4201933 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201933

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Expected Behaviour MessagingXAResource.isSame

by clebert.suconic＠jboss.com

This is for JBM 1.4: What is the expected behaviour of isSame, with two distinct ResourceManagers, one from each JMSSession? The following test would fail: XASession sess = conn.createXASession(); | MessagingXAResource res = (MessagingXAResource)sess.getXAResource(); | | XASession sess2 = conn.createXASession(); | MessagingXAResource res2 = (MessagingXAResource)sess2.getXAResource(); | | Transaction tx = tm.getTransaction(); | | | assertFalse(res.isSameRM(res2)); // This would fail | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201931#4201931 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201931

17 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2009