Hot Rod topology cache update retry timeout
by galder＠redhat.com
Hi all,
For https://jira.jboss.org/browse/ISPN-426 I've created a small retry logic for when there's an issue updating the topology information on startup. By default, I set the max wait time to 30 seconds and I was wondering whether this should be made user configurable. This would a parameter into startServer.sh but it'd only be relevant to the Hot Rod server.
The primary reason I'm considering not to make it user configurable is cos it's related to Hot Rod metadata which user should not really be aware of. If after 30 seconds, lightweight metadata hasn't been updated, something pretty wrong is going on and I doubt increasing it is going to make much difference.
WDYT?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years
Maven repositories
by Israel Lacerra
Do you use a specific repository for the Infinispan dependencies?
I'm asking because after a update that I made a week ago, my workspace
crashes (missing jgroups:jgroups:jar:2.10.0.Beta2). I can search for this
jar and then resolve the issue on my workspace, but if you are using another
repository, I can avoid future crashes like this. :)
thanks!
Israel Lacerra
(a student trying to do ISPN-200)
16 years
Distribution, unreliable returns, conditional commands and transactions
by galder＠redhat.com
In DI.remoteGetBeforeWrite, you have:
if (isNeedReliableReturnValues(ctx) || (isConditionalCommand && ctx.isInTxScope())) {
for (Object k : keygen.getKeys()) remoteGetAndStoreInL1(ctx, k, isStillRehashingOnJoin);
}
Why does the command need to be conditional and within a transaction in order to do a remote get when reliable returns are not needed? It is my understanding that if a conditional command is in use, i.e. replace(k, old, v), it should override not needing reliable returns in order to get accurate results. However, this only seems to be the case if the conditional op is within a transaction.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years
lock acquisition - "finally release" it
by Philippe Van Dyck
Hi all,
in a servlet environment, you sometimes have to claim back a thread for your
thread pool.
Jetty has a nice "denial of service attack" filter and a setting
(maxIdleTime) interrupting servlet threads if nothing comes out (nothing is
written in the pipe).
Well it does not play well with infinispan. Everybody knows that when you
open a stream, the best way to reclaim scarce resources is to close it in a
'finally' statement. What about applying it to infinispan locking mechanism
? ;-)
Calls to acquireLock should be guarded by a finally {releaseLock} (at least
to catch an interruptedException)
It looks very easy to implement, but since releaseLock does not seems to be
called every time in the code, I need help !
The only places where aquireLock is called are
CacheLoaderInterceptor.loadIfNeeded and
EntryFactoryImpl.wrapEntryForWriting.
And BTW, the locks never expire ... so if you interrupt a thread and the
lock is not released, you better say bye bye to the cache entry!
Cheers,
Phil
16 years
Re: [infinispan-dev] XML namespaces in configuration files
by Vladimir Blagojevic
More comments from Alexey. Should have kept him on the cc from the beginning.
On 2010-05-12, at 1:09 PM, Alexey Loubyansky wrote:
> On 5/12/2010 5:18 PM, Vladimir Blagojevic wrote:
>> Thanks a lot Alexey. I think that we are going to follow the approach outlined below. Please have a quick look for my reasoning and see if it is flawed.
>
> It's alright. About the namespace, actually it's a matter of personal taste and reasoning. E.g. have a look at the following namespaces from other JBoss projects. They are not URL-based and some do include the version in the namespace. Users switching from one version to another will still have to just adjust the namespace. Or maybe even not doing that if your unmarshalling layer could recognize the previous configuration version by itself.
>
> registerEntity("urn:jboss:aop-deployer", "aop-deployer_1_1.xsd");
> registerEntity("urn:jboss:aop-beans:1.0", "aop-beans_1_0.xsd");
> registerEntity("urn:jboss:bean-deployer", "bean-deployer_1_0.xsd");
> registerEntity("urn:jboss:bean-deployer:2.0", "bean-deployer_2_0.xsd");
> registerEntity("urn:jboss:javabean:1.0", "javabean_1_0.xsd");
> registerEntity("urn:jboss:javabean:2.0", "javabean_2_0.xsd");
> registerEntity("urn:jboss:spring-beans:2.0", "mc-spring-beans_2_0.xsd");
> registerEntity("urn:jboss:policy:1.0", "policy_1_0.xsd");
> registerEntity("urn:jboss:osgi-beans:1.0", "osgi-beans_1_0.xsd");
> registerEntity("urn:jboss:seam-components:1.0", "seam-components_1_0.xsd");
> registerEntity("urn:jboss:security-config:4.1", "security-config_4_1.xsd");
> registerEntity("urn:jboss:security-config:5.0", "security-config_5_0.xsd");
> registerEntity("urn:jboss:jndi-binding-service:1.0", "jndi-binding-service_1_0.xsd");
> registerEntity("urn:jboss:user-roles:1.0", "user-roles_1_0.xsd");
>
>
>> If you are interested maybe we can collaborate on a project that we made for automatic configuration HTML reference file generation. We used annotated XML configuration pojos, along with a bit more additional metadata attached to each field to automatically generate configuration HTML references. Have a look at:
>> http://docs.jboss.org/infinispan/4.1/apidocs/config.html
>
> Not sure whether I'll get involved but I think it could be useful for other projects as well. Is it a separate standalone project?
>
> Thanks,
> Alexey
>
>> Best regards,
>> Vladimir
>>
>>
>> On 2010-05-12, at 11:11 AM, Vladimir Blagojevic wrote:
>>
>>> Hey all,
>>>
>>> After consultation with Alexey I think the following emerges as the best approach for management of xml schemas, configuration pojos and configuration file backward compatibility.
>>>
>>> We should remove references to schema version in namespace and we might even rename namespace to something like "http://infinispan.org/xml/ns/ispn" and use a prefix "ispn" rather than tns. We could roll this in 4.1 final release. We leave 4.0 schemas as is, but 4.1 signifies a break and a new schema name-spacing that we intend to keep. How do we treat customer who want to use their 4.0 configuration files in 4.1? We tell them to remove references to old namespace from their configuration files. Thanks to ISPN-431 they are not affected.
>>>
>>> Since we removed references to configuration version in schema, as far as our configuration beans go, we are fine as long as we add properties to elements and even adding new configuration elements in ok. In essence, we are fine as long as we do not remove/rename existing attributes and elements from our configuration pojos. Adding new elements to configuration will still work. For example, lets say that 5.0 adds some configuration elements regarding JPA. Reading 4.1 configuration file in 5.0 is ok since we kept all those elements from 4.1 in 5.0, and for JPA element default configuration settings are initialized anyway.
>>>
>>> Let me know what you guys think.
>>>
>>> Vladimir
>>>
>>>
>>>
>>> On 2010-05-11, at 5:43 PM, Alexey Loubyansky wrote:
>>>
>>>> Hi Vladimir,
>>>>
>>>> yes, that's tricky. I can't say we have an elegant solution for that.
>>>>
>>>> I can't tell you what we do wrt EJB metadata (ejb-jar.xml/jboss.xml) as an example.
>>>> For jboss.xml we have common JBossMetaData.
>>>> http://anonsvn.jboss.org/repos/jbossas/projects/metadata/ejb/trunk/src/ma...
>>>>
>>>> It contains binding annotations but w/o the schema-level ones such namespace, etc. Then per schema version we create a top level class, e.g.
>>>> http://anonsvn.jboss.org/repos/jbossas/projects/metadata/ejb/trunk/src/ma...
>>>> http://anonsvn.jboss.org/repos/jbossas/projects/metadata/ejb/trunk/src/ma...
>>>>
>>>> There we specify the namespace and which properties we want to bind. So, actually, for some schemas common JBossMetaData contains more metadata than it is available in those schemas but those properties are just not bound for those schema versions. But the deployers regardless of the deployment descriptor version deployed use the same JBossMetaData API.
>>>> In this case, though, it's only for the top-level class (root element). Although, we could have some tricks for other classes/elements as well.
>>>>
>>>> Other metadata (sub)projects (web, ear, rar, etc) use the same approach. (There are also tests for consistency between XSD/DTD and Java bindings, i.e. structural equivalence)
>>>>
>>>> What is a bit different, we don't include schema version in the namespace. Schema versions are different but the namespace stays the same. The same is true for JEE spec schemas.
>>>> But even if we did, the current approach would still work.
>>>>
>>>> If you have some tricky cases/requirements then let's discuss them on the forums. It might be relevant to other projects as well.
>>>>
>>>> Best regards,
>>>> Alexey
>>>>
>>>> On 5/11/2010 9:46 PM, Vladimir Blagojevic wrote:
>>>>> Hi Alexey,
>>>>>
>>>>> Need an advice regarding best practices when it comes to XML schema management and references in configuration files. In infinispan project we have used JAXB annotated classes to annotate configuration pojos, automate manage configuration loading, and do schema creation. We have used the package-info.java files annotated with JAXB annotations to declare schema namespaces[1]. Then in turn we have generated XML schema file using JAXBContext#generateSchema.
>>>>>
>>>>> The current namespace is urn:infinispan:config:4.0, but this will change to urn:infinispan:config:4.1, urn:infinispan:config:5.0, etc in the future. What are our options for configuration file backward-compatibility?
>>>>>
>>>>> Best regards,
>>>>> Vladimir
>>>>>
>>>>>
>>>>>
>>>>> [1] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i...
>>>
>>>
>>>
>>>
>>>
>>
Vladimir Blagojevic
JBoss Clustering Team
JBoss by Red Hat
16 years
FYI : probable memory leak
by Philippe Van Dyck
FYI, I upgraded from ALPHA1 to BETA1 on a preproduction system this morning.
Take a look at the graphic attached, the server is restarted everyday around
1 am (blue and green lines crossing).
Users began to use the system around 9 am.... look at today's pattern and
the previous day pattern !
Anything I should know or I missed ?
cheers,
phil
16 years
Server location hints in Infinispan
by Manik Surtani
This relates to https://jira.jboss.org/jira/browse/ISPN-180.
In JBoss Cache, we had a provision to allow for pluggable buddy selection algorithms. By default, the buddy selection process would first try and pick a buddy in the same buddy group, failing which any buddy *not* on the same physical machine, failing which any buddy not in the same JVM, and finally any buddy at all. Further, being pluggable, people could write their own buddy selection algorithms to pick buddies based on any additional metrics, such as machine performance by hooking into monitoring tools, etc.
In Infinispan we do not have an equivalent as yet. The consistent hash approach to distribution takes a hash of each server's address and uses this to place the server on a consistent hash wheel. Owners for keys are picked based on consecutive places on the wheel. So there is every possibility that nodes on the same physical host or rack are selected to back each other up, which is not optimal for data durability.
One approach is for each node to provide additional hints as to where it is - hints including "machine id", "rack id" and maybe even "site id". The hash function that calculates an addresses position on the hash wheel would take these 3 metrics into account, so this should be robust and pretty efficient. The only drawback with this approach is that for each address, this additional data needs to be globally available since CH's need to work globally and deterministically. This information could be a part of a DIST JOIN request, which would work well.
What do people think? Any interesting alternate approaches to this problem?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
16 years
New JIRA setup
by Manik Surtani
As you may have noticed, we have a new JIRA instance, courtesy of the infrastructure guys at JBoss.org. I have created a new shared dashboard for Infinispan, which will give you an overview of what's going on in the project at any given time.
* Go to https://jira.jboss.org and log in
* On the "Dashboards" menu item on the top, select "Manage Dashboards"
* Select "Search" on the left tab list
* Specify "Infinispan" in your search terms
* And when you see the "Infinispan" dashboard in the search results, click on it
* Add it to your favourites (there should be a message at the top of the page)
Enjoy
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
16 years
