August 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Transaction Services] - Re: TransactionManager doesnt allow to configure bind addres

by mark.little＠jboss.com

BTW you can change the port numbers at runtime. You just can't do it through the same mechanism AS uses. Check the TS docs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4077385#4077385 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4077385

18 years, 7 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: TransactionManager doesnt allow to configure bind addres

by mark.little＠jboss.com

Yes, this is the same as http://www.jboss.com/index.html?module=bb&op=viewtopic&t=113436. We'll fix it in a future release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4077384#4077384 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4077384

18 years, 7 months

1
0
0 / 0

[Design of JBoss Transaction Services] - TransactionManager doesnt allow to configure bind address

by jgra＠vp.pl

Aparently there is no configuration parameter to specify bind IP for TM to listen (as far as I now) and TM allways binds to all interfaces on machine. In JBoss App Srv ver. 4.2 configuration, TM creates 3 efemeric ports with bindings as stated above and it ignores JBoss run cmd address binding option (-b). test-xen:/usr/local/jboss-4.2.1.GA/bin# netstat -lntp | grep java | tcp 0 0 127.0.0.1:3873 0.0.0.0:* LISTEN 8133/java | tcp 0 0 0.0.0.0:34689 0.0.0.0:* LISTEN 8133/java | tcp 0 0 127.0.0.1:8009 0.0.0.0:* LISTEN 8133/java | tcp 0 0 127.0.0.1:1098 0.0.0.0:* LISTEN 8133/java | tcp 0 0 127.0.0.1:1099 0.0.0.0:* LISTEN 8133/java | tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 8133/java | tcp 0 0 0.0.0.0:52723 0.0.0.0:* LISTEN 8133/java | tcp 0 0 127.0.0.1:4444 0.0.0.0:* LISTEN 8133/java | tcp 0 0 127.0.0.1:4445 0.0.0.0:* LISTEN 8133/java | tcp 0 0 127.0.0.1:4446 0.0.0.0:* LISTEN 8133/java | tcp 0 0 0.0.0.0:43710 0.0.0.0:* LISTEN 8133/java Quick look in App Srv sources shows that the problem is not about integration service for App Srv, but lack of such feature in TM Core which use ServerSocket ctor with only port argument. >From security point of view it should be possible to bind TM to specific address using some config parameters. Regards Janusz Grabowski View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4077383#4077383 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4077383

18 years, 7 months

1
0
0 / 0

[Design of JBossCache] - Re: Partitioning in JBoss Cache - JBCACHE-60

by bela＠jboss.com

We can definitely look into a 'partial flush', so we block only the services on the Multiplexer, which are involved in the JOIN and/or state transfer. Vladimir will look into this once he's back from California. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4077382#4077382 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4077382

18 years, 7 months

1
0
0 / 0

[Design of JBossCache] - Re: JBossCache Cache Mgmt interceptor hit/miss not collected

by manik.surtani＠jboss.com

Once you create the JIRA post a link to it here. Thanks Manik View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4077357#4077357 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4077357

18 years, 7 months

1
0
0 / 0

[Design of JBossCache] - Re: JBossCache Cache Mgmt interceptor hit/miss not collected

by mabc101

Sounds good to me. Thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4077354#4077354 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4077354

18 years, 7 months

1
0
0 / 0

[Design of JBossCache] - Re: JBossCache Cache Mgmt interceptor hit/miss not collected

by manik.surtani＠jboss.com

This looks like a bug to me. I can't see how this is by design. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4077307#4077307 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4077307

18 years, 7 months

1
0
0 / 0

[Design of JBossCache] - Re: JBossCache Cache Mgmt interceptor hit/miss not collected

by mabc101

Thanks Manik for your prompt response. I am including the section of the code from CacheMgmtInterceptor below. As you can see the case statement for "get" which keeps hit/miss stats count, is for "getKeyValueMethodLocal" case only. If I call the method without the key (as indicated in my previous post), the default case is invoked, so the hit/miss count is not captured. I believe this is by design and I just want to understand the semantic difference between the two cases, ie, using "get" without key has a different purpose (perhaps internally - like node visits for eviction etc - which logically should not increment the hit/miss count - but I am treading on this ice here) vs "get" with key which actually returns data and therefore should update the stats. Here is the code segment: ============================================== switch (m.getMethodId()) { case MethodDeclarations.getKeyValueMethodLocal_id: //fqn = (Fqn) args[0]; //key = args[1]; t1 = System.currentTimeMillis(); retval=super.invoke(m); t2 = System.currentTimeMillis(); if (retval == null) { m_miss_times = m_miss_times + (t2 - t1); m_misses++; } else { m_hit_times = m_hit_times + (t2 - t1); m_hits++; } break; case MethodDeclarations.putKeyValMethodLocal_id: case MethodDeclarations.putFailFastKeyValueMethodLocal_id: //fqn = (Fqn) args[1]; //key = args[2]; //value = args[3]; t1 = System.currentTimeMillis(); retval=super.invoke(m); t2 = System.currentTimeMillis(); m_store_times = m_store_times + (t2 - t1); m_stores++; break; case MethodDeclarations.putDataMethodLocal_id: case MethodDeclarations.putDataEraseMethodLocal_id: //fqn = (Fqn) args[1]; attributes = (Map)args[2]; t1 = System.currentTimeMillis(); retval=super.invoke(m); t2 = System.currentTimeMillis(); if (attributes != null && attributes.size() > 0) { m_store_times = m_store_times + (t2 - t1); m_stores = m_stores + attributes.size(); } break; case MethodDeclarations.evictNodeMethodLocal_id: case MethodDeclarations.evictVersionedNodeMethodLocal_id: //fqn = (Fqn) args[0]; retval=super.invoke(m); m_evictions++; break; default : retval=super.invoke(m); break; } return retval; } View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4077280#4077280 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4077280

18 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Getting Started for developers

by tom.baeyens＠jboss.com

you should be able to get started with the reference manual materials. but if you like more the easy reading kind of stuff, there's a great new book on jbpm. you can find a reference on my blog http://processdevelopments.blogspot.com/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4077278#4077278 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4077278

18 years, 7 months

1
0
0 / 0

[Design of JBossCache] - Re: JBoss Cache and JBoss MC

by manik.surtani＠jboss.com

I'd like to use the MC to wire together cache internals. The cache is basically few core objects (CacheImpl, UnversionedNode) some services (CacheLoaderManager, RPCManager, Notifier, CacheMarshaller, BuddyReplicationManager) and a bunch of interceptors in front of the core objects (TxInterceptor, CacheLoaderInterceptor, etc etc). The relationship between these objects are all controlled by the cache.create() method when the cache starts, which uses a Configuration object to determine which services and interceptors are needed and how they are configured. This is where I think the MC can help; where the services and interceptors can be configured in a beans.xml file, which would control the implementations of each service/interceptor used as well as their relationship, e.g., inject a notifier into the NotificationInterceptor, a CacheLoaderManager into a CacheLoaderInterceptor, etc etc. Regarding end users configuring a -beans.xml file, I would like to expose this as a possibility for "advanced" users, but also provide a much simpler configuration file for more typical use cases (no customisation of interceptors, notifiers, rpc managers, etc., but simple stuff like eviction policies, cache loaders as well as timeouts, cache modes, etc). Maybe a well-designed cache-specific schema would allow me to achieve both in a single file. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4077238#4077238 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4077238

18 years, 7 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 August 2007