[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-674 - Propagating changes on ClusteredConnec
by clebert.suconic＠jboss.com
anonymous wrote :
| 1. ServerConnectionFactoryEndpoint sends a view update to ALL active connections returned by the ConnectionManager instance. Why does it send it to all? Didn't you mention that this has to be sent on a "filtered" list of connections? This JIRA issue (http://jira.jboss.com/jira/browse/JBMESSAGING-759 ) is about this.
oops... fixing it... easy fix.
We need a testcase that uses two connectionFactory though.
anonymous wrote : 2. Why the code that sends the view update (currently hosted by ServerConnectionFactoryEndpoint) is not located at ConnectionManager level? Seems more appropriate to be there...
|
I was wondering if we should lock the factory while updating the clients or not. Since there is that possibility we would require a ReadWriteLock on the CFEndpoint. Since there is a possibility of locking the CF that was an indication for me the right place for the update would be the CFEndpoint itself.
anonymous wrote : 3. Why do you keep a different "activeConnections" set at ConnectionManger level? Speed reasons? You got all the information you need in the "endpoints" map already. Keep in mind that cluster view update events are very rare events, considering the time scale at which messaging operates. Why would you need to optimize that, risking cache desynchronization?
|
The active connection list is on a three levels HashMap list VMId->ClientId->Connection. It seemed simpler to have a simple HashSet, managed by the very same routines. I can change that if you like.
anonymous wrote : 4. What's the difference between a LoadBalancingPolicy and a LoadBalancingFactory? Why do you configure a ConnectionFactory service with the latter instead of the former?
The LoadBalancingPolicy is not static any more.. you need a Policy per Connection created. This was working before because Serialization was creating new instances for you... and besides you had a comment about not making it static any more.
anonymous wrote : 5. What is this:
| Code:
|
| // FailoverNodeID is not on the map, that means the ConnectionFactory was updated
| // by another connection in another server.. So we will have to guess the failoverID
| // by numeric order. Case we guessed the new server wrongly we will have to rely on
| // redirect from failover
|
|
|
| (ClusteringAspect.java line 211).
| Why do we need to guess the failover ID?
|
Take a look on the 4th message at this thread (Posted: Mon Jan 15, 2007 17:35 PM) and some others after that.
Case the Factory is updated before failover happens, there is a change the failoverID is not on the MAP any more.
On that case we would require a random node to try a hopping. Instead of a random node I'm guessing the node... and if it fails hopping will take care of it.
anonymous wrote : 6. ClusterViewUpdateTest.testUpdateConnectionFactory() fails.
I executed the whole testsuite about two times between yesterday and today.. and didn't get any failures. Maybe you have a local problem?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003910#4003910
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003910
19 years, 2 months
[Design the new POJO MicroContainer] - serializable KernelDeployment
by bill.burke＠jboss.com
I was experimenting with serializing a KernelDeployment, unserializing it and trying to deploy it. I have been unsuccessful so far and would like some hints. Here's what i do right now:
| AbstractKernelDeployer deployer = new AbstractKernelDeployer(kernel);
| ObjectInputStream ois = new ObjectInputStream(url.openStream());
| KernelDeployment deployment = (KernelDeployment)ois.readObject();
| Field field = AbstractKernelDeployment.class.getDeclaredField("installedContexts");
| field.setAccessible(true);
| field.set(deployment, new CopyOnWriteArrayList<KernelControllerContext>());
| ois.close();
| deployer.deploy(deployment);
|
The "installedContexts" field of AbstractKernelDeployment is transient so I had to instantiate a new one and set the field or otherwise I would get an NPE. Now, I'm finding that most of the beans, but not all, are NOT getting installed. They are getting processed, but the state is ERROR condition. The weird thing is that some of the beans are being installed correctly. Any hints?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003837#4003837
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003837
19 years, 2 months
[Nukes Development] - Re: URIencoding is not working... Not able to save the Germa
by stevehalsey
Hi,
You say using JBoss you managed to get GETs to process the UTF-8 correctly, but not the POSTs. I found your article because I had the opposite problem!
I had read http://java.sun.com/developer/technicalArticles/Intl/HTTPCharset/ and managed to get POSTs to correctly be decoded by puttting the following call to httpServletRequest.setCharacterEncoding("UTF-8") in your servlet processRequest or doGet or doPut methods:-
protected void processRequest(HttpServletRequest httpServletRequest,
HttpServletResponse httpServletResponse)
throws ServletException, IOException {
LOG.debug("ENTERING processRequest method.");
//As this is the UTF-8 servlet then the assumption is that all params are UTF-8 encoded.
//If we didn't do this then the Servlet Engine would assume ISO-8859-1 or use the
//charset header if it was sent (most browsers don't seem to ever send this though)
//If you uncomment these two test lines below it will cause the setCharacterEncoding
//command to have no effect and your parameters will be MANGLED.
//LOG.debug("Testing calling getParameter before setCharacterEncoding, this should screw things up...");
//String thisShouldScrewThingsUp = httpServletRequest.getParameter("thisShouldScrewThingsUp");
//This servlet expects ALL parameters to be UTF-8 encoded and so the
//following setCharacterEncoding MUST be called before ANY reading of parameters
//from the HttpServletRequest object or it will be too late and the default of
//ISO-8859-1 will have been used to decode the parameters and so they will be
//mangled.
LOG.debug("in TestUtfEightParamServlet.processRequest calling httpServletRequest.setCharacterEncoding(\"UTF-8\");");
httpServletRequest.setCharacterEncoding("UTF-8");
I then POSTed the following char ? to the server and it correctly recognises it as unicode character U+920d, but then if I uncomment the line that gets the parameter thisShouldScrewThingsUp then it does, as expected, screw up, interpretting the character as characters with Unicode code points \ue9 \u88 \u8d.
So with the above code, POST worked but GET still didn't.
As it says in your post and at:-
http://java.sun.com/developer/technicalArticles/Intl/HTTPCharset/
you can fix this by setting URIencoding = UTF-8 in the server.xml file, but this then means all your apps on that server will have their URIs interpreted as UTF-8 which you may well not want (I don't, since one app on the server still needs to work with ISO-8859-1 encoded URIs). So I found a way round this is to set useBodyEncodingForURI="true" as follows in server.xml:-
<!-- A HTTP/1.1 Connector on port 8080 -->
After restarting JBoss the above code now works for both POSTs and GETs, but any programs which still work with ISO-8859-1 as the default for decoding their GETs and POSTs should still work OK I think.
Its all very messy and hard to find in the documentation. It would be good to have a page in the Jboss documentation that explains this kind of thing, maybe there is one but I can't find it?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003821#4003821
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003821
19 years, 2 months