Re: [infinispan-dev] [hibernate-dev] Trunk failing because of infinispan tests
by Brian Stansberry
I'm forwarding this to the infinispan-dev list so the Infinispan guys
can fix it. Pinging them on IM as well.
On 12/01/2009 05:55 AM, Juraci Paixao Krohling wrote:
> Guys,
>
> As I know there are some Infinispan guys on this list, I'm sending it
> here. It seems that Infinispan maven repo used to contain some
> "-tests.jar" artifacts, but they weren't published on Nov 30, causing
> Hibernate trunk build to fail (look at cache-infinispan/pom.xml).
> Question is: should we remove the dependency from
> cache-infinispan/pom.xml or will Infinispan guys resume publishing the
> "-tests.jar" into their repository?
>
> Path to dependency:
> 1) org.hibernate:hibernate-infinispan:jar:3.5.0-SNAPSHOT
> 2) org.infinispan:infinispan-core:test-jar:tests:4.0.0-SNAPSHOT
>
> It tried to download this:
>
> http://snapshots.jboss.org/maven2/org/infinispan/infinispan-core/4.0.0-SN...
>
> - Juca.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
14 years, 5 months
Exposing transient/mortality information externally
by Galder Zamarreno
Hi,
Re: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267469#4267469
I think Brian has a good point here. We don't expose any internal
information wrt each cache entry's expiry/eviction values. Brian has a
good point that this could guide him in finding out which entries have
been last been used, how long they've been in memory and how it could
tweak expiration/eviction accordingly.
If we don't do anything, I think we run the risk of people being forced
to get hold of the container, looping through it and getting information
that they need from inspecting internal classes.
So, I'd suggest that we add a JMX method to CacheDelegate called
something like:
Map<String, Map<String, long>> getTransientAndMortalityInformation().
(I'm open to suggestions to other names. This is the 1st thing that came
to my mind)
This would return a Map where the key is the toString form of the cache
key and the value part is a map where individual transient/mortal
properties are returned. I.e.
[Person#1:[created:123456,lifespan:120000,maxIdle:60000,lasUsed:13456],
Person#2:[created:234567,lifespan:120000,maxIdle:60000,lasUsed:24567],
...]
We could event add calculated properties such as 'age' which is current
- created. This would vary with each call obviously.
As indicated in the forum entry, at least based on this use case, I
don't see an immediate need to query this type of information given a
key, although could be potentially useful for other use cases. The
reason this would not help much right now is because it is Hibernate
that creates the keys of 2nd level cache (i.e. CacheKey) and these are
nor meant to be recreated externally, so it'd be hard for external apps
to get something out of the Infinispan cache directly without going
through the Hibernate integration layer.
My suggested JMX method could allow for individual transient/mortality
information to be queried by tools, or other client jmx code. Maybe some
tools could use that to create a table or something like that which
could be ordered based on a column? i.e. age. Also, tools or client jmx
code could convert those longs into whatever they want: seconds,
minutes...etc
The reason I think JMX is a good candidate here is this is inherently
monitoring information and it allows us to expose internal information
via primitives without having to expose internal classes.
Thoughts?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 5 months
Re: [infinispan-dev] [jgroups-dev] Shouldn't Event.GET_PHYSICAL_ADDRESS return a collection PhysicalAddress instances?
by Galder Zamarreno
Here:
https://anonsvn.jboss.org/repos/infinispan/trunk/core/src/main/java/org/i...
We don't call that method in TP, we used your suggested solution. See:
https://anonsvn.jboss.org/repos/infinispan/trunk/core/src/main/java/org/i...
The method exposed in that interface is for sole internal use, it
provides an abstraction of the Transport. That's why I said that the
Address returned is our abstraction, or to be more precise:
https://anonsvn.jboss.org/repos/infinispan/trunk/core/src/main/java/org/i...
Now, back to the question, do you agree that we made:
/**
* Retrieves the current cache instance's phyical network address.
Some implementations might differentiate
* between logical and physical addresses in which case, this method
allows clients to query the physical one.
* Implementations where logical and physical address are the same
will simply return the same Address
* as {@link #getAddress()}.
*
* @return an Address
*/
Address getPhysicalAddress();
Something like this instead?
Address[] getPhysicalAddresses();
On 12/01/2009 03:49 PM, Bela Ban wrote:
> Where's that method ? There is a getPhysicalAddress() method in TP, but
> it's not supposed to be called. The way to get the physical address is
> via the GET_PHYSICAL_ADDRESS event.
>
> Galder Zamarreno wrote:
>> On 12/01/2009 09:41 AM, Bela Ban wrote:
>>> Brian Stansberry wrote:
>>>> On 11/29/2009 06:40 AM, Bela Ban wrote:
>>>>> This feature has been put on the backburner, I might not even
>>>>> implement
>>>>> it. If I do, then in 3.0, which requires changes anyway.
>>>>>
>>>>> I don't know who's using this event currently, are you guys
>>>>> prepared to
>>>>> change your code if I made this change ?
>>
>> Yes, we are but it might be wise to accomodate that for the future
>> since we have an interface called Transport that currently defines:
>> Address getPhysicalAddress();
>>
>> Where Address is an abstraction of JGroups' Address.
>>
>> So, to make it future proof, it should say:
>> Address[] getPhysicalAddresses();
>>
>> Currently, it would only return one but in the future it would allow
>> us to return more than one.
>>
>>
>>>> AS 6 will use it, as information on the address + port of cluster
>>>> members is part of the public API of the HAPartition framework. My
>>>> understanding was this already exists in JGroups 2.8.
>>>>
>>>> The AS can adapt to changes in this, as it's not part of any release
>>>> yet.
>>>>
>>>> JBC 3.2.1 uses it with buddy replication when JGroups 2.8 is
>>>> integrated,
>>>> to support not choosing a buddy on the same physical machine.
>>> I'll leave the GET_PHYSICAL_ADDR even as is for now, it will always
>>> return the physical address associated with the logical one. Associating
>>> multiple physical addresses will be done in 2.9 or 3.0, or maybe put on
>>> the backburner altogether.
>>>
>>> Should I decide to implement this feature, I can still create a
>>> GET_PHYSICAL_ADDRS (plural) event.
>>
>>
>>
>
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 5 months
Re: [infinispan-dev] [jgroups-dev] Shouldn't Event.GET_PHYSICAL_ADDRESS return a collection PhysicalAddress instances?
by Galder Zamarreno
On 12/01/2009 09:41 AM, Bela Ban wrote:
>
>
> Brian Stansberry wrote:
>> On 11/29/2009 06:40 AM, Bela Ban wrote:
>>> This feature has been put on the backburner, I might not even implement
>>> it. If I do, then in 3.0, which requires changes anyway.
>>>
>>> I don't know who's using this event currently, are you guys prepared to
>>> change your code if I made this change ?
Yes, we are but it might be wise to accomodate that for the future since
we have an interface called Transport that currently defines:
Address getPhysicalAddress();
Where Address is an abstraction of JGroups' Address.
So, to make it future proof, it should say:
Address[] getPhysicalAddresses();
Currently, it would only return one but in the future it would allow us
to return more than one.
>>>
>>
>> AS 6 will use it, as information on the address + port of cluster
>> members is part of the public API of the HAPartition framework. My
>> understanding was this already exists in JGroups 2.8.
>>
>> The AS can adapt to changes in this, as it's not part of any release yet.
>>
>> JBC 3.2.1 uses it with buddy replication when JGroups 2.8 is integrated,
>> to support not choosing a buddy on the same physical machine.
>
> I'll leave the GET_PHYSICAL_ADDR even as is for now, it will always
> return the physical address associated with the logical one. Associating
> multiple physical addresses will be done in 2.9 or 3.0, or maybe put on
> the backburner altogether.
>
> Should I decide to implement this feature, I can still create a
> GET_PHYSICAL_ADDRS (plural) event.
>
>
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 5 months