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

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

by apemberton

Steve: You might clarify by adding your Portal version info, etc., but I'll take a stab at an answer anyway. Your servlet listener will intercept requests to the underlying portal servlet, whereas the portlet code you showed there is accessing the portlet's session. These two session are inherently different (different WAR deployments) Instead try the following in your portlet code: | Navigation.getPortalRuntimeContext().getSession().getAttribute("attr1"); This will allow you to access the underlying portal servlet's global session from your portlet code. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201573#4201573 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201573

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Fix for ClusterViewUpdateTest

by clebert.suconic＠jboss.com

As a fix for the ClusterViewUpdateTest, the following change was made: - 10000 - 5000 + 2000 + 2000 It seems that changing the timeout on the test seems suitable, but the above change will affect production systems. shouldn' t those values be changed on the Testsuite only instead? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201572#4201572 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201572

17 years, 2 months

1
0
0 / 0

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

by clebert.suconic＠jboss.com

Tomorrow I will be playing with MultiThreadFailoverTests... I will try to break a few things and have some fun debugging it. I will only propose merging it on trunk after I have done the complete tests with those tests. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201560#4201560 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201560

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover & Paiging...

by clebert.suconic＠jboss.com

Besides sending the AddressName on replicate delivery, and forcing a depage until a reference is found, I also had to make sure replicateDelivery wouldn't subtract sizes on the PageControl. replicateDelivery was calling removeFromQueue, and that would call addSize(-size). addSize is supposed to be called only on ACK, so I had done a few tweaks around the method. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201557#4201557 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201557

17 years, 2 months

1
0
0 / 0

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

by clebert.suconic＠jboss.com

I did some work to make sure the LargeMessage sending will be replicated to the backup nodes. On my initial work, I was having a lot of problems on getting the LargeMessage to be replicated and sent on both nodes. I was aways getting an Out-of-credits on the backup when replicating the message, causing issues on replicating the ACKs and properly failing over to the backup. Changes I had to make to fix the issues on LargeMessage and Failover: 1) I simple fix to sendLargeMessage | On ServerConsumerImpl:: | | private void sendLargeMessage(final MessageReference ref, final ServerMessage message) | { | // TODO: Should we block until the replication is done? | channel.replicatePacket(new SessionReplicateDeliveryMessage(id, message.getMessageID(), message.getDestination())); | | // SendLargeMessage has to be done on the same thread used on the QueueImpl or we would have problems with ordering and flow control | largeMessageSender = new LargeMessageSender((LargeServerMessage)message, ref); | largeMessageSender.sendLargeMessage(); | | } | This above code used to wait the replication to finish before sending the LargeMessage, what would use another thread. The queue would continue its work asynchronously and the Consumer would eventually handle another message while sendLargeMessage was still processing, what would cause issues on the backup node (not enough credits). 2) When taking credits on backup, we will eventually resume sending the largeMessage. That process needs to be done synchronously while receiving the credit from the live node. If we play the commands on a different order we would eventually reject messages because of credit during the replication, or because we would still processing a largeMessage. promptDelivery is now calling resumeLargeMessage if largeMessageSender != null, and this is resumeLargeMessage: | private void resumeLargeMessage() | { | if (messageQueue.isBackup()) | { | // We are supposed to finish largeMessageSender, or use all the possible credits before we return this method. | // If we play the commands on a different order than how they were generated on the live node, we will | // eventually still be running this largeMessage before the next message come, what would reject messages | // from the cluster | largeMessageSender.resumeLargeMessageRunnable.run(); | } | else | { | executor.execute(largeMessageSender.resumeLargeMessageRunnable); | } | } | 3) While receiving LargeMessages, the client will send credits back, as soon as the chunk is received on the client. For that handleLargeMessageContinuation, will call flowControl. While flowcontrol is being called, handleLargeMessageContinuation caller will be holding a lock of the ClientRemoteConsumer. As a result, we will have a dead lock if failover happens while flowControl is being called within handleLargeMessageContinuation. I am now using an executor for the flowControl, when receiving LargeMessages. This way I release the lock on the ClienteRemoteConsumers while sending the flowcontrol back, so Failover will be able to perform outside of the locks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201554#4201554 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201554

17 years, 2 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Maven refactoring

by pgier

I'm done with the changes and the testsuite is running on hudson now. So far everything looks ok. Let me know if there are problems. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201539#4201539 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201539

17 years, 2 months

1
0
0 / 0

[Design of JBossXB] - Re: problem parsing sip.xml with JBossXB

by alex.loubyansky＠jboss.com

Ok, right. I'll add support for that as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201533#4201533 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201533

17 years, 2 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Maven refactoring

by kabir.khan＠jboss.com

Don't worry if the asintegration-* tests fail, I can fix them in the morning View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201528#4201528 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201528

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MutableClassInfo?

by stale.pedersen＠jboss.org

as we've stated in the aop design forum (and here) is that the current state of jboss-reflect is too limited for aop to use at all. a well designed MutableClassInfo can change that though. from what i can see it has to support the following: - the possibility to create a classobjectrepresentation from a byte[]/File/Url - be able to change/add/remove fields/methods/constructors/classes similiar to what javassist support - do finegrained operations/checks ala annotation visibility (which is only possible with javassist and not java.lang.reflect afaik) - be able to get a classobjectrepresentations (ala ClassFile in javassist) from an existing ClassInfo object - support scoped classpools ++? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201527#4201527 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201527

17 years, 2 months

1
0
0 / 0

[Design of Management Features on JBoss] - SNMP Custom data type attributes

by evance

Not sure if this is the right place to post this question but I have a requirement to get our Mbean accessible via SNMP. I believe have the everything setup because I use a simple SNMP manager to get and set values for MBean with simple type. My problem is when I have MBeans with custom POJO data types in the setters and getters I receive the follow error in the JBoss console: [SnmpAgentService] Unknown type for [oid=.1.3.6.1.4.1.2162.500.2.1, mbean=messenger:service=HelloWorld, attr=Message, rw=true] I have a PropertiesEditor created and it wors via the JMX console for setting and getting the values with my custom data type but not in my SNMP Manager. I am using AdventNet MIB browser to test with. Again... It works when the MBean uses String, integers and other simple types but not with Class types. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201524#4201524 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201524

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