[JBoss Cache Users] - Re: What is an invocation, and the related option override?
by alllle
"mircea.markus" wrote : it only makes sense to use setForceWriteLock(true) on read. Normally when you do an cache.get(fqn) an read lock is aquired, but setting the forceWriteLock to true would force a write lock acquisition. when you do a put(fqn)(generally a write), a WL (write lock) is acquired so having the flag is redundant. As a general rule, the forceWriteLock only apply for one call, i.e. for one invocation.
| tm.begin();
| | // force write lock even on read operations
| | cache.getInvocationContext().getOptionOverrides().setForceWriteLock(true);
| |
| | // read node
| | Object value = cache.get(myFqn, "key");
| |
| | Object value = cache.get(myFqn2, "key");
| |
| | tm.commit();
|
| In this example a WL is acquired for myFqn and a RL is acquired for myFqn2
|
| anonymous wrote : In other words, once I set the "setForceWriteLock(true)", all future cache related operations in this thread will see this option set to "true". No. Only the next call, after that the flag is cleaned. As mentioned in the previous post, an invocation is an call to the cache.
I did a quick test and you are absolutely right. Just like what you pointed out in your sample code, after each read or write, the over write option is reset. This clears the confusion I had. Thanks!
The reason for this post was that I'm trying to find a reliable way to do a "select for update" kind of operation in the new MVCC locking, i.e., a read followed by a write and the write value depends on the read result. Could you please comment on this thread?
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=161530&postdays=...
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258508#4258508
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258508
15 years, 3 months
[Clustering] - Re: Farm deployment errors with large WAR files
by bstansberry＠jboss.com
I've commented on the JIRA, but will go into a bit more detail here.
First, the logs you sent me, Adam, showed the file that was being farmed was actually "xxx.ear.filepart" not "xxx.ear". From that I believe you were using a tool (perhaps WinSCP?) to upload the file directly to the farm directory. That's a lengthy enough operation that the hot deployment scanner ran in the middle.
Hence my recommendation on the JIRA to stop the hot deployment scanner thread before doing lengthy I/O operations.
The scanner can be stopped by invoking the JMX stop() operation on the jboss.deployment:flavor=URL,type=DeploymentScanner MBean. This can be done via the jmx-console or via the twiddle utility in $JBOSS_HOME/bin.
I also you recommend you do your upload to a temp folder and then do a local copy into farm/. Otherwise if there is a failure during the upload you'll be leaving a corrupt file in farm/.
Second, looking closely at the logs tells me that a very high percentage of messages JGroups is sending from the master are not being received on the child. This makes things go very slowly. You need to determine why there is such a high rate of loss on your network. Earlier in the thread we've discussed the OS maximum read buffer setting. You can also adjust the maximum write buffer. Note also that changes made via sysctl -w are not persistent across restarts; for persistent changes you need to edit /etc/sysctl.conf.
If you can't eliminate the UDP packet losses, you might consider using a TCP stack, particularly if yours is a 2 node cluster, where there is no benefit from using IP multicast. If you can use IP multicast for the initial cluster discovery messages (which seems to be working fine) then it's very easy to configure the AS to use TCP for regular traffic, just add this to your command line arguments:
-Djboss.default.jgroups.stack=tcp
(Switching to TCP is a bit more complicated if IP multicast for discovery isn't an option.)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258506#4258506
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258506
15 years, 3 months
[Installation, Configuration & Deployment] - More ServiceBindingSet questions
by bdamato
I've got a jboss server that's running behind an apache web server, so I have the HTTP and HTTPS connectors disabled in jbossweb.sar/server.xml. Only AJP is running:
| <Connector protocol="AJP/1.3" port="8709" address="${jboss.bind.address}"
| redirectPort="8443" />
|
I'm using the port offset feature in bindingservice.beans/META-INF/bindings-jboss-beans.xml to handle the ports. Everything is working properly, except that when I hit a secured web page, jboss is redirecting me to port 9143 instead of 8443 (port offset is 700). This is my config:
| <!-- The CouponEngineBindings bindings are obtained by taking the base bindings and adding 700 to each port value -->
| <bean name="CouponEngineBindings" class="org.jboss.services.binding.impl.ServiceBindingSet">
| <constructor>
| <!-- The name of the set -->
| <parameter>CouponEngineBindings</parameter>
| <!-- Default host name -->
| <parameter>${jboss.bind.address}</parameter>
| <!-- The port offset -->
| <parameter>700</parameter>
| <!-- Set of bindings that are specific to this ServiceBindingSet -->
| <parameter>
| <set elementClass="org.jboss.services.binding.ServiceBindingMetadata">
| <bean class="org.jboss.services.binding.ServiceBindingMetadata">
| <property name="serviceName">jboss:service=Naming</property>
| <property name="bindingName">Port</property>
| <property name="port">8299</property>
| <property name="description">The listening socket for the Naming service</property>
| <property name="fixedPort">true</property>
| </bean>
| <bean class="org.jboss.services.binding.ServiceBindingMetadata">
| <property name="serviceName">jboss.web:service=WebServer</property>
| <property name="bindingName">HttpsConnector</property>
| <property name="port">8443</property>
| <property name="description">JBoss Web HTTPS connector socket</property>
| <property name="fixedPort">true</property>
| </bean>
| </set>
| </parameter>
| </constructor>
| </bean>
|
Any ideas on how I make tomcat redirect HTTPS requests to the correct port?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258492#4258492
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4258492
15 years, 3 months