[Remoting] - Re: JBREM-877: New Socket Connection is being Created for Ev
by ron.sigal＠jboss.com
Hi Dave,
"ImmortAlex" wrote :
| I think, you forgot isParam="true".
|
Alex is right. "invokerDestructionDelay" affects the creation of invokers on the client side, and setting "isParam" to "true" causes the "invokerDestructionDelay" parameter to be included in the InvokerLocator, which means it can be seen by the client.
I should tell you, though, that the use of "invokerDestructionDelay" may not help you when you're using the http transport. See the thread "Socket keep alive with client EJB and RMI over HTTP" (http://www.jboss.org/index.html?module=bb&op=viewtopic&t=137758&postdays=...) in this forum. Unfortunately, I don't have any good answers right now.
"Dave Schneider" wrote :
| What also has me confused is that I've already upped the callbackPollPeriod attribute from its default of 102 (ms) to 5003, so I would be expecting connections from the clients only every 5 seconds or so.
|
You're using an old version of JBossMessaging which, prior to versions 1.4.1.GA, 1.4.0.SP3.CP04, and 1.4.2.GA, didn't know about blocking/nonblocking mode, so you're seeing the default, nonblocking, behavior. I'm not sure why increasing "callbackPollPeriod" didn't have an effect, but you probably don't want to be using nonblocking mode anyway, and "callbackPollPeriod" is ignored in blocking mode. For that reason, I would suggest upgrading JBM.
Until recently it was necessary for the client code (JBM in this case) to specify the blocking mode when calling org.jboss.remoting.Client.addListener(), but JBREM-1084 "Allow CallbackPoller to access Client and InvokerLocator parameters" will allow org.jboss.remoting.callback.CallbackPoller to get the blocking mode directly from the InvokerLocator if you add the parameter "useAllParams" to the InvokerLocator with the value set to "true"; i.e., add
| <attribute name="useAllParams" isParam="true">true</attribute>
|
to remoting-http-service.xml. That feature doesn't exist in a released version of Remoting yet, but, if you're interested, I could attach a preview jboss-remoting.jar to JBREM-1084.
By the way, here's remoting-http-service.xml from JBossMessaging 1.4.0.SP3_CP07:
| <?xml version="1.0" encoding="UTF-8"?>
|
| <!--
| HTTP-based Remoting service deployment descriptor.
|
| $Id: remoting-http-service.xml 3222 2007-10-20 12:13:57Z timfox $
| -->
|
| <server>
|
| <mbean code="org.jboss.remoting.transport.Connector"
| name="jboss.messaging:service=Connector,transport=http"
| display-name="HTTP Transport Connector">
| <attribute name="Configuration">
| <config>
| <invoker transport="http">
| <!-- There should be no reason to change these parameters - warning!
| Changing them may stop JBoss Messaging working correctly -->
| <attribute name="marshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute>
| <attribute name="unmarshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute>
| <attribute name="dataType" isParam="true">jms</attribute>
| <attribute name="serverBindAddress">${jboss.bind.address}</attribute>
| <attribute name="serverBindPort">4458</attribute>
| <attribute name="callbackStore">org.jboss.remoting.callback.BlockingCallbackStore</attribute>
| <!-- End immutable parameters -->
|
| <!-- The period of sending pings to the server -->
| <attribute name="clientLeasePeriod" isParam="true">10000</attribute>
|
| <!-- Set this to true if you want the HTTP transport to block waiting for server->client traffic.
| Or false if you want it to poll for new traffic periodically. Recommended is true -->
| <attribute name="blockingMode" isParam="true">blocking</attribute>
|
| <!-- Timeout for blocking. Only has relevance if blockingMode = true -->
| <attribute name="blockingTimeout" isParam="true">30000</attribute>
|
| <!-- The periodicity of polling. Only has relevance if blockingMode = false -->
| <attribute name="callbackPollPeriod" isParam="true">10000</attribute>
| </invoker>
| <handlers>
| <handler subsystem="JMS">org.jboss.jms.server.remoting.JMSServerInvocationHandler</handler>
| </handlers>
| </config>
| </attribute>
| </mbean>
|
| </server>
|
Using blocking mode should reduce the number of invocations, and therefore reduce the number of open sockets.
-Ron
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214397#4214397
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214397
17 years, 1 month
[Beginners Corner] - DANGER !!!!!! BE CAREFUL OF LD_ASSUME_KERNEL=2.1.4 ABOVE
by ngonidan
DANGER !!!!!
BE CAREFUL OF SETTING LD_ASSUME_KERNEL=2.1.4 ABOVE in newer Linux distros like Fedora 4 upwards etc
PLEASE BE CAREFUL OR YOU WILL CRASH YOUR MACHINE AND FAIL TO LOGIN
What is LD_ASSUME_KERNEL
A while back a environment variable was introduced (mostly) to allow users to control how Linux handled threading issues. All sorts of applications (in particular Java) started telling users to set this LD_ASSUME_KERNEL variable. If you still have this variable set in Fedora Core 4, you are looking for trouble.
*****Itâs true, I ngonidan crashed our Proxy server at office because I set the variable to
export LD_ASSUME_KERNEL=2.1.4
**********************
When Linux was changing threading models the new threading model broke several applications (in particular Java) and so they added a variable you could set to get the old threading behavior. Many people just added this to their .profile or login to always allow things like Java to work.
Another application that had issues at one point with the threading model was rpm. After some upgrades you would need to set LD_ASSUME_KERNEL to some particular value to get rpm to work at all.
At some times during the transition, mozilla/firefox needed LD_ASSUME_KERNEL to properly run. Those days are long past.
This was all well and good for transition to a new threading model/abi, but this has long since been completed. If you have LD_ASSUME_KERNEL set in Fedora Core you will see nifty errors like:
/usr/lib/openoffice.org2.0/program/javaldx: /lib/obsolete/linuxthreads/libpthread.so.0: version `GLIBC_2.3.3' not found
and
rpmdb: unable to initialize mutex: Function not implemented. error: cannot open Name index using db3 - Function not implemented (38)
The solution is of course to go through all your personal init files and make sure you remove any mention of LD_ASSUME_KERNEL. Including .profile, .bashrc, etc.
How did I Ngonidan solve the crash
NOW, soon after setting export LD_ASSUME_KERNEL=2.1.4 in bashrc, I could not login as root. This meant the whole machine users were in trouble. Now I got a tip to use a failsafe session, which is kind of a safe mode for linux. BUT, commands Do NOT work as expected e.g. programs like vi, etc. I think itâs coz programs/services are not loaded so what I did, I thought of using the append commands. I booted linux, took note of Fedora Kernel 2.6.18-1.2798.fc6
Solution- was to simply append another environment variable soon after that erroneous line, which meant that will be the variable which will be loaded
# echo export LD_ASSUME_KERNEL=2.6.18-1.2798.fc6 >> /etc/bashrc
Thatâs it. Disaster recovered, will never play again with LD_ASSUME_KERNEL !!!!!!!!
If above fails Try using an Ubuntu Live CD to go in and edit the file and save and reboot machine. But for me Ubuntu Live CD took too long or actually failed to startup my machine
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214381#4214381
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214381
17 years, 1 month