[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
15 years, 10 months
[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
15 years, 10 months
[JBoss Cache: Core Edition] - on child insert parent, child collection updated in DB but N
by dukehoops
In abtract
I am load testing a Hibernate/JBC3 web application and am seeing that about 7% of the time inserting a child entity into a previously-empty collection results in update (INSERT) into DB but local cache remains unchanged:
-collection Node is still empty
-there is no child Entity node
This does not appear to be a race condition, as from that point on in any TX parent.getChildren() will return an empty collection from cache (even though DB state is non-empty).
This seems vaguely similar to https://jira.jboss.org/jira/browse/JBCACHE-1481 but that issue's marked resolved.
In detail
App Config
Single Tomcat 6 NIO
Hibernate 3.3.1.GA
JBossCache 3.0.3.GA - Local Cache only; using default Locking (MVCC); READ_COMMITTED isolation
BTM JTA transaction manager
Load Test
JMeter load test where each of userCount users loop over the following scenario of HTTP requests:
for(I iterations)
| {
| login();
| thinkTime //sleep;
| getRestrictedData(); //requires being logged in
| thinkTime //sleep;
| logout();
| thinkTime //sleep;
| }
|
App Pseudo Code
Domain Model
-Transactional entity caches User, UserSession; collection cache User.sessions
| class User{
| private long id;
| private Set<UserSession> sessions; //1-to-[0,1] modeled as one-to-many with unique constraint
|
| public boolean isLoggedIn()
| {
| return !getSessions().isEmpty();
| }
|
| public void addSession(UserSession us)
| {
| us.setUser(this);
| sessions.add(us);
| }
|
| public Set<UserSessions> getSessions()
| {
| return sessions;
| }
| }
|
|
|
| class UserSession
| {
| private User user;
|
| void setUser(User usr)
| {
| this.user = usr;
| }
|
| }
Service Methods
//insert new UserSession if credentials check out
| //throw exception otherwise
| public void login(id, credentials)
| {
| User usr = dao.getUser(id);
| if(credentials == bad)
| {
| throw new AuthenticationException();
| }
| usr.add(new UserSession());
| }
|
| //return data only if a userSession is present
| //throw exception otherwise
| public String getRestrictedData(id)
| {
| User usr = dao.getUser(id);
| if(! usr.isLoggedIn())
| {
| throw new AuthorizationException("not logged in");
| }
| return data;
| }
|
| public void logout()
| {
| //clear userSessions
| }
| }
|
Problem Observed
When userCount==1, no requests fail, regardless of thinkTime (varied latter between 0 and 2000ms)
| When userCount is > 30, about 10-20% of users eventually (and most of the time on the very 1st iteration), fail like so:
| -login() //success
| -getRestrictedData() //fail: user not logged in
|
| My load test terminates on 1st failure. Inspecting states of DB and JBoss Cache (via JMX) reveal:
| -DB does have record of UserSession in question
| -In Collection cache: User.sessions Node contains an empty PersistentSet
| -In entity cache: User node references above (empty) collection; no node for UserSession that is in DB;
| -hibernateVersion of User (parent) is updated in DB but not in Cache node
|
| Musings
|
| Though I am unable to repro this problem with 1 user, it is not possible for user A to affect state of user B in my app. So I am not quite clear on what's going on here. Since I don't (yet) understand the internals of MVCC (and jbc in general), I'd appreciate any thoughts and answers to the following questions that'll help me narrow down the problem:
|
| 1. In MVCC, how many threads participate in login() method? Is it the case that one thread does the read and writes a versioned update, but another thread merges the updated data *after* TX commit?
|
| 2. A somewhat dated http://www.jboss.org/community/docs/DOC-10266 wiki says there exists a faulty assumption about consistent ordering of synchronizations in Hibernate/JBC (problem #5). Has that been addressed? If not, could that be causing given problem?
|
| 3. Same wiki's problem #7:
| anonymous wrote : Hibernate should either retry or JBossCache should fail silently on this. (Nikita: not sure what 'this' refers to) As long as the data is stored in the db correctly, failure putting the data in the cache could fail silently. Next time someone requests the entity, it'd be retrieved from db and put in the cache.
|
| This paragraph seems to imply that it is normal that cache is not updated on insert of new UserSession during login(). However, it also expects subsequent User.getSessions() to result in a DB read (and a put into cache). But what I am seeing that User.getSessions() in getRestrictedData() results in a cache hit on a (stale) node containing empty set user.sessions. Should addSession() in login() result in User.sessions collection node being invalidated (to be populated during subsequent reads) or being updated with a new reference to UserSession node? Similarly, should addSession() result in put into UserSession entity cache, or is that put expected to occur only on subsequent read?
|
| 4. Finally, turning up debugging shows multitude of these 2 types of messages. These are emitted seemingly in failing and succeeding requests:
|
| anonymous wrote : [3/2/09 16:27:38:268] DEBUG [d585d9d4-cc59-4b35-b717-d26c97db8f89,ltester-100000] org.jboss.cache.interceptors.InvocationContextInterceptor - FAIL_SILENTLY Option is present - suspending any ongoing transaction.
| | [3/2/09 16:27:38:269] DEBUG [76225fe7-1541-4960-9c2d-cdbe1330f5c5,ltester-100001] org.jboss.cache.invocation.CacheInvocationDelegate - putForExternalRead() called with Fqn /com/doppelganger/domain/User/userSessions/COLL/com.doppelganger.domain.User.userSessions#183 and this node already exists. This method is hence a no op.
| |
|
| Does the latter say that a collections cache node will not be updated because one already exists. What if existing node contains an empty collection but the candidate node contains a non-empty collection?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214380#4214380
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214380
15 years, 10 months