Unexpected value returned from the cache
by Sanne Grinovero
Hi,
I'm frequently experiencing problems with a stack as this one:
Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to [B
at org.infinispan.lucene.SingleChunkIndexInput.<init>(SingleChunkIndexInput.java:49)
The puzzling aspect is that the cast operation is applied on a type
I'm retreiving from a Cache, which can not possibly be of a different
type. I also happen to store some byte[] instances, but I never store
a Class instance so I have no clue where this is coming from.
I see these possible explanations:
1- Infinispan "forgets" to deserialize the object I'm requesting
2- It's picking the wrong Externalizer
3- the key is returning me a diffent object
4- I'm fooling myself with crap code
Any known issue in the first 3 categories?
Please don't ask me for trace logs, when I enable those the problem
doesn't happen.. I could try again with specific categories.
Sanne
12 years, 11 months
data interoperability and remote querying
by Mircea Markus
That is write the Person object in Java and read a Person object in C#, assume a hotrod client for simplicity.
Now at some point we'll have to run a query over the same hotrod, something like "give me all the Persons named Mircea".
At this stage, the server side needs to be aware of the Person object in order to be able to run the query and select the relevant Persons. It needs a schema. Instead of suggesting Avro as an data interoperability protocol, we might want to define and use this schema instead: we'd need it anyway for remote querying and we won't have two ways of doing the same thing.
Thoughts?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
12 years, 11 months
Fwd: Authentication implementation question
by Manik Surtani
This really should be on infinispan-dev.
Begin forwarded message:
> From: Tristan Tarrant <ttarrant(a)redhat.com>
> Subject: Fwd: Re: Authentication implementation question
> Date: 10 April 2013 14:49:51 BST
> To: "infinispan-core-dev(a)infinispan.org" <infinispan-core-dev(a)infinispan.org>
>
> Hi guys,
>
> I asked our Security Response Team for opinions on how a proper HotRod (or other types of authentication, such as JGroups node-to-node auth) would need to be implemented without incurring into common pitfalls.
> The reply is below, and I'll soon be writing up a spec proposal.
>
> Tristan
>
>
> -------- Original Message --------
> Subject: Re: Authentication implementation question
> Date: Wed, 10 Apr 2013 15:22:01 +1000
> From: David Jorm <djorm(a)redhat.com>
> To: Tristan Tarrant <ttarrant(a)redhat.com>
> CC: Arun Babu Neelicattu <abn(a)redhat.com>
>
>
>
> Hi Tristan
>
> Thanks for reaching out to ask us about this. It looks like the HotRod
> protocol is stateless and designed for high performance, which makes
> implementing a strong authentication mechanism a bit tricky. The #1
> concern is mitigating replay attacks:
>
> http://en.wikipedia.org/wiki/Replay_attack
>
> If authentication credentials are just passed over the network in
> cleartext, a man-in-the-middle attacker could extract them from a
> message and attach them to their own malicious request. TLS/SSL
> communication only partially mitigates this - when combined with other
> flaws, replay attacks are still possible for encrypted communications (I
> can explain this in more detail if required, but it is a bit of a
> digression from the topic at hand). To mitigate this problem, you could
> use a mechanism similar to HTTP digest authentication:
>
> http://en.wikipedia.org/wiki/Digest_access_authentication
>
> Since HotRod is stateless, you can't just authenticate the user once at
> the start of a session and then leave the authenticated connection open.
> Instead, you need to authenticate the user with each request. But since
> you're designing for high performance, that would introduce too much
> overhead, especially using a multi-step exchange like HTTP digest in
> order to avoid replay attacks. So you could authenticate the user once,
> then provide them with an authentication token that is valid for a given
> period of time. All subsequent requests just have the authentication
> token attached, which the server side can confirm is valid by
> maintaining a cache. Once the token expires and is dropped from the
> server-side cache, you authenticate again. This is the most efficient
> approach, but it is still vulnerable to replay attacks - if a
> man-in-the-middle can intercept an authenticated HotRod request, they
> can extract the authentication token from it and attach it to their own
> malicious request. This can be mitigated by selecting an appropriate
> balance between the valid life of the authentication token and the
> performance concerns. A token valid for 24 hours would make replay
> attacks far too easy. A token valid for 1 minute would make replay
> attacks very difficult, but could introduce too much overhead.
>
> The alternative approach is to make the protocol stateful. Then you'd
> just authenticate once at the start of the session (using something like
> digest to avoid replay attacks), and avoid the need for tokens.
>
> In addition, I have the following recommendations:
>
> * Default to authentication over TLS/SSL if at all possible
> * Do not implement account lockout for too many incorrect password
> attempts as this becomes a vector for denial-of-service attacks
> (intentionally lock out someone's account using invalid login attempts)
> * On the server side, only store salted one-way cryptographic hashes of
> credentials, no passwords either cleartext or encrypted
>
> I hope that helps, please let me know if I can be of any further assistance.
>
> Thanks
> David
>
>
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
12 years, 11 months
a nice HTML5 console for Infinispan & a question on MBean names...
by James Strachan
Howdy folks!
I'm working on a HTML5 web console called hawtio (http://hawt.io)
which is a pluggable & modular console for various Java libraries,
frameworks and containers. e.g. today it has plugins for Apache Camel,
ActiveMQ, Fuse Fabric as well as JMX, OSGi & Logging - then plugins
for containers like Tomcat, Jetty, JBoss, Karaf/ServiceMix. We've a
cute dashboard & wiki which uses git to store its configuration/files
too.
Anyway the reason I bring this up is yesterday we had our first
Infinispan issue with hawtio:
https://github.com/hawtio/hawtio/issues/134
its now fixed; but it got me thinking if we could have a nice little
hawtio plugin for Infinispan so folks could make dashboards of real
time metrics of caches, browse caches etc.
I enabled metrics and managed to get a basic JMX tree going with real
time metrics on attributes/charts on a single Cache using vanilla JMX
in hawtio with Infinispan. I've attached an example of how it looks if
you're interested.
The thing is, there's no way to easily click on a folder and get all
the MBeans for the Statistics. If that were the case then hawtio would
show a sortable table of all the metrics of all the caches in one
table view; or we could easily chart any of the metrics of all the
caches in one real time chart easily.
It'd be a fairly minor change; we'd just need to change the ObjectName
used for the Cache mbeans from this naming convention:
Infinispan:type=Cache,name="drink(local)",manager="DefaultCacheManager",component=Statistics
to this (just moving the "name" property to the end)
Infinispan:type=Cache,manager="DefaultCacheManager",component=Statistics,name="drink(local)"
then in the hawtio JMX tree we could select the "Statistics" folder
and see all of the mbeans in a table and so you could sort the table
by metric, see all the values on a single screen & create real time
charts of any permutation of cache & metric.
I wondered if folks fancied either adopting this naming convention
(putting the name last and the component kind before it) or adding a
configuration flag so we could enable this kind of JMX naming
convention style? It'd make things much more hawt when using hawtio
and infinispan! :). You'd get nice HTML5 statistics in hawtio
instantly on all caches.
I also wondered if folks fancied adding a few more operations to the
Cache mbean so that we could build a little console in hawtio for
Infinispan; to view/update contents of the caches or flush them etc?
As a background; since JMX is usually the lowest common denominator,
hawtio defaults to using it to detect whats in a JVM. If we discover a
particular kind of MBean we then enable/disable different parts of the
hawtio UI dynamically. e.g. if you're viewing a JVM then you deploy
some Apache Camel, hey presto, the Camel UI in hawtio appears as a
tab.
>From a technology perspective hawtio is all static HTML5 / JavaScript
on the client; it then communicates with the MBeans via an awesome
library called jolokia (http://jolokia.org/) which exposes JMX over
HTTP/JSON.
So hawtio could totally use the Infinispan REST API (but it'd be nice
if there was an mbean registered to indicate the REST API is running
and where to find it so hawtio could discover it). However you can
usually rely more on JMX being there (folks don't always deploy
Infinispan inside a web container with a REST API). So I wondered if
folks fancied adding a simple little JMX API to query / update / flush
the cache that we could then use to build a little HTML5 console in
hawtio?
e.g something valuely like:
interface CacheMBean {
...
String getJson(String key)
void setJson(String key, String value);
// lets browse the keys - in a simple paginated way some how..
Set<String> getCacheKeys( String from, int count);
}
You could return Objects; jolokia automarshalls things to JSON; though
maybe having a specific JSON reading/writing mbean (using
jolokia/jackson under the covers) might be neater as it'd work with
all JMX tools?
So in summary, I'm happy to help hack a little hawtio plugin for
infinispan if anyone's interested. Making the cache ObjectName change
would be a nice quick win & if more operations get added to the MBeans
we can then easily build a better hawtio plugin for Infinispan.
Thoughts?
--
James
-------
Red Hat
Email: jstracha(a)redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration
12 years, 12 months
Dropping the @ConfigurationDoc support
by Mircea Markus
Hi,
These annotations haven't been maintained for the new configuration objects, also if user is looking for this kind of information he should be able to find it in the appropriate place: javadoc if using the configuration API or the XSD if using the XML. I think this was useful at the time the XSD was generated, but not these days. Any cons for not dropping this?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
12 years, 12 months
Re: [infinispan-dev] Missing elements when using JProfiler...
by Bela Ban
A possible explanation for this:
Say we're not finding message 17 in [4 | 15 | 25]: 4 is the lowest
message we *garbage collected*, 15 the highest we *delivered* and 25 the
highest we *received* so far.
When different threads sent messages 15 - 18, they could have sent them
in the order 15 -> 18 -> 16 -> 17. (Messages are only ordered at the
receiver).
If, *before* 17 was added to the sender's retransmission table, the
retransmit task at the receiver kicked in, then message #17 would not be
found in the sender's retransmission table. A few microseconds later,
#17 would be added and therefore retransmission would pass, although the
receiver is likely *not* to ask for retransmission of #17 anymore as it
probably received the message by now.
This is *not* incorrect, but I mitigated it in 3.3.x by dividing message
gaps at the receiver into 2 groups: old and new, which is something like
a generational garbage collector, where the most recent missing messages
are not retransmitted for the first time, only when they 'survived' one
retransmission. In other words, with 3.3.0.x, you should see far fewer
of these warnings !
On 4/9/13 5:00 PM, Alan Field wrote:
> Hey Bela,
>
> A couple of weeks ago, I was trying to run the client stress test comparison between JDG and Coherence under JProfiler. These test runs were not successful, because one of the nodes in the cluster would always crash. However, I was also seeing missing element log messages from JGroups, like this: (https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-61-radargun-jdg-...)
>
> 16:48:09,363 WARN [org.jgroups.protocols.UNICAST2] (OOB-9,edg-perf01-16155) edg-perf01-16155: (requester=edg-perf02-56801) message edg-perf02-56801::8723243 not found in retransmission table of edg-perf02-56801:
> [8722840 | 8722840 | 8723253] (411 elements, 2 missing)
> 16:48:12,327 WARN [org.jgroups.protocols.UNICAST2] (OOB-67,edg-perf01-16155) edg-perf01-16155: (requester=edg-perf03-22539) message edg-perf03-22539::9484784 not found in retransmission table of edg-perf03-22539:
> [9484613 | 9484613 | 9484807] (193 elements, 1 missing)
> 16:48:12,794 WARN [org.jgroups.protocols.UNICAST2] (OOB-53,edg-perf01-16155) edg-perf01-16155: (requester=edg-perf03-22539) message edg-perf03-22539::9484784 not found in retransmission table of edg-perf03-22539:
> [9484783 | 9484783 | 9484840] (56 elements, 1 missing)
>
> I don't know if these messages have any relation to running the jobs with JProfiler, but I wanted to ask you about them. In this job configuration, 4 nodes are used in the cluster, (edg-perf01 to edg-perf04) but JProfiler is only attached to the JVM on edg-perf01.
>
> Thanks,
> Alan
>
--
Bela Ban, JGroups lead (http://www.jgroups.org)
12 years, 12 months
query repl timeout
by Ales Justin
We're running a GAE HelloOrm2 example app on 3 nodes (3 laptops).
Very soon after deploy, we get a never-ending stack of timeouts,
which completely kills the app:
* https://gist.github.com/alesj/5319414
I then need to kill the AS in order to get it shutdown.
How can this be tuned / fixed?
-Ales
12 years, 12 months
